How I grew to hate every computer language

http://lbrandy.com/blog/2009/08/how-i-grew-to-hate-every-computer-language/

by cruise02 • 17 years ago

44 42 17 years ago

gdp6• 17 years ago

I went through a similar progression. Then I learned SML. I haven't started hating it yet, and it's been about 6 years. YMMV, but I generally find that the things I hated most about most "main stream" programming languages are absent in languages like ML and Haskell (and I assume in F# too, though I haven't really used it).

jganetsk• 17 years ago

Would vote this up 10 million times, if I could.

This is because the structures of ML and Haskell are based on the structure of logical proof, through the Curry-Howard isomorphism. Most programming languages are constructed on top of arbitrary decisions made by their designers.

gdp6• 17 years ago

True.

And in particular, there are a few things I really like:

Hindley Milner-style type systems make life easier. You don't write out very many type annotations, but you get a type safety guarantee. People seem to underestimate just how strong this guarantee really is. It is equivalent to "Your program will not crash" for all intents and purposes. Similarly, I generally find that a program that passes type checking is about 7 trillion* times more likely to be functionally correct than a Java or C++ program that merely compiles.

(Specific to ML) The "Mostly functional" nature of SML means that you usually write pure functional programs. However, it's easy to drop down into something resembling a more imperative style of programming if you need to. I found this helped my learning curve a lot. I could write functional code as far as my limited experience would allow me, and then I could finish the program using my (considerably more extensive) imperative programming experience. I've found that I had done this less and less as I've become more experienced (to the point where I pretty much don't do it at all), but it was a nice option. Supplementary to this point, the presence of mutable arrays occasionally makes sense in terms of performance, and so these are available to you in the rare cases where it makes sense to use them. This certainly isn't knocking purely functional languages such as Haskell that use Monads to achieve much the same effect, I've just found that having a "mostly-functional" approach has suited my brain, and permitted me to write more efficient programs with less effort. Others would probably say exactly the opposite with regards to Haskell vs ML.

Pattern matching. Oh, how I love thee, especially when combined with recursive data types. I don't like to get sentimental about programming languages, but seriously, sometimes it is pure poetry.

Functors give you most of the nice properties of templates in C++ without the warts (at least with respect to the way I use each).

The performance of compiled OCaml and SML code is very similar to that of C++ by some benchmarks. In practice, I've found this to mean "plenty fast enough", even in scientific and numerical computing applications.

Polymorphism and higher-order functions make code re-use a practical reality, as in, you usually write things in a reusable way purely by accident rather than needing to think about how you will make things reusable.

Sorry, this is turning into a love letter, so I'll stop.

* May or may not be the exact figure. I mean "a lot".

Periodic2• 17 years ago

I've been really enjoying learning Haskell. I believe I'm still in a honeymoon phase though, and it too will pass, though it has lasted longer than for any other language.

tybris3• 17 years ago

Good engineers don't see problems or solutions, only trade-offs.

gdp6• 17 years ago

That's certainly one platitude that contains some of the same keywords as the article.

Except that programmers work in a synthetic world. We shouldn't have to "trade off" (nor should we find this acceptable) unless we actually encounter some limitation from the real world (e.g. finiteness of computer memory or CPU cycles, or developer time). I would argue that most of the time, we are tilting at windmills instead of solving things the way would we like to solve them.

mgreenbe• 17 years ago

Of course programming languages involve trade-offs. Concrete syntax trade-offs abound, but more important are semantic trade-offs. Many are of the form feature vs. performance. Dispatch? Memory safety? Laziness? Otherss are more complicated, like those involving type systems, which are formally complex while affecting the informal "feel" of the language.

I think it's specious to suggest that the problems in programming language design and implementation are illusionary, and that we could somehow code "the way would we [sic] like". The language of computation is extremely subtle, and the process of building abstractions over our computers' basic operations is still more subtle. We are not done exploring possibilities---nor, I suspect, will we ever be.

tybris3• 17 years ago

I wonder when it is you don't encounter limitations from the real world. I certainly couldn't type a line of code without my computer interacting with the real-world.

akeefer2• 17 years ago

The best languages for writing quick-and-dirty 15-minute scripts are never going to be the best languages for million-line, mission-critical applications, the best languages for embedded programming are not going to be the best languages for web programming, and the best languages for beginners are not going to be the best languages for more advanced programmers.

So perhaps programmers sometimes give up too quickly and could do better on all those fronts, but it's not some limitation of the real world that forces the tradeoff: it's the fact that different decisions regarding things like syntax or the type system do have a real impact on the suitability of the language for different purposes, and you can't be all things to all people there. Sometimes you want a very loose language that doesn't get in your way; sometimes you want a very strict language that ensures correctness; sometimes you want a language that lets you manipulate things close to the metal; sometimes you want a very simple language that's easy to learn because it doesn't have too many concepts; sometimes you want a very advanced language that gives you lots of different ways to solve problems.

No language can or should be all things to all people.

asciilifeform• 17 years ago

Exactly:

"If I wanted to put an 'If' statement in a 'While' statement, I don't have to worry about whether the 'If' statement will oscillate at a certain frequency and rub against the 'While' statement and eventually they will fracture. I don't have to worry whether it will oscillate at a certain higher frequency and induce a signal in the value of some other variable. I don't have to worry about how much current that 'If' statement will draw and whether it can dissipate the heat there inside that while statement. Whether there will be a voltage drop across the while statement that will make the 'If' statement not function. I don't have to worry that if i run this program in a salt water environment that the salt water may get in between the 'If' statement and the 'While' statement and cause corrosion. I don't have to worry when I refer to the value of a variable whether I am exceeding the fan-out limit by referring to it 20 times. I don't have to worry, when I refer to the variable, how much capacitance it has and whether there has been sufficient time to charge up the value. I don't have to worry when I write the program, about how I am going to physically assemble each copy and whether I can manage to get access to put that 'If' statement inside the 'While' statement. I don't have to worry about how I am going to gain access in case that 'If' statement breaks, to remove it and replace it with a new one. So many problems that we don't have to worry about in software. That makes it fundamentally easier. It is fundamentally easier to write a program than to design a physical object that's going to work. This may seem strange because you have probably heard people talking about how hard software is to design and how this is a big problem and how we are going to solve it. They are not really talking about the same question as I am. I am comparing physical and software systems of the same complexity, the same number of parts. I am saying the software system is much easier to design than the physical system. But the intelligence of people in these various fields is the same, so what do we do when we are confronted with an easy field? We just push it further! We push our abilities to the limit. If systems of the same size are easy, let's make systems which are ten times as big, then it will be hard! That's what we do! We make software systems which are far bigger in terms of number of parts than physical systems. A physical system whose design has a million different pieces in it is a mega project. A computer program whose design has a million pieces in it, is maybe 300,000 lines, a few people will write that in a couple of years."

"The Danger of Software Patents" by Richard M. Stallman (http://www.cl.cam.ac.uk/~mgk25/stallman-patents.html)

katamole• 17 years ago

Hubris.

Programming is partly a creative pursuit. Thus, it helps if one enjoys using the tool you need for the job.

tybris3• 17 years ago

> tool you need for the job.

What is it about your tool that you need for the job? Is your tool specifically designed for your (type of) job? What trade-offs are you making with that tool versus other tools? Did you consider the long-term implications of your choice of tool? What if you wish to extend your job? Is your tool well-maintained? What if a customer comes back with questions about your job after a few years? Is it possible that more people will work on your job? Will they need to learn your tool? Will you still be happy about your choice of tool? (etc, etc, etc)

Engineering is making trade-offs.

edw5192• 17 years ago

These kinds of posts have never really resonated with me. I know about a dozen different languages and use 3 of them 99% of the time. They all have their pros and cons.

I may be in the minority here, but I've never really cared as much about the language as the task at hand. Sure, some languages are better than others for different things, but you can do almost anything with almost any language. I'm so concerned about getting the result to the customer that I forget how much less I'd be suffering with different tools.

Now if there were an article entitled, "How I grew to hate every practitioner of computer languages," that might be a different story :-) I've seen great code and horrible code in every language. I'll take great programming in a crappy language over crappy programming in a great language any day.

dkersten4• 17 years ago

A great language will make crappy programming harder.

axod• 17 years ago

Is that necessarily a good thing? Surely then it's harder to decide who is a good programmer and who is not.

olliesaunders4• 17 years ago

Only true if, by harder, you mean relative to the good practise that it makes easy.

wglb• 17 years ago

I agree, but I did have an intense moment with Fortran II that effectively launched me into a compiler-writing career.

And actually a second point was a zero-knowledge dislike of COBOL. This faded when after a couple years of RPG-III, a COBOL compiler was installed. Felt so much better.

wsprague• 17 years ago

I find that every computer language does one thing best (ML with pattern matching, Tk with quick GUIs, Perl with text, Python with object orientation, Java with .... never mind), but in most other respects falls short of some other computer language. The more languages I know, the more salient their respective shortcomings become, which makes me hate them all. So I sympathize.

gdp6• 17 years ago

I think you've misunderstood my use of "pattern matching" in the post above. The way you've used it is a bit like saying "C is the best language for if statements".

A pattern match in ML is something like:

fun f 0 = <do something> | f 1 = <do something else> | f n = <do something in the general case

This goes really well with the ability to build up arbitrary datastructures, for example:

fun sum_tree (Node v) = v | sum_tree (Branch (left, v, right)) = v + sum_tree(left) + sum_tree(right)

Which would sum up all the values stored in an integer tree.

vegai• 17 years ago

> Java with .... never mind

Creating jobs.

Periodic2• 17 years ago

It feels to me that most* programming languages were created to solve a particular problem and use a particular style. If you are working in that problem domain then often that language will be best. If you are looking for a language to be your go-to for everything you're only going to end up hating them all.

Each programming language makes trade-offs. Ease of low-level control vs. ease of high-level constructs. Quick write-execute turn around vs. code optimization. Strong type guarantees vs. ease-of-use duck typing. There are hundreds of these tradeoffs and you just have to figure out where you want to be for your particular problem.

* I say most, because there are some really terrible languages out there that were largely created out of ignorance. Usually they're just scripting languages created for a specific application. Instead of using a tested solution, like extending Ruby, Perl, or Lua, they write their own which has most of the same features half-implemented.

ilyak• 17 years ago

Where's the stage when you love every language except PHP and C++, because languages are fun and enabling, and have those beauties?

jzachary2• 17 years ago

Pity he didn't learn Lisp.

peregrine• 17 years ago

He did. Its right before Ruby and Python.

jzachary2• 17 years ago

I know. I was being sarcastic.

brianobush• 17 years ago

I have my favorite languages (python and C) and have gotten used to their warts. It is like a marriage, you just get used to the problems and learn to avoid the problem areas. For kicks I think assembly is still fun to program in, e.g., the Tierra assembly language that was built by Tom Ray back in the early 90s for evolution research was fun to toy with.

How I grew to hate every computer language

Related Stories