I don't like Python. Does that make me a bad person?

But in Python, you don't even have to worry about other people not indenting their code!

I guess the only complaint I might have is why bother thinking about indentation, ever? Throw in a couple of {} and now the tools can provide additional help.

When you edit Python, the tools can already help as much. The start of a block is obvious (def, if, for, etc), so tools indent for you. To dedent, just hit the right key (e.g. a backspace on an empty line in emacs) -- no harder than hitting the brace key.

The pain of keeping indentation correct is a forced ongoing investment in readability that is well worth it--at least to me.

I'm glad that haskell also has whitespace rules.

Hotfixing is a naturally perilous process regardless of language. I've spent hours tracking down untested hotfixes in Java.

You're also probably less likely to come across a badly formatted block of python code because that would generally result in a bug. Much like misplaced brackets in Java/C/C++ would result in a bug.

It doesn't make the code magically better. It makes it less redundant. Indentation should already be there, why do you need curly brackets?

This. I'm convinced half the reason Ruby is displacing Python is that it's actually practical to talk about Ruby code in forums without ridiculous little-known workarounds like pastebins.

http://google-styleguide.googlecode.com/svn/trunk/pyguide.ht...

In fact at Google the maximum line length for python code is 80 characters because long lines make the code unreadable, and following the style guide basically anything can fit in a nice and readable way.

for (i = 0; i < 1000; i++)

     printf ("%d %d %d\n", i / 100, (i % 100) / 10, i % 10);

In case the loops are doing something different, they should be indented separately. For instance, the following makes little sense:

for (i = 0; i < 10; i++) {

foo (i);

for (j = 0; j < 10; j++) {

     foo (i + j);

foo (i + j + k);

}

}

}

what do you think of ooc-lang syntax? http://ooc-lang.org/

It seems like Java wasn't defined in order to be an efficient for a three-person shop to hack in. It was meant to be efficient for a 40 person shop to build code as a team that they can maintain.

That said, I dread going back to my Java projects and updating them, even though I tried to maintain best practices in order that updating be as simple as possible. I've been immersed in php and javascript lately, so we'll see what it's like to go back.

If you want Java without the unwieldiness, try Groovy. It's Java with a ton of syntactic goodness added; for instance, the default variable scope is "create a getter and setter which I can optionally override." Groovy interoperates well with Java libraries. The downside is that it's a dynamic language, so there is a significant performance penalty.

    (use 'clojure.set)

    (reverse (sort (map int
                        (intersection (set "letters in this sentence")
                                      (set "and this one")))))

    (use 'clojure.set)

    (->> (intersection (set "letters in this sentence")
                       (set "and this one"))
         (map int) sort reverse)

Scala isn't as succinct, of course, but it gets much closer!

def foo (self, stream): What is stream here?

void foo (std::ostream &out) { out << "bar" << endl; }

Hope you get the point.

The purpose of this thread was merely to gauge what kind of paradigm shift people who were used to programming in C or C++ generally experience when they move to Python. Some people seem to find making the jump easier than others - I personally have found it difficult and have made little progress so far. Since I generally consider myself good with computers, I find this a little unnerving.

I think it's fairly clear from context that he/she means, "not a lot of red tape", rather than a reference to specific language features.

The whole scripting language issue is a complicated one imo.. People want to either use 100% scripting or 100% system (i.e., C), which is not alright. Combine scripting & system according to your needs. This is why I like Tcl the most: It prevents you from using it where there might be computational bottlenecks (e.g., in algorithms). It is meant to complement C, not replace it. Anyway this is a separate thread.

Not to be a prick, but if you're having "typing" problems with Python, you're using it wrong.

Types are almost irrelevant in Python. What matters is whether, in a given situation, the method you're calling is supported and does what is intended. The actual type/class of the receiving object doesn't really matter, ditto for any arguments you pass to the method.

While this may seem highly unsafe and brittle, it has important benefits. You can just hack up some code that "just works" in a few minutes, without having to sacrifice a goat to the compiler first, making sure that all the correct types are specified, subclasses are defined, interfaces are implemented completely, etc. The rigid type systems in other languages often require this and more; making changes to your software becomes a chore. Rapid prototyping this is not.

In Python, when used correctly, you don't have this problem. Write a bit of code, write a test, run it, and decide what to do next. Ideal for testing out ideas. It doesn't work? Throw that shit out and write something else; two minutes later you'll be testing your new code again. Yes, you do need to have unit tests, but the same is (or should really be) true for most languages. Just because something compiles, doesn't mean that it does what you want. (Except maybe in Haskell. :-)

Interestingly, the quickly-written prototype might well be good enough to become the actual production code, with some additions. Just keep you tests up-to-date, for reasonable use cases, and there's no reason why your code shouldn't work in real life. Sure, that function foo(x) that wants to call x.bar() will fail if you call it with an x that doesn't support the bar() method. So don't do that, then! ;-)

Anyway, to summarize, I personally would much rather have Python's flexibility, paired with unit testing, than Java's lack of flexibility paired with compiler checks.

Here is a link to doctests. There are godly, and unlike any testing library, in that they aren't a library, they're a comment scanner: http://docs.python.org/library/doctest.html

Smallest amount of rigmarole required to make testing happen I've seen in any language.

Java is almost untyped by comparison. Languages like Ocaml and F# occupy a middle ground.

All of Java's features conspire to create a language that's pretty verbose and doesn't do a lot to make things easier for you (aside from simple object orientation). If you like spelling everything out in excruciating detail, that's good. If not, the language doesn't want to twist your arm, but it's certainly not going to do anything to help you.

Ruby is more fun,but python is more mature. In the end - whatever gets the job done right?

There are a number of things that made me think Ruby was made by a less astute designer. The 'end' everywhere feels bad in a world where I know both "}" and a newline can accomplish the same thing but with less typing and screen clutter. Also do not like Ruby's dropping of ()'s from fn call statements, because it blurs the boundary with non-calls and non-expressions and control flow keywords. I also feel Ruby encourages a certain kind of DSL creation which makes the code harder to read and maintain. I also don't think every app or library needs to export a DSL into client space. It's better if the interface it publishes still looks and feels like the prog language used.

That said, I acknowledge Ruby has good qualities. Python is not perfect, but to me it gives the better designed feeling. Actually the Lisps seem to be the most elegant and powerful. Love their regularity and power but not (yet) all the parentheth everywhereth.

Apropos: Does Ruby optimize tail calls?

    a = '''O'Malley says "Hello"'''

    a = "apple pear orange".split()

For example, if there's a function composed entirely of print statements, the last expression evaluated will be the expression in the last print statement executed. But, that means you have to know that 'print' is a statement and not an expression, and that the right-hand side of the print statement is in fact an expression.

In ruby, actions like prints and assignments are side-effects and always evaluated as expressions. So if puts is the last expression in a function you'll get the return value of puts (which is usually nil I believe). That's pretty simple.

This is easier to read and understand, only goes through the list twice, and loses nothing in terms of power:

    [j*j for j in [i+1 for i in a] if j%3 != 0]

In general, I don't see much of a reason to use filter/map/etc in Python: weak lambdas mean they're not terribly powerful. List/sequence comprehensions can do everything they can do with cleaner syntax and/or fewer operations.

This, I think, is actually at the core of this whole discussion. The Ruby/bash approach makes sense if you're used to working with sequences like Ruby/bash do. The Python approach is more natural to me though, because I've written a lot of Python. (And having spent the last year writing a lot of Ruby, I still find the Python approach cleaner/easier to understand at a glance.)

This is an excellent point. Ruby code can be some of the cleanest, most readable functional code there is. I have these kinds of chained pipelines in my Ruby code all over the place and they're much easier for me to follow than similar expressions in Lisp or Haskell and than Python's comprehensions.

    map { $_*$_ } grep { $_%3 != 0 } map { $_+1 } @a

  @a.map({ $_ + 1 }).grep({ $_ % 3 != 0 }).map({ $_ * $_ })

  @a ==> map { $_ + 1 } ==> grep { $_ % 3 != 0 } ==> map { $_ * $_ }

  @a ==> map * + 1 ==> grep * % 3 != 0 ==> map { $_ * $_ }

  @a ==> map -> $i { $i + 1 } ==> grep -> $i { $i % 3 != 0 } ==> map -> $i { $i * $i }

  ((@a >>+>> 1).grep: {$_ % 3 != 0}) >>**>> 2