There are three languages that I really don’t like.
I really don’t like C++, because it tips the equation of “what’s less likely to increase dramatically over time, and what should we therefore choose to optimize for — CPU or man hours?” on its end. It may be great for Mars landers, operating systems and embedded systems where you really need to know what to allocate on the stack or the heap, and in which order to destruct it, but that’s not what it’s most often used for. That such a convoluted package of statements and pseudo-backwards-compatibility still thrives today is a concept I cannot grasp without the aid of powerful narcotics.
I really don’t like LISP, and here I mean LISP the API culture and not LISP the husk of a fundamental language. LISP may have helped gel a more complete and at the time drastically different view to a programming model that helps enormously today, and I don’t dispute it. (I strongly suppose that its supporters would deride me as “missing the point” no matter what I wrote even if I “acknowledged” its entire “heritage”, “superiority” and “innovation”.) But what bugs me is that here stood a bunch of people intent on starting over without focusing the language design on hardware specifics, without even worrying about memory management, and the best constructs they could think up were these horrible atomic things like cons and car and cdr. LISP smells like a language to build a compiler to, not to get stuff done in; it smells of interpretive dancing with language constructs instead of writing what you mean. (Which doesn’t prevent people from getting stuff done in it; I’m just saying that I’ve never been mystified about how LISP isn’t taking over the world.)
I really don’t like Python, and I wish I could give a specific answer to why. Smart people with glasses and degrees get things done in it and they work fast, but I’ve never been able to juice that out of the language. Python isn’t “executable pseudocode”; out of all the languages I have difficulty writing, Python trails even AppleScript. It may be true that Ruby is my current favorite language, and that Perl was my first favorite language, but I’ve never planned resentment towards Python. Trial after trial, it has earned it by being obtuse and difficult, at least towards me.
I don’t like not liking things like these. I see qualities in most languages or technologies I don’t like, which makes it bitter for me. I feel like I’m missing out. I’m missing out on frameworks like Django from Python, I’m missing out on a LISP culture in which metaprogramming is established and default (although if I had to write code using those primitives, I’d want to effectively generate lots of code too) and I guess I’m missing out on performance, although given what I’d have to give up to get there in C++, it’s clearly not worth it for me.
I can see the arguments for people that would like to slap me in the face for saying these things. I like Ruby, Objective-C, Perl and C#. It’s not hard to shoot them down with “weird community and language”, “strange hybrid”, “it looks like line noise” and “from my parents’ home in Wyoming, I stab at thee” . They are often not deep, well-argued points of view, but sometimes they are, and even when they’re not they are real opinions, formed for a reason. Often, people who don’t like LISP and C++ but prefer C# have run to whatever course Microsoft has offered, decided after basic training that this is close to manna and never seriously tried to learn, never mind gain appreciation for, another language. I can only conclude that I’m not that person.
Programming is evolving so quickly now that it’s hard to see if or when a plateau will be reached. LISP guys may tell you that it doesn’t mean anything since they invented everything forty years ago anyway. C++ guys may tell you that it’s all syntactical crap that gets in the way of “performant” execution. Python guys may tell you that for form and structure, it’d be really nice if I had a fitting stereotype to round out this summary.
But like a friend is fond of saying: the more you know, the less you know you know, and the more you know it. Sharpen this a bit and apply it: If these arrogant LISP fuckers think they invented it all and the rest of us have spent the last few decades “badly reimplementing everything”, how much do they really know?
I find “Trial after trial, it has earned it by being obtuse and difficult, at least towards me” completely baffling. Every time I try to do something in Python it either (a) works exactly as I would guess, the first time (“Guido’s time machine”), or (b) I google the problem, or look at the documentation, and there is a library with a clean predictable API which does just what I need.
By Jacob Rus · 2008.08.29 06:21
Regarding C++, I think Yossi said it best…
“While some people are better at learning than others, it is also true that some languages are easier to learn and use than others. C++ is one of the hardest, and your reward for the extra effort spent learning it is likely to be extra effort spent using it. If you find it hard to work in C++, trying another language may be a good idea.” ~ Yossi Kreinin
C++ FQA by Yossi Kreinin http://yosefk.com/c++fqa/
By John Love-Jensen · 2008.08.29 12:36
I’m not sure what you mean by ‘Python isn’t “executable pseudocode”;’. Presumably you are saying Python is very similar to plain English and thus good for pseudocode (a major strength) & prototyping, but requires the runtime / interpreter to be installed on the computer before it will work?
If so, you should see py2exe, PyInstaller, cx_Freeze and py2app. These tools allow you to create stand alone Python scripts and apps. Hope this helps. :)
By Ryan · 2008.08.29 16:36
“Executable pseudocode” referred to the old quip that Python is supposedly intuitive to write and with little, uh, ASCII art to get in the way. I don’t find Python easy to write at all. I found Ruby hard to write in the beginning as well since it was also largely an introduction to a different, more closure-focused way of programming, but I’ve tried to get into Python many more times with much more vigor, and it hasn’t let up.
It’s probably not about the difficulty of the libraries, it’s that my principle of least surprise is more consistent with Matz’ than Guido’s.
It is tremendously satisfying when everything works like clockwork in C++. But it’s hell getting there, and it’s hell going through iteration to get to another version of the code, and I have a well-documented hell aversion.
By Jesper · 2008.08.29 18:47
Perhaps presenting a piece of Python code that you don’t like will make everyone understand if it’s a subjective dislike of Python (fine by me!) or you’re just unlucky with your excursions in Python, to which I would suggest just keep trying!
Really, you don’t get many comments about Python being hard to write and being obtuse and difficult.
By Orestis Markou · 2008.08.29 19:17
I said that I think Python is hard to write, obtuse and difficult (everything else is extrapolation, especially based on the way I framed it). Despite that “subjective dislike” is a tautology (show me an objective dislike), it is these things which I can’t pinpoint, surely, that make me be unlucky in my excursions. I’ve coded in everything from VB to PLC to C++ to Ruby to Java to C# to Perl, and it is only with Python that this problem arises.
I wish I could present a piece of Python code because that means I could solve the problem, but it’s not that easy.
By Jesper · 2008.08.29 20:08
“… here stood a bunch of people intent on starting over … and the best constructs they could think up were these horrible atomic things like cons and car and cdr”
You do understand that Lisp was first implemented in 1962, right? Not so much “starting over” as “starting”. I wouldn’t claim that Lisp would be my first choice to write a large complex system in these days (although some do), but my early exposure to it has had a profound effect on the way I think about programming.
You’re the first person I’ve ever heard say that Python is hard to write. I must conclude that you must think very differently about programming than I do. (Not better or worse, just different.) If you find Ruby and Perl more productive for you, then so be it.
By rsfinn · 2008.08.29 21:01
Yes, yes I do, but it was hardly the first language. It was one of the first languages to be specified as a good and practical language instead of as a language that would be easy to run on the hardware of the day. I knew this years before I wrote this post, and still I wrote what I did because I think regardless of then current conditions (which, again, the design of LISP was eager to not depend on), it’s a crummy model.
By Jesper · 2008.08.29 22:43
I should perhaps note, since this is apparently so fucking exceptional, that I don’t generally have a problem reading Python programs and following what they do. It’s just a matter of writing them: when I start to try to write Python programs, I stumble. I don’t intend to boast about my programming language proficiency, but not being able to pull up some API documentation is hardly the limiting factor. It’s not even that tuples and lists take mental energy to disambiguate between (this is probably sanded into your spine by the second day of successful coding, even if in some cases, like return values, they feel like a crutch for other missing features).
Maybe it’s that much of common usage reads like function soup, which is odd for a language that’s so object-oriented. Maybe it’s the PHP-like approach of doing data type-like things with function-like syntax (
set(),dict()). Maybe the strict front against helpful disambiguation and syntactical sugar that’s so foreign for a “scripting language” that it’s really off-putting to write, considering how the first such language I learned was Perl. (Again: I had no resentment towards Python going in, but you’ll find plenty of confirmation that they really are two cultures.)This is not invented, veiled criticism against Python. I highly respect some of the better applications of Python out there, and I believe it’s up to you personally which language you get things done in. If I knew what made Python so hard for me, I’d tell you. Rather, I’m spooked that I can’t, and it’s uncomfortable to write about, but I fear I won’t be able to pinpoint it otherwise.
By Jesper · 2008.08.29 23:07
Just so you know you’re not alone, I feel the same way about Python. It may be syntactically elegant, but its standard library is inconsistent, with a mix of functional and OO interfaces. Ruby on the other hand, has some questionable syntax choices but it is architecturally elegant. Once you get used to pure OO and closures in the way Ruby presents them, other languages seem–what’s the word–suboptimal, perhaps.
By Zim · 2008.08.30 13:16
Nicely articulated. I agree that Python’s standard library is not very well architected.
By Orestis Markou · 2008.09.01 00:37
Next time you need to do perl, you should have a play with Moose – it provides a full metaprotocol for perl so you can probably re-use many of the tricks you’ve learned in ruby. Plus of course, you get multiple inheritance, which combined with perl5.10’s “use mro ‘c3′” (or MRO::Compat on 5.8, aka “python did MI better so we stole it”) is actually rather usable, although Moose’s role abstraction means that in new code it’s largely unnecessary
By Matt S Trout · 2008.09.01 03:58
With regards to LISP: You don’t like it because of cons car and cdr? You could easily redefine those terms….
Many of the greatest programmers know LISP inside out, perhaps that is reason enough to want to learn more about it before dismissing it.
By doofusandgallant · 2008.09.01 08:52
“Maybe it’s the PHP-like approach of doing data type-like things with function-like syntax (set(), dict()).”
Those things have been phased out. I only ever use dict() as a function for converting an existing associative list into a dict. You use {a: b, c: d} notation to describe dicts usually.
Sets still require set([a,b,c]), which is bad as you point out. But in upcoming Python 3, you will be able to write the much more natural {a, b, c} for sets.
Anyway, I think talking about specific gripes with Python isn’t going to make anyone feel better. You (original author) just have some fundamental issue with Python, and any attempt by people to explain or argue one feature or another will just make you dig in your heels more.
That’s Totally Fine. Everyone has languages they Really Don’t Like, and those languages are different among people. Me, I love Python and I dislike Ruby and I can’t stand Perl! If you try to explain why Ruby is the way it is, I still won’t like it. This is why I’m glad we have lots of different languages.
Anyway great post. I totally agree with you on C++ and Lisp (except Lisp has great historical significance).
By Matt Giuca · 2008.09.01 13:23
doofusandgallant: LISP “relies” on car and cdr, C++ “relies” on manual memory management; they are fundamental building blocks of the language. Of course these can be abstracted away, but they leave permanent imprints on the language, the culture and the philosophy. You might argue that it’s possible to reshape LISP in a way that’s not possible with C++ to get away from that problem, and I’d in turn argue that that might be part of the problem more than it’s part of the solution. I may be old-fashioned (or new-fashioned, whatever fits best), but while you shouldn’t expect the best solutions to everything to be bundled, I do believe that you should have things that work for you available out-of-the-box.
I saw an example written by an actual LISP users about recommended and deprecated macros to do something very simple (grep within the page for “dramatization”. It’s a good thing if your language is good enough to be redefined/-able, but if this admitted dramatization has a kernel of truth, then macros are probably overused as the answer to everything, and that makes the language harder to write in, even when it’s more powerful.
It might very well be that LISP really is the next level of programming, like Paul Graham says, and that I’m having trouble grasping that since I don’t think in it at all, but (figuratively) yelling at people for not realizing it isn’t going to solve anything.
Ruby’s language approach is fantastic in this regard: you can write function soup, you can write object-oriented, you can use closures and you can use metaprogramming. None of it is forced on you, but it’s all available to you the minute you want to start using it. That’s the way to wean people — I know that’s what opened my eyes to closures.
Matt Giuca: I never denied the historical significance of any of these languages, and I believe the world would look a lot different had they not been around.
Matt S Trout: I don’t do a lot of Perl programming anymore, but I’m still in love with the language. I’ve said before that Ruby is my Perl 6 until Perl 6 arrives with full support, and I think I stand by that for the time being. I know that Moose is in some ways a port of the Perl 6 OO, which I love, but I want to keep a clear distinction of Perl 5 and Perl 6 in my mind and have avoided using it for that reason.
By Jesper · 2008.09.01 18:11