@CᴏɴᴏʀO'Bʀɪᴇɴ The typical order of Python arguments is f(modifier, source). See: map, apply, everything outside of string methods.

Which looks better?

re.sub(lambda x:do_something(x), source_string)
re.sub(source_string, lambda x:do_something(x))

You two are just saying that to be argumentative >_>

But the first shows you how it's being modified

red apple vs apple red

Adjective before noun

Unfortunately there's no cure for that yet

But stay strong; one day we will be able to rid you of that horribleness

The lambda is the adjective. The source string is the noun.

s/lambda/replacement_string/

Why am I arguing with JS fanboys; you'll never understance the elegance of Python

"really like OOP"

Man you need some serious medication

Oh I misread

Oh well, close enough

"really ... like OOP"

Young padawan, you have much to learn

There are many programming paradigms

And none are silver bullets

Each paradigm is good at solving certain problems. OOP is unique in that it's one of the few paradigms that is not good at solving any useful problems.

@CᴏɴᴏʀO'Bʀɪᴇɴ Now I think you're trying to piss everyone off :P

@CᴏɴᴏʀO'Bʀɪᴇɴ "Trees" isn't a problem. Trees are a way of representing a problem.

@CᴏɴᴏʀO'Bʀɪᴇɴ Functional programming. LISP.

One of the most important things you'll take away from a formal CS education is that there is a right tool for every job, and no tool is right for every job.

You'll come to find that even those languages you despise have their niches.

Like VB.NET, for example. I loathe it. But it's the only reasonable choice when you need to make GUI apps fast for Windows machines.

And you'll learn to put aside the language bashing and deal with the language's supposed shortcomings to get the job done.

Because you're being told to, not because you think it really is the right tool for the job?

Python is exceptionally useful for writing quick'n'dirty scripts. It's also good for larger projects, but it forces you to actually document things well and think hard about what you're doing. A lot of people will say Python is horrible for large projects because of its duck typing (and other language features). The reality is, they just don't want to think that much about what they're doing.

@Cyoce That makes no sense. If it's the right tool, it does the job right, and doesn't need fixing. The fundamental design of a hammer hasn't changed in the past few millenia - it's still something hard on the end of a stick. It's the right tool for the job when you need to hit something small really hard. It may suck at other jobs, but that doesn't mean it needs reworking - that means you need a screwdriver.

Exactly. It's not the hammer's fault that it's a hammer. It's the wielder's fault for thinking everything looks like a nail.

@Cyoce Ok, start a list of things that need fixing in Python, and I'll give you the design justifications for them.

Unlike many other languages, Python's syntax and features were thoroughly planned before any code was written.

@Cyoce What fear of properties?

do-while is a shortcut for using a loop marshal

@Cyoce That's because strings are iterables, and len is a global operation on all iterables.

It is

str.__len__ is the internal method. The public interface is len(str)

It's a different spelling of the same thing

Why is it stupid?

Why?

@CᴏɴᴏʀO'Bʀɪᴇɴ That's because s++ would be ambiguous on basically all objects

Nope, because you are specifying exactly what to add to it

Explicit is better than implicit

@Cyoce You confuse explicit with verbose

There is nothing wrong with str.length. There is also nothing wrong with len(str). Neither is better than the other.

^

@AlexA. you summed up what I was about to try to type very well

@CᴏɴᴏʀO'Bʀɪᴇɴ Either tbh, though naturally I lean towards the latter because Python

It should be commutative, because a*b is normally commutative.

So really the answer is both

$ python -c 'print 3*"foo"'
foofoofoo

$ python -c 'print "foo"*3'
foofoofoo

Good language design: a*b is commutative

* is commutative in Seriously also

@flawr AdderFactory.createAdder<Integer, Integer, Integer>().add(i,1).result<Integer>();

"foo"3* vs 3"foo"*

That's not even Java; that's overuse of verbose design patterns

Factory pattern is useful when used correctly and causes homocidal tendencies when it's not

@Cyoce Weren't you arguing about Python being bad?

@flawr Do code this way, regardless of the language

Factory pattern: you have a bunch of different classes that all do somewhat-similar things, and you need to select one based on parameters. So, you create a shared interface for the classes, and create a class (the factory) that creates the appropriate object based on the parameters and returns it as an instance of the interface for polymorphism fun.

@Cyoce You were giving reasons why Python is bad, and I was making you justify your reasons. You went quiet, so I assumed you gave up.

Java is not to blame for overusing verbose design patterns; you just see a lot more Java code that does overuse them

You can abuse the factory pattern in C++, Python, or any language that supports OOP

I said language, not murder weapon :P

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

How to code gud

@CᴏɴᴏʀO'Bʀɪᴇɴ If Seriously isn't licking the window I'm gonna be sad

@CᴏɴᴏʀO'Bʀɪᴇɴ Great in theory, terrible in implementation. It often ends up licking the window rather than solving the problem golfily.

Hexagony is tying its own shoelaces to the fan

Or giving itself a wedgie/swirley