11 ms·

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

151 points by thedigitalengel 16y ago

I don't like Python. I love C. I like C++ too. I used to write a lot of Java when I was a kid (as in high-school kid) but now that I've written quite a bit of C and C++, Java seems more like a toy language. I did enjoy Java back then, however. I yet to do any major work in C#, but it seems to be a powerful language, especially when handling certain kinds of complexity. I've been learning LISP on weekends for two weekends now, and I find it interesting. I know little bits of Haskell (am planning to learn it later this year) and seem to like it too. Maybe I like the idea of liking Haskell, I'll know for sure once I actually start writing Haskell. Coming back to the point - I don't like Python. I've never liked it. I've tried working on various Python projects but have always found some or the other excuse to prematurely back out. And mind you, I love coding - I spend most of my time writing code or learning new stuff about code. My question to the hardcore python lovers is this (and mind you, by hardcore I mean the kind of people who wrote Exaile, not the kind who hack up a Python script every now and then to organize their iPod): No doubt many of you have come from C / C++ / LISP backgrounds. What is the paradigm shift you experienced? I look at a piece of C code in a certain way - how do I look at a piece of Python code? How do I think about Python? How do I think in Python (copied that one from Bruce Eckel)?

grails4life 16y ago
No.
HarrySimons 16y ago
I hate Python too, only because of its insistence on indentation and because of its verboseness relative to, say, Perl. I'm not against the non-Perl philosophy of There Is Only One Way To Do It, but for God's sake, don't insist on indentation! I am under a personal vow that until Python lifts its indentation requirement (say, via a command-line switch), I'm no way using this language for my programming needs.
- jsankey 16y ago
  I've never understood this objection. Do you not indent your code anyway? If so, why should you also need to delineate scopes in another way? Python allows you to choose your indentation, it just requires consistency: something that is always required by coding standards (with good reason). If there was a command line switch, would you use it? Why?
  - melling 16y ago
    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.
    - edanm 16y ago
      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.
      - util 16y ago
        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.
        edanm 16y ago
        This does get to be a problem with people not indenting consistently. I.e., some code using tabs and some using spaces, and then copying between them. Technically, your editor should take care of that for you, but some of them don't do it properly (and sometimes can't do it properly), and it really sucks. Well, everything has a downside :)
      - melling 16y ago
        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?
        edanm 16y ago
- Jach 16y ago
  First, to the topic question, I'm not qualified by your criteria to answer the question, but I'll say anyway that I prefer doing video game programming in Python for 99% of the tasks that come up compared to C++. (For example, the PyGame wrapper for SDL just feels a lot better than the C++ interface, plus it adds some nice features.) My own take on mental models can be simplified with the example of strings. In Python, I can think of a string as a string, or a word, or a sentence, or an iterable list of characters. In C, I can't ever forget that it's all pointers. Python lets me think at higher abstractions more readily from looking at code. Plus I really love dynamic duck typing. And to the parent: I really hate to be "that guy", but can you give me an example where non-indented code looks better than indented code (since all your complaint really is about is style rather than what Python can help you do)? If it's just braces you're after, Python "supports" those by just commenting them out. When I first learned Python years back I was coming from a PHP and some Java background, and my code was sometimes single-space-indented, sometimes not indented at all, and it was hideous. After I realized I should be indenting anyway, Python made a lot of sense, all these languages with braces or 'end's everywhere didn't, and I can't think of any case I've ever thought "Man, I wish I didn't have to indent here." The one thing I can say I don't exactly like about Python now is the occasional self-hell.
  - bad_user 16y ago
    Sometimes I have trouble when breaking looong lines of Python code in multiple lines ... like for example when I have method chaining. I don't like long lines of code, it makes the code unreadable. Of course, most situations can be solved by a backslash-enter, and simple statements can be separated by ; but there are places where I wished for more flexibility. This is only about readability, and overall Python code tends to be more readable than in other languages, although I've read beautifully written code in Java or Perl or C++, and the readability really depends a lot on the programmer writing it. I think the major problem is the lack of focus in high-school / college on such things ... quite the contrary, many teachers are usually disconnected from real-world projects and don't have this skill themselves.
    - birken 16y ago
      Google python style guide has a very good way of dealing with long lines: http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Line_length#Line_length 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.
- dnorris10 16y ago
  The only reason I have had lately to get annoyed at Python is when one of the guys I'm working with on a project was using an editor where the tabspacing wasn't set correctly. That meant anything that he changed/added led to the script not working. Even though this was an easy change (=G in vim), it's still annoying to think that such a minor issue would completely kill the script. Of course I prefer Ruby, but that's a whole other can of worms :)
- cookiecaper 16y ago
  The indentation is not a big deal at all. You indent your code anyway, right? Python doesn't enforce a specific standard, you can indent however you want, just as long as you use the same units of indentation consistently. The only time I've had a problem with indentation is while copy-pasting things, occasionally that can get messed up and be annoying. Everything else is fine.
  - RodgerTheGreat 16y ago
    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 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: for(i=0;i<10;i++) { for(j=0;j<10;j++) { for(k=0;k<10;k++) { printf("%d %d %d\n",i,j,k); } } } (Not to mention more in keeping with the principle of "alignment".) Still, if nonstandard indentation can make it easier to see the patterns in your code, it benefits both development and maintenance.
    - thedigitalengel 16y ago
      Would it not be better this way: for (i = 0; i < 1000; 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 = 0; i < 10; i++) { foo (i); for (j = 0; j < 10; j++) { foo (i + j); for (k = 0; k < 10; k++) { foo (i + j + k); } } }
      - RodgerTheGreat 16y ago
        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 < grid.length; x++) { for(int y = 0; y < grid[0].length; y++) { drawTile(grid[x][y], x * tileWidth, y * tileHeight); } } There are other ways to refashion this as a single loop, (storing everything in a 1d array and handling the dimensioning ourselves, using an iterator and giving tiles a position attribute containing their (x,y) coordinates, etc) but is any of that really more straightforward? 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 < grid.length * grid[0].length; t++) { int x = t % grid.length; int y = t / grid.length; drawTile(grid[x][y], x * tileWidth, y * tileHeight); }
- gaius 16y ago
  In C and C-like languages, you have indentation for the humans and curly brackets for the compiler. Python simply unifies this into a single convention. Both parties "see" the code in exactly the same way. If you see someone else's code, there's never any ambiguity about what they meant.
- T_S_ 16y ago
  I'm glad I don't have to read your code. But I don't believe you should be downvoted. Only reformed. ;-) BTW in haskell whitespace is optional but nobody write code that way.
amix 16y ago
Yesterday there was an interesting link on HN comparing NLP in Python vs. other languages: http://nltk.googlecode.com/svn/trunk/doc/howto/nlp-python.html 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.
- paulgrahamsmom 16y ago
  As my boy would say, if you aint using lisp yous using blub, and blub programmers get a spanking!
- nudge 16y ago
  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 mean is turned into something the bureaucracy understands. The linked NLP examples are great for illustrating this.
  - thedigitalengel 16y ago
    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.
    - exit 16y ago
      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/ http://ooc-lang.org/
      - thedigitalengel 16y ago
        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.
deleted 16y ago
[deleted]
l4u 16y ago
Do you hate scripting languages in general? Maybe you should compare python with other scripting languages.
- paulgrahamsmom 16y ago
  Maybe you should use lisp, like my boy says to
- thedigitalengel 16y ago
  I don't have much experience with scripting languages - I've only written some bash scripts to automate stuff (other than Python, of course). Unless, of course, Brainf*ck counts as a "scripting language". :D
- squidsoup 16y ago
  I really dislike the term "scripting languages". While you could describe Python and Ruby this way, it does them a huge disservice, implying that they aren't capable of large scale application development. I think this term should really be reserved for Bash et al.
  - prodigal_erik 16y ago
    I read "scripting language" as a legitimate warning about tradeoffs that make it unsuitable for high-volume use, because the code is permitted to change so much runtime behavior that most known optimizations (and other kinds of static analysis!) are ruled out. For example, Twitter's Ruby to Scala migration made news, so there's value in being able to broadly say what's different between those kinds of languages.
pyober 16y ago
Before I ever encountered Python, I'd gotten pretty familiar with a wider variety of languages than C, C++, and Java. So if you don't have to learn Python right now, maybe you should first learn Lisp, Haskell, or whatever else you want or need to learn that isn't much like C/C++/Java. I think you'll have more fun this way. :-)
paulgrahamsmom 16y ago
Did you read what my boy said about Python? He said they are smarter programmers. Who do you think you are?
- cookiecaper 16y ago
  Let's leave the meta-memes on reddit. This is a little bit personal to be funny imo anyway.
  - paulgrahamsdad 16y ago
    Hey, dont talk back to Paul's mother. Shes had a hard enough life raising a kid who cant decide if he is a hacker or a painter.
shib71 16y ago
Preference for languages can take into account everything from the syntax to the libraries to the community. It's not surprising when someone has strong opinions about them. The problem is when people get precious, but you seem to be straight up about it. And with C and C++ you certainly won't suffer because you aren't a Python guy.
deleted 16y ago
[deleted]
- paulgrahamsdad 16y ago
  My son doesnt like Java, is he a bad person?
Estragon 16y ago
Yes, you're a bad person. We're assembling a re-education camp for People Like You right now.
experimentor 16y ago
Python is a great language. But there is nothing bad about preferring one language/style over another. There are great programmers in all the camps. Try the other two scripting languages - Ruby and Perl. I would prefer Ruby. See if you like the way things are done there. If you find that you are more at home with this language than Python, try analyzing what makes you prefer it over Python. I would suggest you to start with the basics of the Ruby language, and then try building a simple web app with Sinatra. I find the Ruby style much more comfortable than Python. But if you don't like any of these languages, its still well and good. If you get can shit done with C#, thats all it counts.
paulgrahamsdad 16y ago
I hate Blub. I taught Paul about Blub when he was just a boy. Mainly, the bigger kids would tease Paul for being such a geek, so to make him feel better I would tell him that those kids "where all just a bunch of Blub programmers!"
messel 16y ago
http://tryruby.org http://tryruby.org You'll probably still dislike it. But at least you can feel more comfortable comparing python to something. I prefer Ruby, but appreciate Python and Perl. I come from C/C++ coding for 14 years.
l0nwlf 16y ago
"My question to the hardcore python lovers is this (and mind you, by hardcore I mean the kind of people who wrote Exaile, not the kind who hack up a Python script every now and then to organize their iPod)" I'm disqualified to answer - as I come in your so called second type (softcore python lover perhaps), people who uses python to fix things in day to day life.
thejbf 16y ago
Languages fit you if your tasks are fitting to those languages. As far as I can see as a C/C++ programmer you should have been involved more lower-level issues rather than writing software standing on several frameworks. Java is not a toy language but it handles the stuff you were used to deal with almost automatically so it feels like it is. So what kind of programmer are you? What do you develop? These questions are essential before making any advise.
- thedigitalengel 16y ago
  Currently I'm a student and question of what kind of a programmer I'm is wide open. I am currently working on a project that has to do with the GC and the JIT compiler for a language runtime. I plan to use my (remaining) student years to gain as broad a programming experience as I possibly can, not because I wish to be good at everything but so that I don't miss anything out. The whole point of this post was to find out that since virtually everyone finds Python so bouhaha and I don't, am I doing something wrong? 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. I mean while (str++) str = (str) + 1; becomes for (int i = 0; i < sb.length (); i++) sb.setCharAt (i, sb.charAt (i) + 1); // and relevant casting While the above piece of Java code can be improved and condensed (for instance, by calling getChars and iterating through them* and then creating a new String - would be slow however), I think you get the point.
  - thedigitalengel 16y ago
    It seems some of the HN eats up some of the asterisks. But you get the idea.
est 16y ago
> I like C++ too I never met a hardcore C++ guy claim they like C++ > by hardcore I mean the kind of people who wrote Exaile I think Python weren't meant to write desktop music players. Stuff like Zope are hardcore.
- thedigitalengel 16y ago
  I never said I was a hardcore C++ guy. :) I'm more like a hardcore C guy. I do know a fair bit of C++ though. Perhaps C++ would've been better if compatibility with C was not kept as a fundamental goal. Just a personal opinion. Qt does an amazing job of taming C++. I used their framework for some GUI design and loved it.
  - olliesaunders 16y ago
    I think what he is saying is, if you program enough C++, you'll grow to dislike it.
twism 16y ago
I was in the same boat as you before, but it is now my "go to" language. It happened when I started using django. Just humor yourself and go through this tutorial: http://docs.djangoproject.com/en/dev/intro/tutorial01/ http://docs.djangoproject.com/en/dev/intro/tutorial01/ Don't copy and paste the code in the tutorial and when they ask you to type something in the REPL, do it. That's when it all started for me.
- messel 16y ago
  I was looking for a smooth way to ramp up my Python (very weak). Just had a little experience with it from the friendfeed api v2 on the app engine.
exit 16y ago
what don't you like about it vs python? it could be easier to respond to some specific issues.
gte910h 16y ago
I'm a guy from a C/C++ background who did linux kernel development, and picked up python along the way and used it to do desktop tools. I used python (without knowing any of it) to write a disassembler for a project I was doing in 2003 on a non-x86 processor. It took me 5 days to learn the language enough to do so and to write the entire tool, at which point I "got it". First off, Java isn't a toy language. You've characterized it improperly. Java is a bureaucratic language. You have to cross your t's dot your i's, fill out your requests in triplicate at the FactoryFactoryFactory to get the objectOfYourDesire. Why is this so? This comes back to how C++ works on projects, especially large projects and midsize projects with a couple mediocre programmers thrown in (because, in commercial software development, you rarely get control of your team). C++ does not work well for large team development unless 1> You have very capable people 2> and you can fire everyone who steps outside the "defined okay subset" of C++ you use on the project. The language is too big, certain parts make it too uncertain, etc, for people to just willy nilly use all the language features. So Java, is basically Sun's "redoing" of C++ where they took its wild west nature, and made a BureauDisney version where you can't do a dozen things that happens in C++ all the time when good programmers go off the reservation or bad programmers enter the equation at all. C++ has uses, but it's the sulfuric acid of programming languages: you have to have good personnel control and fire those who screw around outside the boundaries of the right style. A programming group with one guy programming like C with classes and another guy programming like it's Ocaml without garbage collection, and you're in for a mighty piece of hell. So that's where Java came from. That's why it is what it is, and I hope I've highlighted a non-business issue with C++ that comes up from it's overabundance of "understanding breaking powers" which don't mess well with total programmer freedom. Now lets look at what python was, and what it is now: Python was originally designed as a substitute for the pascal/BASIC line of programming languages (specifically a language called ABC). It was designed to be very very clear. It still is very very clear. It is still quite terse compared with C++/Java/C, but it's wordier than perl and ruby, but very much clearer for even non-python programmers to decipher much of the time. Over time, it grew into an Application development and webserver development language. Why? It has a very easy way to interface to C code. This is important, because C does great module level integration, but once you get at the system level, you start to get issues with namespaces, tracing bugs, etc. So python became an alternative for tying C code together. It writes very quickly. While you may not understand how to write it quickly yet, usually python/ruby/perl will be quite a bit more productive on a feature basis than Java/C#, and tons more productive than an equivalent C/C++ project. This has to do with the fact it takes very few lines of these languages to "do a job". For you currently, you're possibly less productive in python right now than you are in C++; I've honestly found this doesn't hold true more than 40-80 hours into learning python development while doing a real project for almost anyone who can handle commercial C++ software development. The C++ people do python faster than they do C++ and it has many fewer issues in the end than C++ they would have wrote. We use weave.inline or something else to speed up the inner loops with some native C, if even required for that application, and all is good, it works just as fast for the user or application, and was completed much faster with much less obtuse bugs. If you spend those 40-80 hours on the language, you too will likely be a faster developer in python than C++ for many features. Some tips: You are not doing C, you are not doing C++, you are not doing Java. Don't pretend you have to do the bueracracy that those languages require. If you write a python program with absolutely no functions, it will run just fine. So if all you need to do is process a small amount of text or open a little server, you can do this in a flat file with just a series of lines of code striaght out of main() in a C program. However with the size and completeness of the python standard library, you'll rarely have to write the rest of the functions. Secondly, it's important to learn idomatic python today. If you write things like "it's supposed to be" in python today, you get speed on par with C/Java (or only 3-5x slower), and it's really freaky to see an interpreted language do that. Thirdly, it's important to learn and use the standard language rather than writing code. Python module of the week blog is a great resource to do this: http://www.doughellmann.com/projects/PyMOTW/ http://www.doughellmann.com/projects/PyMOTW/ Much of python's power comes from a stupidly complete standard library that does much of what you need to do so allows you to write 20 line programs. Lastly, learn easy ways to fall back on C/C++ in python. This way when you use python for an application it turns out it's too slow for, you can still add a bit of C/C++ to get the speed you need. You can embed C++ inline and have it compiled on the fly with weave, so I suggest you learn that. http://www.scipy.org/Weave http://www.scipy.org/Weave for getting it http://www.scipy.org/Cookbook/Weave http://www.scipy.org/Cookbook/Weave for examples of use http://www.scipy.org/PerformancePython http://www.scipy.org/PerformancePython for examples of how fast this runs vs other things.
doosra 16y ago
I 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 thread) just doesn't work right. Maybe I'm using it wrong?
- jakevoytko 16y ago
  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 help improve contention [1]. With any luck, by the end of the Python Feature Freeze, there will be some significant headway towards efficient handling of threads within Python, but I'm not holding my breath yet ;) [1] http://www.dabeaz.com/python/NewGIL.pdf http://www.dabeaz.com/python/NewGIL.pdf
  - jnoller 16y ago
    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.
    - jakevoytko 16y ago
      I agree. To clarify, I'm hoping that because they're not focusing on language enhancements, they might make some major headway towards nuking the GIL
- eru 16y ago
  > I started off hating Python as well. I could not stand a language that didn't terminate statements without semicolons! :) I have exactly the opposite heuristic for syntax. The only thing worse than semicolons and curly braces, are `begin' and `end'.
deleted 16y ago
[deleted]
terra_t 16y ago
You don't have to like Python. I don't. Of course, I don't have any pretentions of being a "good person" either.
cageface 16y ago
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.
- exit 16y ago
  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.
  - cageface 16y ago
    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 block of Ruby at a glance. Python requires closer inspection. Everything in Ruby is an expression that returns a value whereas Python has statements and expressions and it's up to you to remember which are which. Ruby feels to me like the product of an astute student of languages that borrowed the best ideas from Smalltalk, Lisp, Icon etc. The design mistakes in the first versions of Python, mostly now corrected, suggest to me that Guido didn't do his homework as dilligently. Perhaps I'm way off here but the languages seem to me to show some of their cultural heritage. Python has a blunt & minimalistic Dutchness about it while Ruby has a Japanese elegance and style.
    - dedward 16y ago
      That's about it - Python has a richer, more refined set of libraries to call on than Ruby. (Ruby also has a ton...) Ruby is more fun,but python is more mature. In the end - whatever gets the job done right?
technomancy 16y ago
If you don't like Python, it may just be an indicator that you know more about functional programming than Guido, which is hardly a feat. Read his opinions about tail-calls for a good laugh.
kbob 16y ago
The paradigm shift is that in Python the most direct way is best. Examples. In Java, accessor methods are considered good style. In Python, directly accessing a member is better. (more concise, makes client code clearer.) If you need to do magic, you can use properties. In C++ and Java, you use inheritance to denote which classes have a given behavior. In Java, you also use interfaces. In Python, you simply give a class the needed method(s). (I.e., you use duck typing.) That flattens or removes lots of class hierarchies. If you need to do magic, you can use isinstance(), issubclass() or hasattr(). In Python, you use the built-in types a lot. Many problems decompose easily to lists, sets and dictionaries. That reduces code dramatically. Java and C++ STL's containers, in contrast, are so clumsy they make me look for ways to avoid them. If you need to do magic, you can subclass the built-in types or build new types with the same methods as the built-ins.
Avataristic 16y ago
I still write most of my code in C. Could never really warm to C++ and Java was fun in the early days, but the sheer volume of API's, J2EE, et al eventually crushed my spirit. It took me several goes to become friendly with Python. I find it excellent to try out algorithms. If I don't know how something is going to be best implemented, then writing a bunch of classes in Python and tweaking attributes and methods until the algorithm is as simple as can be helps me get there very fast.
- CyberFonic 16y ago
  I didn't warm to Python until v2.2. Took an article by Eric Raymond for me to take another look at it and it finally clicked. Great for trying out ideas, etc. But I still write all the heavy duty stuff in C. Its really cool to do the heavy lifting in C and expose it as a shared library and then do the coordination stuff in Python.
flexterra 16y ago
Yes
scelerat 16y ago
Easy language to read, write, and maintain. Big standard library and lots of tools. Win.
zephyrfalcon 16y ago
I've been using Python since around 1996. Back then I had used, or was still using, C, C++, Turbo Pascal, Delphi, BASIC (groan) and assembler. Python was so much more high-level than all these other languages that it was staggering. It was pretty weird to use it at first. Where are all the declarations? What are these "lists" and "dictionaries"? You mean I can just stick any old thing in an object or even a class? Etc. Soon it became obvious how much more powerful this new language was, and I enjoyed replacing reams of Pascal/C code with a few lines of Python. I tried to use it at work too, but failed because it was considered "unmaintainable" by the powers that were (this was around 1999-2000). Of course, this just fueled the feeling of having an obscure but superior language rebelling against the big evil statically typed empire. :-) Anyway, this used to be some of the appeal of Python. I suppose it still applies to some extent, although since then, Python has been passed left and right by languages that are more powerful, more flexible, more functional, more "fun", and whatnot. Nowadays there seems to be a meme going around claiming that e.g. Ruby is fun and flexible, while by contrast Python is boring and conservative. It wasn't always like that. I distinctly recall people discovering Python and exclaiming that "programming is FUN again!". Then again, all of these things are in the eye of the beholder, mostly. If you don't like Python, no big deal, especially if you have both lower-level (C, C++) and higher-level (Lisp) languages at your disposal. (Personally, I used to think that Ruby was butt-ugly and uninteresting... these days, I have taken more of a liking to the spirit of the Ruby community, which (perhaps ironically) reminds me of Python's in the 1990s.)
neutronicus 16y ago
I don't much like it either. Came from C++, learned Perl, got a job writing Fortran, learned Lisp. When hating on Perl came into vogue on the internet, I said to myself, okay, I will learn Python as a Perl replacement. It is a decent Perl replacement, what with all the libraries and the fact that it is shebang-able. Now that I've dispensed with background, what I don't like about Python: 1. Assignments don't return values. I hate this. An example. I would like to write: if (m = re.match("woo, regular expression")): do some stuff with match object Instead m = re.match("woo, regular expression") if m: do some stuff with match object This obscures the fact that I only care about this match object if it evaluates to true. 2. List comprehensions kind of suck. [(a, b) for a in as for b in bs] is a cartesian product and not a zip? Really? 3. Loops don't help this either: There's no equivalent of the Lisp (loop for x in xs for y in ys do (stuff x y)). I have to explicitly loop over the index. This pisses me off. 4. I feel that I am generally shoehorned into creating and assigning more objects than I would like. Honestly it seems kinda crippled in comparison to Lisp, which, by the way, runs faster. I would go back to Perl if multidimensional arrays were not so godawful. Perhaps I should try Ruby.
- eru 16y ago
  Perhaps `zip' could help address some of your points? > 2. List comprehensions kind of suck. [(a, b) for a in as for b in bs] is a cartesian product and not a zip? Really? Strange. I would say it sucked if it was the other way round. You can use the `zip' function, if you want a zip. zip (as, bs) > 3. Loops don't help this either: There's no equivalent of the Lisp (loop for x in xs for y in ys do (stuff x y)). I have to explicitly loop over the index. This pisses me off. Try the function `enumerate' and `zip'. E.g. for x,y in zip(xs, ys): stuff (x,y) If you need an explicit index for your stuff: for (i, (x,y)) in zip(xs, ys): stuff (x,y) > 4. I feel that I am generally shoehorned into creating and assigning more objects than I would like. I agree, only the other way around. Python is much too destructive and relies on in-place updating. E.g. recently we got `sorted' that doesn't sort in-place but return a sorted array --- but the `shuffle' function still works only in-place. Also dicts are destructive. There should be a persistent (i.e. non-ephemeral) data structure for key-value-mappings in the standard library.
rue 16y ago
I think an exhaustive answer is "mu". Focusing on the tools instead of the problem is bad.
deleted 16y ago
[deleted]
- waterlesscloud 16y ago
  What's good about C++ is that I know it well, so it's comfortable for me. Why someone just coming to it now would like it, I couldn't tell you. I will say that when I came to Python I felt much lighter and faster as programmer. You forget how it can be. And starting into Clojure recently just feels more "right". I avoided Lispiness for a long, long time, but Clojure seems to hit the proper balance for me.
j_baker 16y ago
If you ignore the fact that this page is a bit biased towards python, it is a pretty good intro to Python if you're coming from a C++ or Java background: http://dirtsimple.org/2004/12/python-is-not-java.html http://dirtsimple.org/2004/12/python-is-not-java.html My personal experience is that the Java-ish languages encourage you to overthink problems a bit. Instead, I suggest that you just do what comes naturally. This will actually get you pretty far, as Python doesn't have that many gotchas (at least in comparison to Java or especially C++).
endtime 16y ago
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.
Aegean 16y ago
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
- mkramlich 16y ago
  Agreed. And interesting you said C and Python. A few years ago I was thinking about what would be the minimum set of languages that would be good to know in order to be able to do almost anything you wanted, and do it well, and to always be employable. I ruled out 1 language alone because of the C phenomenon: there's a whole class of software where today C is the best choice, and a whole different set where C is a bad choice. Therefore, the ideal set was 2+ with C being one. I ended up settling on C, Java and Python. Java for enterprise/BigDumbCompany work, but also because there's a lot of great tooling and innovation happening in the Java space more so than other langs. Python for the role of glue and prototyping and high level no boilerplate bureaucracy but where you could still trust every developer using it. Ruby could probably fill that role decently instead, except be a little better or worse in diff areas. C, Java, Python Then I found out that Google had picked these three as well. Nice!
  - kragen 16y ago
    No, Google picked C++, not C. Very different philosophy!
    - mkramlich 16y ago
      Thanks, looks like you may be right. I just found a post by Steve Yegge in 2007 where he said it was C++, Java, Python and JavaScript. I'm pretty sure I found references elsewhere to C/Java/Python though. Close enough. I had forgotten about JavaScript, I guess I considered that one a no-brainer on the browser side. However, the line blurs between C and C++, especially if you use the extra stuff only tactically as needed rather than a hard-core-always-OO-and-templates approach.
njharman 16y ago
The biggest revelation Python gave me is peoples thought process/problem solving process/whatever you want to call it (I call it brains) work differently. And importantly peoples brains are wired to work really, really well with specific language qualities(dynamic, functional, boilerplateish) as manifested in specific languages. But really poorly with other qualities/languages. So, no you are not a bad person. If you've given Python a honest attempt (took me a year to do that, I had whitespace hangup that was hard to get past), then you aren't missing anything either. Python just isn't the language for you. Move on, be happy.
scorpion032 16y ago
Python people are too busy solving real world problems fast and quick and getting their shit done, to fall in love with python. Tools are just tools. And I don't mean to come across as a jerk. I love developing. But that is as a means to an end, but not as an end in itself. - Those who like the latter, end up as research scholars; or Rubyists.
jcapote 16y ago
Nope, I fucking hate python.
KirinDave 16y ago
A lot of us don't like Python. It's a language with a mediocre design, a somewhat frustrating syntax, and a stubborn refusal to commit to such essentials as real closures and lambdas. It's basically a language written by a group of people who don't trust you (as a Python user) to be knowledgable and educated. Decisions have been made based on the assumption that you are bad at your job. Now, everyone seems to comfort themselves with the notion of making it “easy for maintenance”; repeating “I am smart, surely, but not everyone can be as smart as I am.” But this is ultimately a dodge that feeds into the problem endemic to our industry: a disdain for everyone else and everyone else's methods if they differ slightly from our indoctrinated best practices.
- lelele 16y ago
  > It's a language with a mediocre design, a somewhat frustrating syntax, and a stubborn refusal to commit to such essentials as real closures and lambdas. I agree about closures, but why lambdas would be so much better than named functions (already available)? I think named functions help code readability, which is among Python's top goals.
  - KirinDave 16y ago
    > I agree about closures, but why lambdas would be so much better than named functions (already available)? Because sometimes you want to conditionally create functions on the fly. Named functions are a very awkward way to do this. It is unfortunate that we even have to have this argument. Anyone with significant experience in functional programming can tell you how useful unnamed functions are. And it's important to realize they are not necessarily anonymous in local scope. They're anonymous in the global scope. > I think named functions help code readability, which is among Python's top goals. Anonymous Lambdas need not be a detriment to readability. Why do you think it would be otherwise?
Kaizyn 16y ago
Programming languages all come with a specific mental model for how you're supposed to code in the language. That's why it's so useful to learn different types of languages so that you "pick up" those different ways of thinking. Everybody thinks differently so not every language is going to suit the tastes of every developer. You may find that Lua or Ruby are a better fit with your thinking patterns and that you are more productive using one of those as a scripting language of choice. The power of scripting languages really come down to a very simple thing: each line of code in a scripting language is equivalent to roughly 5 to 10 lines in a systems programming language. You're doing the same mundane programming tasks but with fewer lines and getting nearly the same performance as if you had written the code in one of the systems languages. It really won't make much difference which one you use, you'll see the same productivity gains using Perl, Ruby, Python, Lua or practically any of the others. However, the more obscure the language you choose, the fewer developers and the fewer available libraries to use.
expeditious 16y ago
Python's alright, but it made me work too hard for what it does. I tried hard to like it but using Python for writing scripts I was constantly asking it, "why are you making me do extra work? Perl doesn't make me do half the crap that you ask of me" (ex. regexes, quoting, string interpolating). Also, Perl has the CPAN, so, I fired Python and use Perl.
ahoyhere 16y ago
I don't like Python, either. There's nothing wrong with disliking Python - there's lot to dislike. There's also a lot to like, for a certain kind of person - e.g. not you and me. It's an aesthetic and personal choice.
3KWA 16y ago
A programming language is like a screw driver, the brand doesn't matter but what you do with it!
kunley 16y ago
Disclaimer: I'm not saying this to start a holy war... Try Ruby. It gives much more freedom than Python, not to mention countless way of shooting oneself in a foot (which you know already from the C family ;)
adamilardi 16y ago
yes

alphamerik 16y ago

I do indent my code, but I prefer to auto-indent. Using indentation to determine if a line of code falls inside or outside some logic block requires a lot more effort for me. Would much rather just use curly braces. Curly braces also make copying and pasting code blocks much easier.

nailer 16y ago
I use auto indent on python all day. Not having to perform secondary bracket mark up is great.
- maw 16y ago
  You don't, because auto indent for python doesn't and can't exist.
  - crystalis 16y ago
    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.
    - maw 16y ago
      If you write code like this: if x: # do stuff # do other stuff Your indenter will not know where to put the third line. In languages whose blocks are closed using nonwhitespace the problem doesn't exist. Your indenter just has to push everything as far to the right as it can, and problem solved. It's nice that your editor gets copy and paste right, but it doesn't and indeed can't decide how to indent your code, something that works in every other language I've dealt with.
      - crystalis 16y ago
        Why does that matter? In brace language: if (condition) {{ code_1 }} code_2 In Python: if (condition):\n code_1 \n^H code_2 Unless your editor also knows when to place your close braces, and, haha, it doesn't and indeed can't, you have not even won a keystroke.
        maw 16y ago
        Once I've placed my closing braces, I'll never need to think about it again, unless and until I restructure that piece of code. It's got nothing about saving keystrokes. And now, back to working on pass-infested Python code.
  - jonknee 16y ago
    I think he means in his editor. I do the same, it works well.
  - gcr 16y ago
    Are you sure? A counterexample: My editor indents every line that I end with a colon (:). So I just type : and <enter> and have a new indent. When I want to unindent, I just type backspace to go back one tab. This is simple to implement and understand, and with python, it's really all I need. This kind of "automatic indentation" (colon-enter to indent, a quick backspace to unindent) feels much more natural to me than a C-style indent, where the editor's cue to indent would be space-rightbracket-enter and leftbracket-enter to unindent. True, one cannot come accross a completely unindented block of python code and ask the editor to format it correctly for them. But by definition, unindented code is not valid python and will not run. This is not unlike C / C++ / Java code that's missing all its braces, which would not run either.
  - koenigdavidmj 16y ago
    Vim does pretty well. On starts of blocks (when I hit : followed by return) I get an indent. At the usual places that would end a block (return, raising an exception, break or continue) I get a dedent automatically.
T_S_ 16y ago
Whitespace doesn't help you write code. I helps you read code, which is a lot harder writing it, even though it seems like it should be the other way around. 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.

cageface 16y ago

Python's whitespace indentation seems like a great idea until you realize that it makes things like copying & pasting code from web pages etc far more difficult and, worse, makes automatically reindenting a block of code in an editor impossible. If I come across a badly formatted block of code in Ruby or Java or C in emacs it takes me one keypress to sort it out. In Python I have to carefully, manually look at each line. It's also fun to spend an hour looking for a bug caused by somebody inserting a tab instead of a space somewhere. We had a production crash that took us a long time to fix because somebody hotfixed a file with the wrong editor and did this. I also don't understand how forcing people to indent code in the same way magically makes people write good code. The kind of programmer that can't or won't indent his code properly is introducing bugs far more serious than bad layout into your project. Python's a nice language in many ways but I consider the syntax to be a bug.

dhimes 16y ago

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 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.

dfox 16y ago
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)
- dhimes 16y ago
  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.
  - sanderjd 16y ago
    Interesting about objects in javascript. I have actually started feeling that prototype-based object orientation is less tacked on than its class-based cousin. The syntactical implementation is a bit strange (the 'function' keyword for objects, putting functions on the prototype object rather than the object itself), but the mechanism itself seems more generic and flexible. The implementation in Io is better I think, you should check that out before discounting prototype-based object systems outright.
    - dhimes 16y ago
      Oh, I won't discount them (I'm not good enough to be a prima-donna about it), and it's nice to know that I will see how to use it to my advantage as I play with it more.
  - brunoc 16y ago
    >> 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 think you can divide into those who use the `new` keyword and build objects that are more or less Java-like classes and those who create objects and prototypes on the fly, and probably use a lot more ideas from the functional and LISPy side of things.
    - dhimes 16y ago
      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() ).
  - dfox 16y ago
    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 (as is the case with ST). On the other hand most uses of design patterns in Java code (eg. 90% of uses of Observer pattern, especially in cases when it is called Listener) seem to be to be compensating for fact that Java is not Smalltalk(/JavaScript/Ruby/Python/C# whatever with first class classes and methods). JavaScript is language that is very different from anything else. Depending on how you look at it it has either unconventional semantics (majority view) or unconventional syntax (my view). It's object model is strong and often useful (you can emulate class-based inheritance with it, not the other way around), but I agree that it is to some extent afterthought (although I have strong feeling that our reasons are very different). What is probably largest problem of whole JS is the "Java" part of it's name and weird syntax deliberately designed to "look-like-Java" or "look-normal", which simply does not match underlying semantics. Coming from C/Unix background I actually consider the IDE thing burden in itself. I expect that there are some easily editable source that is transformed by series of some steps into final program, but all changes happen only in the original input. Which is simply not case in Java/ST world, where you essentially need pretty complex IDE (on the side note: few years ago some Java IDE I was using for quick experiment forbade me from saving source file with syntax error with it... WTF?).
    - dhimes 16y ago
      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.
donaq 16y ago
Urgh, I learned Java in school and recently had to use Java at work to do some stuff with a bad XML schema (think lots of "<parent><child><grandchild_1 /><grandchild_2 /><grandchild_3 /></child></parent>" wtf is element "child" for??). I used XStream for it, and started off trying to write the objects the "right" way, i.e. with private members for child nodes and getters and setters for them. However, having drank deep of the Python well, I got about 20 minutes into it before I realised that my time was better spent writing the actual logic of the app and did a :s/private/public/g. The pain from my ulcer faded almost immediately. :) *I realise that pro Java coders use Eclipse to generate their getters and setters, but I have also drank deeply of the vim kool-aid and find myself going to ridiculous lengths sometimes to avoid other editors or IDEs. I keep trying to navigate with the wrong keys and trying to save with :w and using :sp to open other files when I use them.
- dhimes 16y ago
  One thing to look out for here is this: if you are writing getters and setters for primitive data types like strings and ints and stuff you're doing it wrong. Instead of public Customer(String name, int custId) do public Customer(CustomerData cd) where CustomerData is an object. In Customer you would have getters and setters for CustomerData rather than each item that identifies your customer. This is for extensibility: As your app grows, some part of it may need other ways to identify the customer. Adding these ways won't break your Customer interface. That's the purpose of the rigor of the design standard. Now what I do, which goes against stated policy, is keep the CustomerData variables (String name, int custId, and so on) public so I can set them easily. The only time I require getters and setters for primitive types (for example, name) is if I were to read in data from a user generated form that needed to be sanitized. My apps are full of these customized data objects, and it's a technique which has saved my ass as I added features etc.
  - sqrt17 16y ago
    ouch. If you encapsulate all the data about a customer in a "CustomerData" object, do you really need a separate "Customer" object? Or do you mean, not the whole customer but larger bundles of information like addresses etc. that don't need any business logic or abstraction but are nice to have as one single bunch of data? (I mean, there's a reason why C++ still has "struct"s even though OO zealots will tell you they come from the devil).

TrevorBurnham 16y ago

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; 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.

thedigitalengel 16y ago
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.
- cabalamat 16y ago
  > Java tends to make writing bad code difficult I've known people who could write bad code in Java with the utmost ease! It'd probably be more accurate to say that Java deliberately limits its expressiveness, in order to make it harder for people to shoot themselves in the foot, and to make it easier for one programmer to understand what another has written.
  - thedigitalengel 16y ago
    > It'd probably be more accurate to say that Java deliberately limits its expressiveness, in order to make it harder for people to shoot themselves in the foot, and to make it easier for one programmer to understand what another has written. That is exactly what I meant. Bad programmers exist. They will write bad code, no matter what language they're made to use.
- strlen 16y ago
  > Java tends to make writing bad code difficult If this were actually the case, it would be a bonus point for Java. It isn't, however. Nor is it the case for Python, Ruby or even BSDM languages like Ada. How many times have you come (when searching for a used car or trying to reserve a table at a restaurant) to a slow, ugly, non-functional URL that creates an error message if you press the wrong button at the wrong time? Usually those URL ended in ".jsp", ".asp[x]" or ".cgi" or ".php". I'd argue, that the largest amount of bad code that exists is in Cobol, followed by Java, C# and then C/C+, PHP and various BASIC dialects. That has nothing to do with how good those languages are but rather with the facts that most code out there: a) is created by IT departments or outsourcing firms staffed by mediocre or completely disinterested programmers (I've never been in such an environment, but my hair stands up every time I read horror stories on dailywtf or on progit) b) shouldn't have been created in the first place (there are commercial and open source packages that do this) if it weren't for the NIH symptoms. There are tons of restaurants with their own order/registration forms despite the fact that OpenTable is widely known and available. There are tons of non-technology companies writing their own accounting systems even though there's a multi-billion/year industry around that type of software (that employs programmers who understand not just J2EE but accounting itself as well). c) is forced upon its users (due to the sunken costs fallacy) and thus isn't exposed to market forces d) is written in those languages as they're most common and are either easy to learn (PHP, BASICs) or are widely taught in colleges or trade schools (Java, C#, C++) Truth is, there is no magic language bullet. Some languages are more expressive, more pleasant to program in. Some produce faster code. Others are more scalable in the sense of making it possible to write whole systems in one language. Some are more "safe" in the sense of being less prone to garden variety security attacks, less likely to crash the entire machine when there's a bug (at the cost of imposing restrictive abstractions on the programmer). No language, however, is a substitute for a team of competent and interested developers solving a relevant problem.

zepolen 16y ago

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.

thedigitalengel 16y ago

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 similar, I don't remember exactly). Now what is a request? If Django were in C, I would know what a request object really was, grep for it, and look up the header file. If request has a GHashTable named post_data, I don't think I need two guesses about what it exactly is. Same goes for C++ and C#. Then you've inconsistencies. The same method may return a string object or an integer on different calls. And this happens in practice - I remember when I was (trying to) model a relational database in Django, I found a ManyToMany field returning (when invoking values ()) a list of dictionaries instead of a list of Model objects (which I was expecting). Of course, if I was not dumb enough to not read the documentation I might not have stumbled; but the point is that Python allows this to happen. And since I don't have the benefits of a compiler, anything other than basic syntax errors (the ones I can catch by calling py.compile) explode at runtime. The thing I've begun to notice that scripting languages tend to require you to hold the entire structure of the program in your head as you code. In C++ you know that unless you've gone out of your way to do some casting magic, a string get_foo () will always return a string. And you can always do get_foo ().c_str (). In python you're never sure.

loup-vaillant 16y ago
You sound that you will like Haskell. It's type system can be really paranoid (it lets you express many invariants through it), yet remain very flexible. And If you can't fathom the segregation of (side) effects, there's still Ocaml.
- ldsa 16y ago
  OCaml is a dying, soon obsolete, language. Better use F# which has way better libraries and tools.
  - zaphar 16y ago
    As I understand it OCaml is in heavy use at a number of shops in the financial industry. I wouldn't say it was dying just yet. On the other hand F# is a new and as compared to OCaml untried and untested language.
    - ldsa 16y ago
      Number of financial companies using F# is about the same as for OCaml (but numbers are not evolving in the same manner). F# uses .NET which is way more tested than OCaml runtime. F# uses .NET libraries which are way more tested than OCaml libraries. F# core language is still a bit less tested, but considerable work is being done. In contrast, there is only fulltime person working on OCaml. OCaml community is dying, while .NET community is huge.
      - zaphar 16y ago
        .Net being tested is not the same as F# being tested. The idea that the OCaml community is dying is purely subjective. OCaml, having been around longer than F#, may just be going through a perceived lull. Either way generalizing that F# will replace OCaml as the goto language in the ML family from a perceived decline in the OCaml community is probably not the right call.
      - eru 16y ago
        We also use Ocaml here (Citrix), and people agree that Ocaml seems to be going nowhere. Some projects have started switching to Haskell.
  - loup-vaillant 16y ago
    Don't overlook the fact that F# is build on top of a proprietary, potentially patent-ridden platform. For many people, including me, that's a non starter.
wyuenho 16y ago
I'm surprised no one has mentioned Peter Norvig yet. http://norvig.com/21-days.html 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.
japherwocky 16y ago
what makes you think you can't grep for the request object/class?
- thedigitalengel 16y ago
  What I implied was that it was not immediately obvious what the class was. def foo (self, stream): What is stream here? void foo (std::ostream &out) { out << "bar" << endl; } Hope you get the point.
  - japherwocky 16y ago
    So, grep for what's calling your function, or use pdb.set_trace()
duke_sam 16y ago
You seem to be complaining that when using a language new to you in combination with a large framework written in that language you would have been forced to read the (very good) documentation to figure out what was happening. The inconsistencies you mention are (in a well written code base) very rare. If you call a method get_name() odds are you are going to get back a string. If you seem to randomly get back an int or a dictionary or a datetime object it's a pretty good sign the code is foobar'd. Good Python programmers don't abuse the dynamic nature of the language. Methods should return predictable types (documentation is important), it might return different types depending on the input but this should be documented and obvious (say a parse date method that returns a datatime object if you pass it a string containing a date and time). The values() example you use is very clearly documented as returning a ValuesQuerySet that supplies dictionaries not models (http://docs.djangoproject.com/en/dev/ref/models/querysets/#values-fields http://docs.djangoproject.com/en/dev/ref/models/querysets/#v...). In a number of years using python, the standard library and 3rd party libraries I've never been left wondering "If I pass X to this method what the hell type am I going to get back". Just like in C/C++ I need to remember it returns a list or a string or a dictionary but that's usually where the mental overhead stops. Python is dynamic which means it's flexible. Flexibility is usually reached by sacrificing simplicity so Python encourages testing and good documentation. I would argue that these are both necessary features of any good code base, Python is just more upfront about this than a number of languages.
- thedigitalengel 16y ago
  I'm not really not complaining about anything - the shortcoming clearly lies within me and not in Django or Python. 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.
arghnoname 16y ago
This is something I run into with perl/php/python/ruby/etc too. Perhaps I've just gotten used to outsourcing some of my brain to the compiler, but I really like to lean on it to get good results. Run-time blow-ups suck, and I've always preferred using a compiler to writing all these test cases to catch run-time type errors. I really like using a dynamic language for some tasks. I almost never use C, C++, or Java for any task I hope to start and complete within a day. Those jobs are small enough it's easy to keep track of what you are passing around. I spent 6 months writing all of my utilities in Python. I tried very hard to like it, but it just didn't tickle my fancy. I do like perl and ruby for a dynamic language. I think perhaps the issue is, if you are like me and you don't like using dynamic languages for large programs, the extra clarity of python isn't enough of a added bonus.
LordLandon_ 16y ago
> If Django were in C, I would know what a request object really was, grep for it, and look up the header file. If Django were in python, you wouldn't even have to grep >>> import django.http, inspect >>> print inspect.getsource(django.http.HttpRequest)
- vaughnkoch 16y ago
  Or even easier: ipython >>> from django.http import * >>> HttpRequest?? # prints out source code for HttpRequest
kragen 16y ago
I think you just need different techniques for Python than for C. You can write a dummy view that calls dir() on the request object (which will probably tell you how to get the POST data), asks it for its __class__, asks it or its __class__ for their __module__, asks for sys.modules[request.__module__].__file__, and so on. If you just want to know what's in the request object, rather than what its methods are, you can get its __dict__ and print that out, and then you get not just the type of its contents, but an actual example. When you have a REPL and an example of an object, you can call help() on the object and get generally pretty good documentation on And there's the inspect module, like LordLandon_ pointed out, but which I didn't know about. And when the going really gets tough, you can monkeypatch random libraries to change the way they work (e.g. to add logging) in order to debug the problem. All of the above applies to Python development in general, not just Django. Django in particular has several additional advantages: • it has an "interact" mode that pops you into a Python REPL so you can poke at all of this stuff interactively instead of having to save a source file and hop over to your browser; • it has really first-class documentation; • if you raise an exception in debug mode, the traceback includes dumps of all of the objects mentioned on all the levels of the traceback stack, along with a few lines of source code from the stack frame; In short, Python offers much more power to undertake the kind of analysis you were wanting to do than C or C++, but you have to do it dynamically, instead of statically.
lars512 16y ago
To complement what other people are recommending here, I'd say that in cases like this I only sometimes read the documentation. Other times I put a line in my code: import pdb; pdb.set_trace() which makes it enter the debugger at that point, and I simply inspect the object that I'm really getting, looking at what it supports, the documentation on its methods, etc. Doing it this way is not always feasible, since sometimes there's a prohibitive amount of setup code that needs running before you can get a real object. For short code paths though, like Django apps, it works really well.

phsoftnet 16y ago

Why doesn't anyone ever mention my favorite language, Tcl? foreach line [read stdin] { foreach word [split $line] { if [string match *ing $word] { puts $word } } }

sigzero 16y ago
One reason is that people haven't looked at Tcl in a while and so they "already know" what Tcl brings to the table. There have been a lot of changes/additions to Tcl in the last couple years alone. It is a very nice and consistent...and to borrow from Ruby...FUN language to program in. The one thing that gets me is the "it's already been done" mentality. If you love Tcl then you want to create things in Tcl for the world to use. I have thrown out a couple ideas like "mailman in Tcl" or "nagios in Tcl"...but I always get "it's already been done". Sure, I could have done it anyway, but it gets your spirit down when you hit that wall. I know they have been done with other languages. Let's do it in Tcl to see if it can be done better!
- phsoftnet 16y ago
  Yeah .. I have not faced this kind of wall until now but I get your point. 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.
anon_d 16y ago
Your code sample isn't quite right. [read stdin] returns a string (not a list of strings), which is parsed as a list when you try to loop over it. The parsing breaks the string into a list of words, so the second loop is redundant. The parsing could fail if the input file isn't valid list syntax (unmatching {}'s). [split _] makes it safe. foreach word [split [read stdin]] { if [string match *ing $word] { puts $word }} I love Tcl too! Tcl is a scripting language for C, Python is less-powerful version of Lisp.
- phsoftnet 16y ago
  Yes you're right hehe. less powerful version of Lisp? that's weird but oh well ..

deleted 16y ago
[deleted]
- TrevorBurnham 16y ago
  I hate to get all meta, but as of this writing the parent comment has -2 points. I understand that comments that just say "Interesting :)" are frowned upon on HN because they add no information. However, in this case the commenter is the OP. He's expressing thanks for a lengthy, informative response. "Thanks for responding, that's an interesting perspective" is not a class of comment that deserves downvotes. It's completely appropriate. (Update: The comment was deleted as I wrote this.)
  - fgf 16y ago
    I agree, it's probably going to be much more satisfying to give long answers if those can be rewarded with something more than an impersonal upvote. It's a mistake to not let those who ask questions post short "thank you" replies.
rick_2047 16y ago
You are not doing C, you are not doing C++, you are not doing Java. This is the best tip that could be given. In the SICP course in Berkeley CS class, the instructor puts it as "Don't ask me what the language will do if you do something stupid, the answer will always be either you would get an error or the computer will do something stupid. Don't try to convert java code into LISP, try to think in the language."
- AndyKelley 16y ago
  I had to solve a real problem in lisp before, and I tried, I really tried to think in lisp. But after hours of frustration with the language itself and the interpreter tools, I gave up, wrote python that worked in 10 minutes, tested it, and converted it to lisp by hand. At this point I was left with lisp code that worked, but may as well have been machine code for how readable it was to me.
japherwocky 16y ago
""" Java is a bureaucratic language. You have to cross your t's dot your i's, fill out your requests in triplicate at the FactoryFactoryFactory to get the objectOfYourDesire. """ This is such an absolutely fantastic way of succinctly describing why I dislike Java so much. Bureaucratic! Absolutely fantastic post, get this on a blog somewhere. I seriously wish I could upvote you more.
- Lewisham 16y ago
  It's also a great way of specifying why I love it. Having been bitten on the ass one too many times by typing problems in a Python project, the feeling of confidence I get from doing the Java bureaucracy (to some extent mitigated now I do Scala instead) is something I have really come to love. It's like a security blanket for me.
  - zephyrfalcon 16y ago
    (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 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.
    - bdr 16y ago
vorg 16y ago
To use python you need to download it first, from http://www.python.org/download/ http://www.python.org/download/ It'll work from Hong Kong, and probably most places in the world, but if you cross the Chinese border into Shenzhen, you'll get "The connection has been reset". Same with other places in mainland China I've been.

mkramlich 16y ago

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.

cageface 16y ago
Ruby certainly has some rough edges. I don't find the redundancy of end/} a big deal in practice but I do wonder what Matz was thinking when he put them both in the language. The omission of parentheses from function calls can occasionally add some confusion but it makes uniform access to properties transparent without the property hack that Python had to add to accomplish this. It seems like Python has had to add a lot of new, non-orthogonal stuff over the years to catch up to what was elegantly possible in Ruby from the beginning. People sometimes do go overboard with DSLs in Ruby too but the big problem I have with Python code is that it all looks the same. The shape of Ruby code is usually a good indicator of what it's doing, partly thanks to DSL. Python seems to have gone just far enough in making all code look the same to defeat quick visual intuition. Why not take it a step further and get a completely regular, homoiconic syntax and all the Lisp-y benefits it brings? To me Ruby hit the sweet spot exactly between Lisp and Perl. If I had to code in Python I wouldn't hate it though. There are far worse languages.

asher 16y ago

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.

samdk 16y ago
I see your point, but I think your Python's not terribly idiomatic and that's a big part of the problem. 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] (And for any given operation, there's very possibly a cleaner way to abstract out the inner list comprehension, which would again make it a lot nicer.) 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.)
- LordLandon_ 16y ago
  [(i+1)**2 for i in a if i%3!=2] Goes through the list once, and reads like set notation! (and does i+1 once, which is what I assume you were going for with the separate [i+1 for i in a])
  - samdk 16y ago
    I kept the i+1 separate because the parent noted that this was a trivial example and wanted to make a point about the more general map-filter-map operation. I wanted to make the point that you can do the map-filter-map in Python more succinctly and more efficiently without sacrificing any power or flexibility. In this example, yes, it's easy to solve the problem with only one iteration through the list. In a more complicated example (especially when the first map step is expensive and you really only want to do it once) this kind of solution may not work.
cageface 16y ago
I find the Ruby version clearer because it proceeds from left to right like a shell pipeline. 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.
__david__ 16y ago
Oh, I want to play! Here's Perl: map { $_*$_ } grep { $_%3 != 0 } map { $_+1 } @a Interestingly, in this particular case Perl seems to have way less syntax than ruby or python, which I find rather ironic. It does have to be read backwards though, because of the syntax of map and grep...
ekiru 16y ago
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.
- Jach 16y ago
  I think this is a great example why Perl 6 highly intrigues me but at the same time scares the crap out of me. Thanks for sharing.

Lewisham 16y ago

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 exceptions to occur before it would fire. The sort of thing that would even escape most unit testing. I would never force static typing on Python or Ruby or upon any language that didn't want it, and when I switched to Python I was very pleased with dynamic typing. However, I find myself much happier with the stronger compiler checks. Writing a medium project in Python now frays my nerves!

zephyrfalcon 16y ago
"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 <wink>). 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/ 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.
- Daishiman 16y ago
  Regardless of the language, when you get to over 50K lines of code, cute tricks need to go out the window.