You owe it to yourself to learn at least one dynamic high level language. The advantage of Python (and Ruby, which I prefer) is that, for the right tasks, it's an extremely productive language. Compared to C++ or Java you have to write far, far less code and you can usually find good libraries that reduce the amount of code you have to write even further. Python doesn't have the elegance or flexibility of Lisp, but it's an extremely practical language for getting anything done that doesn't need C++ performance.
I don't like Python. Does that make me a bad person?
71–80 of 231 posts
Re: I don't like Python. Does that make me a bad person?
#72Earlier quoted context omitted.
The main reason I like having explicit braces and non-significant whitespace is that it allows me to use my whitespace flexibly to clarify the structure of a program. There are some interesting ideas regarding the use of whitespace in C here: http://www.quinapalus.com/coding.html I don't agree with everything he has to say- for example, I think his nested for loop example would be far nicer as something like this: fo…
Would it not be better this way: for (i = 0; i printf ("%d %d %d\n", i / 100, (i % 100) / 10, i % 10); IMHO, such patterns (multiple nesting with empty outer loops), in most cases, are really an indication of just one real loop. Using multiple counters might also be an option. In case the loops are doing something different, they should be indented separately. For instance, the following makes little sense: for (i =…
I absolutely agree with your second example, but I think you're missing my point for nested loops. Perhaps this would be a better example:
Let's say I'm making a simple tile-based game that uses a two-dimensional array called "grid" to store the map. To draw that map to the screen, I might do something like the following:
for(int x = 0; x Again, I am not arguing for indentation anarchy, merely that there are times when it can help to bend the rules.
edit: I imagine you'd prefer something like this?
for(int t = 0; t Re: I don't like Python. Does that make me a bad person?
#73Yesterday there was an interesting link on HN comparing NLP in Python vs. other languages: http://nltk.googlecode.com/svn/trunk/doc/howto/nlp-python.ht... . I think this article shows the clearness of the Python language - - and this clearness and simplicity is the reason why I love to code in Python.
I agree that short python samples are as clear as a high level language can possibly be. Implementing algorithms, for instance, becomes incredibly easy in Python. I face problems when Python programs get above a certain length. I've done some Django programming in the past. A view gets a request object (pardon me if I'm wrong or if this has changed recently) and is supposed to then render the response (or something s…
I'm surprised no one has mentioned Peter Norvig yet.
http://norvig.com/21-days.html
From your comments, I kind of get that you want to be a real good programmer, and part of being a good programmer is to understand the different way you can wire bit and pieces together in the many different languages. I had a similar experience as you in that I went from C->C++->Java->Javascript->Scheme->SML->Python. I can definitely tell you that learning Scheme and SML first helped me tremendously in understanding dynamic languages in general. In more concrete terms, understand typing rules has helped me how to debug a program when I mess up in Python. For example, in SML, I can completely omit type annotations and the interpreter will infer the right type for me at parse-time, and that each function or statement must only return 1 type.
In dynamic languages such as Python, you can still do what you can do in SML or Haskell, but the runtime system makes no guarantee that your program as it is written is type-safe when the interpreter parses all your source files. Type checking is done at execution, when the code path in question is exercised. However, if you THINK about how the types are infered in SML when you write in Python, you generally will not run into TypeErrors.
The same goes for functions that return different types. To prevent tripping up with these functions, just apply what you've learned in Haskell or SML when you are debugging library functions that do this, and avoid writing functions that return different types.
Re: I don't like Python. Does that make me a bad person?
#74Earlier quoted context omitted.
Java doesn't require you to define getFoo() and setFoo(). Some best practice advice suggests you do. But you can leave the vars public and just use the . operator, if you choose. 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 proj…
Java certainly was not designed to be this "enterprise language" it is now. It only was similar enough to Smalltalk to replace it. (and Smalltalk has this culture of "if it is repetitive then extend IDE to automate it", which to some extent influenced Java IDEs)
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 of the problems programmers and programming teams had to handle had changed significantly. It seemed OO became popular as a way to handle this scale of things. Java was presented as a solution for building maintainable apps, so I learned it.
I also tried to stay close to the OO paradigms (of course, I was just learning them), as I built this 50000 line beast called "Egorg." Now, I get to maintain and update it, so we'll see if it paid off.
On a side note, I have a real distaste for objects in Javascript. They seem clunky, almost like they were stuck on as an afterthought (I get a similar feel about Generics in Java). But the design of Javascript makes it quite easily to hammer out a script to do something cool. I'm worried about maintenance, though, because I feel like I'm evolving my own design patterns, so retracing my steps will likely be painful.
You are correct about the IDE thing. That does ease a large burden in Java.
Re: I don't like Python. Does that make me a bad person?
#75Earlier quoted context omitted.
Java is, as I said, a toy language. A language that needs you , the client programmer, to define getFoo () and setFoo () methods manually can't be right.
I don't get what you mean by "toy language." Clearly some big, powerful, practical stuff has been written in it. Usually the phrase "toy language" is used to refer to those with little practical use. Java is unwieldy, but it has a rich ecosystem and compiles to very efficient code across a broad range of platforms. If you want Java without the unwieldiness, try Groovy. It's Java with a ton of syntactic goodness added…
As I said earlier.
"Secondly I don't mean to criticize Java. By calling it a toy language, I was simply referring to the fact that Java tends to make writing bad code difficult, and in doing this takes away some of the flexibility and power that you tend to associate with other languages."
Judging from the general reaction it seems I should not have used the term "toy language". My apologies if I ended up implying that Java has little practical use.
Re: I don't like Python. Does that make me a bad person?
#76Earlier quoted context omitted.
This is the main draw for me. Compared to Python, other languages (well, some) seem to require you to do so many things that just seem... unnecessary. I couldn't believe all the junk Java required of me when I took a stab at it. It's like being confronted with some unhelpful bureaucrat: I know what I mean, they know what I mean, but they're damn well going to make me trudge through all the nonsense so that what I mea…
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.
Here's a translation of that to Clojure, since I'm learning that now:
(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)
Re: I don't like Python. Does that make me a bad person?
#77I started off hating Python as well. I could not stand a language that didn't terminate statements without semicolons! :) And python just seemed a lot like Perl; when using both languages for large projects my code just seemed to degenerate to "hacky." But I've grown to like the simplicity of Python. One thing I don't like is its threads implementation, however. Because of the GIL, multithreading (GUI + background th…
The Right Way for a long time was to run multiple processes. If you absolutely needed threads, then the Other Way That Is Less Correct involved launching threads written in C from a C extension The Python community seems to be warming to the importance of threads. There are several efforts breaking their swords against the GIL nowadays (Unladen Swallow being the most prominent), and Antoine Pitrou wrote a new GIL to…
If someone were to submit a patch nuking the GIL, I doubt it would be a language change, ergo, the language moratorium (a block on new syntax) does not apply.
Re: I don't like Python. Does that make me a bad person?
#78Earlier 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.
It makes it harder to correctly do operations on code as text, eg, inserting a chunk of code from elsewhere or moving it out from or under an "if" statement. I have trouble with this occasionally working in emacs at least.
Re: I don't like Python. Does that make me a bad person?
#79Earlier quoted context omitted.
I use auto indent on python all day. Not having to perform secondary bracket mark up is great.
You don't, because auto indent for python doesn't and can't exist.
You say this, and get points, but I'm not sure what you mean. I've written Python and gotten each new line to automatically indent to the proper point, with a functional backspace that unindents the appropriate amount. I've then copy-pasted blocks with several different indentation levels that were automatically adjusted to the surrounding code, with the possible exception of an error corrected by a single keypress.
To my knowledge, this is no worse than the expectation for a braced language, but much better than the worst case for a braced language.
If you mean something simpler than I've taken you to mean, e.g., the conversion of a whitespaceless C program into a whitespaced one, I concede you are mostly correct (';' still works in Python), but I must admit I would still not yet see your point.
Re: I don't like Python. Does that make me a bad person?
#80Earlier quoted context omitted.
c++ feels incredibly bureaucrat to me too though. like separating definition from declaration into header files. what do you think of ooc-lang syntax? http://ooc-lang.org/
I think the header-file and source-file distinction was more of an architectural decision (so that you could implement an efficient compiling and linking system) than a language design decision. Just an opinion, though.
of course it was architectural, but that's precisely the problem - why are we still using a language designed for an age of computational scarcity?
another example: functions should be virtual by default.