Live data from Hacker News

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

news.ycombinator.com

141–150 of 231 posts

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

#141
post #134

Earlier quoted context omitted.

(Disclaimer: Not meant as flamebait) 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…

Note that you start with "you're doing it wrong" and end with "I personally would much rather". :) You also switch from arguing against type checks overall (could be Haskell) to arguing against Java. I'd say that strong compiler checks become more helpful as the size of a program increases. You can keep less of a big program in your head, and big programs have more code paths that could potentially need testing.

Hm, I didn't mean to argue against all type checks, just the flavor of static typing as described by the OP (i.e., Java). I don't consider Haskell's type system "rigid"; it's strict as hell, but it's also very expressive.

Either way, both flavors of static typing require development methods that are very different from Python's, though. My original point was that in Python, you shouldn't really have to worry about types, or checking them (in tests or otherwise). You can, but (IMHO) you'd be going against the grain of the language.

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

#142
post #129
post #74

Earlier quoted context omitted.

My impression, although I'm not an insider and could be off base, is that it wasn't conceived to be an enterprise language, but its patterns were. I learned it when I started application programming for my startup (I had been doing scientific routines, i.e. FORTRAN and Mathematica), because I was curious about OO. A lot had changed since I hacked out a little C and assembler on my Mac+ many years ago, and the scale o…

Most of these patterns come from Smalltalk (which was probably the original language of complex enterprise OO systems). I think that what made Java this kind of entrprise language is that it was reasonably similar to smalltalk so all these patterns and concepts can be reused and on the other hand it is similar to "normal" programming languages so average programmer does not have problems with it's workflow and IDE (a…

LOL- I think I had the same IDE when I was first stumbing about with Java! It was definitely a WTF moment. It became useful for code expansion, refactoring, and unit testing however. I'm now using vim to develop php and Javascript and I miss its convenience (on the other hand, I'm a lot better with sed now...). But using Firebug to find my errors is a bit slow.

What I find really cool about your comment is that you appear to have a deeper view of it all (meaning a deeper understanding of the underlying semantics), and I'm wondering how my view will change as I continue to work with it.

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

#143
I like Python because, IMO:

* It's the most concise, expressive language I know * Friendly syntax: I just write what I'm thinking and it pretty much works * Most importantly: It includes a ton of functional programming goodies (of which I make liberal use), but I can still just say x = 1 when I want to. Best of both worlds.

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

#144
post #56
post #44

Earlier quoted context omitted.

I indent my Perl code. Not everyone does, however. It's a trivial task to reformat it in an editor. 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.

The point is, I've never met a programmer who doesn't think of indentation. I've never seen a (real) project which doesn't have indentation. So if everyone is doing it anyway, why not take advantage of it and make it a part of the language? This way programmers learn to use indentation from the start (which any real programmer uses anyway), and indentation is always correct, nothing to ever think about.

Shouldn't tools take care of that before a commit to svn, git, etc? Java has formatters, the Go language has one.

Do any exist for Python or Perl?

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

#145
post #103
post #74

Earlier quoted context omitted.

My impression, although I'm not an insider and could be off base, is that it wasn't conceived to be an enterprise language, but its patterns were. I learned it when I started application programming for my startup (I had been doing scientific routines, i.e. FORTRAN and Mathematica), because I was curious about OO. A lot had changed since I hacked out a little C and assembler on my Mac+ many years ago, and the scale o…

>> feel like I'm evolving my own design patterns I think that this is happening to many people who are doing a lot of 'non-trivial' JavaScript. The language is still very young and because the concepts that were chosen when creating the language are powerful and flexible (prototypal inheritance, objects can be accessed like hashes, first-class functions etc) there's always a million ways to code something. OO-wise i…

I have somehow settled into the pattern of using new/java-like classes for large objects that store a logical set of data and need to operate on it, and on-the-fly prototypes to groups group just data (or, perhaps, a trivial operation).

My worst crime by far (that I am aware of) is that I have no hesitation to use a global variable if it saves me from bending over backwards to get around it. I'm doing animations, and sometimes the algorithm just comes to me a lot faster if I let a var keep a global value and be used by lots of functions between calls to my animate() function (using window.setInterval() ).

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

#146

Earlier quoted context omitted.

(Disclaimer: Not meant as flamebait) 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…

Well of course I'm doing it wrong, I got crashers during execution :) I understand the concept, but sometimes in a medium-size project, you just accidentally send the wrong object back. It happens. But Python won't tell you, and it'll blithely wait for the code to get exercised before dying. I don't remember exactly why I was having this problem, but the bug wasn't shallow, and required a certain confluence of except…

"I don't remember exactly why I was having this problem, but the bug wasn't shallow, and required a certain confluence of exceptions to occur before it would fire. The sort of thing that would even escape most unit testing."

I agree that this does indeed happen... I think it's a matter of, the more flexible a language is, the more rope you get to hang yourself with, even unintentionally and unexpectedly.

(Anecdote:) For my work, I have been developing and maintaining a fairly large Python code base... (~70K lines... comparable to about 700K lines of Java ). Another developer changed a module so it would access the database upon importing, which was a no-no (IMHO), so I changed it back, using a class that gets the desired info from the db upon instantiation, and some sort of singleton construct so the same instance would be reused. I also decided to write a test to check that when this module was first imported, there would be no instance of said class yet. To make sure it was a first import, I removed any references to the module from sys.modules, then did an import. This worked great... until I ran the whole test suite using nose [http://code.google.com/p/python-nose/], which has its own ideas about import order and such. This turned out to be surprisingly hard to fix... a non-shallow bug that wouldn't even be possible in less flexible languages.

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

#147
post #107
post #87

Earlier quoted context omitted.

curious what you prefer about Ruby. i'm very familiar with python, and have only looked at Ruby long enough to decide (mistakenly?) that it wouldn't do anything for me which python doesn't already.

Given a = [1, 2, 3, 4, 5]: Ruby: a.map{|i| i+1}.reject{|i| i%3 == 0}.map{|i| i*i} Python: [i*i for i in filter(lambda i: i%3 != 0, [i+1 for i in a])] Please ignore the fact that the whole operation can be simplified mathematically - nontrivial map-grep-map operations do occur. I find the Ruby version clearer because it proceeds from left to right like a shell pipeline.

In Perl 6:

  @a.map({ $_ + 1 }).grep({ $_ % 3 != 0 }).map({ $_ * $_ })
Alternately, using the feed operator ==>:

  @a ==> map { $_ + 1 } ==> grep { $_ % 3 != 0 } ==> map { $_ * $_ }
And, if your code being readable to people who've never used Perl 6 and know nothing about it isn't a concern, you can use the much more concise Whatever star notation for closures:

  @a ==> map * + 1 ==> grep * % 3 != 0 ==> map { $_ * $_ }
Using Whatever for the last one would neither work nor be readable(although you could do "* 2", but that's still suboptimal for readability), since the last "" in " * " would be interpreted as a second parameter.

If the preceding notations for anonymous functions have been too implicit for you, then you can use pointy blocks(or just plain anonymous function declarations).

  @a ==> map -> $i { $i + 1 } ==> grep -> $i { $i % 3 != 0 } ==> map -> $i { $i * $i }
Or, you could use hyper operators instead of the maps:

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

The hyper-operators extend the scalar operators "+" and "
*" to lists. Since the ">>" point to their operands on the right side, that operand will be extended to be as long as the other side, allowing you to use a single scalar as the right-side element.

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

#148
I am a day-to-day C programmer. I am surprised to hear Python did not fit well after C for you. In my view, Python is the like the easy scripting version of C. I first learned Tcl/Tk, then Perl, then looked at bash scripting (my god, horrible) and seen that the earlier three has some obscure syntax with some special meanings of $'s and @'s and hyphenated flags everywhere with no resemblance to C.

Then looking into python, I saw the same philosophy as C; A struct or an array? Use a nice dictionary, set, tuple or a list, nicely kept under the [ ] brackets. Throw them in for loops without the iteration integer. Its just all the same things I do in C but easier, with no cryptic idioms. That's why I love it.

I have 2 choices of languages for all my projects: C and Python

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

#149
post #87

Earlier quoted context omitted.

curious what you prefer about Ruby. i'm very familiar with python, and have only looked at Ruby long enough to decide (mistakenly?) that it wouldn't do anything for me which python doesn't already.

Python and Ruby are very much alike but I find Ruby more ergonomic. It's more consistently object-oriented, which means I spend less time looking things up because the core is easier to remember. The syntax is more expressive, which makes my code shorter and easier to read. The consistent use of blocks everywhere is more intuitive and consistent than Python's mix of loops and comprehensions. I find I can take in a bl…

You gave a great comment. I get almost completely the opposite take on Ruby versus Python though:

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.

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

#150
post #130
post #43

Earlier quoted context omitted.

You don't really appreciate Python until you try and program in something like Java again. The following code is readable and I have required a variation of it in a program before: sorted([ord(c) for c in set('letters in this sentence') & set('and this one')], reverse=True) Doing it in Java would be a chore now.

Doesn't python have sorted sets? Oh, what a pity. Does python only have one single implementation of sets? Too bad. Is the runtime behaviour of that implementation documented? Let's take a look ... I'll be back. This could take a while.

Python has sets as a built-in datatype. If someone needs a different implementation, there's nothing stopping them from writing one.
Post reply on HN