6 ms·

How I grew to hate every computer language

44 points by cruise02 17y ago

gdp 17y 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 17y 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.
  - gdp 17y 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".
- Periodic 17y 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.
tybris 17y ago
Good engineers don't see problems or solutions, only trade-offs.
- gdp 17y 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 17y 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.
    - gdp 17y ago
      > I think it's specious to suggest that the problems in programming language design and implementation are illusionary That's definitely not what I was trying to suggest. I was suggesting that we do not need to accept "trade-offs" as an inherent property of programming, and that we can strive to do better. Sure, programming languages are designed within a context, but the number of inherent limitations upon us as programming language designers are fewer than those placed on real-world engineers. Gravity, mass, cost and tensile strength of certain materials are fixed constants, yet building skyscrapers and wide-body jets are a practical reality. What have we got to contend with? Incompleteness? Bah! So my reply was not intended to say "programming language design is not hard", rather, "we should not be so quick to accept unnecessary trade-offs". The original post was complaining about problems which have been (largely) solved in other languages. The reply about seeing trade-offs implied that working around limitations is acceptable and part of an engineer's lot. I disagreed, suggesting that most of these "limitations" are imposed by limitations of thought, not limitations in what we can actually achieve.
edw519 17y 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.
- wglb 17y 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.
- dkersten 17y ago
  A great language will make crappy programming harder.
  - axod 17y ago
    Is that necessarily a good thing? Surely then it's harder to decide who is a good programmer and who is not.
    - unalone 17y ago
      Who cares who's a good programmer and who's not? What matters is what gets made, and if people are making cool stuff then I don't care if they're completely inept. Hell, I'm completely inept and I've found it doesn't matter as long as I end up with a product people want to use.
wsprague 17y 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.
- gdp 17y 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 17y ago
  > Java with .... never mind Creating jobs.
Periodic 17y 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 17y ago
Where's the stage when you love every language except PHP and C++, because languages are fun and enabling, and have those beauties?
thstart 17y ago
I found in IBM Archives John Backus' (Fortran) thoughts on programming: “Von Neumann’s concept was brilliant. of course, and worked fine 30 years ago,” said Backus. ‘But...here’s my highly oversimplified analysis of the von Neumann computer. It consists of two boxes. One is the central processing unit, where the calculations take place, and the other is the store, or memory. Traffic between them takes place, figuratively speaking, through a narrow passage that I call the von Neumann bottleneck. Because it is just that. You see, the purpose of a program is to make a big change in the store. But how does it do it? By huffing and puffing words (a computer word is only 32 bits — 0s” and ‘l’s”) back and forth through the tiny passage between the store and the CPU. One word at a time.” The result, says Backus, is that the programmer is left with an enormous task of how to get things out of the store, combine and pump them back into the store so that the ultimate result is achieved. Everything that can be said in a conventional programming language has to be thought of in advance, making the language huge and inflexible. “And because it takes pages and pages of gobbledygook to describe how a programming language works, it’s hard to prove that a given program actually does what it is supposed to. Therefore, programmers must learn not only this enormously complicated language but, to prove their programs will work, they must also learn a highly technical logical system in which to reason about them. Here is a link where I put together some information: http://blog.thstart.com/2009/07/scienceibm-archives-john-backus-page-3.html http://blog.thstart.com/2009/07/scienceibm-archives-john-bac...
jzachary 17y ago
Pity he didn't learn Lisp.
- peregrine 17y ago
  He did. Its right before Ruby and Python.
  - jzachary 17y ago
    I know. I was being sarcastic.
brianobush 17y 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.

44 points by cruise02 17y ago

gdp 17y 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 17y 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.
- gdp 17y 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".
Periodic 17y 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.

tybris 17y ago

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

gdp 17y 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 17y 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.
  - gdp 17y ago
    > I think it's specious to suggest that the problems in programming language design and implementation are illusionary That's definitely not what I was trying to suggest. I was suggesting that we do not need to accept "trade-offs" as an inherent property of programming, and that we can strive to do better. Sure, programming languages are designed within a context, but the number of inherent limitations upon us as programming language designers are fewer than those placed on real-world engineers. Gravity, mass, cost and tensile strength of certain materials are fixed constants, yet building skyscrapers and wide-body jets are a practical reality. What have we got to contend with? Incompleteness? Bah! So my reply was not intended to say "programming language design is not hard", rather, "we should not be so quick to accept unnecessary trade-offs". The original post was complaining about problems which have been (largely) solved in other languages. The reply about seeing trade-offs implied that working around limitations is acceptable and part of an engineer's lot. I disagreed, suggesting that most of these "limitations" are imposed by limitations of thought, not limitations in what we can actually achieve.

edw519 17y 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.

wglb 17y 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.
dkersten 17y ago
A great language will make crappy programming harder.
- axod 17y ago
  Is that necessarily a good thing? Surely then it's harder to decide who is a good programmer and who is not.
  - unalone 17y ago
    Who cares who's a good programmer and who's not? What matters is what gets made, and if people are making cool stuff then I don't care if they're completely inept. Hell, I'm completely inept and I've found it doesn't matter as long as I end up with a product people want to use.

wsprague 17y 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.

gdp 17y 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 17y ago
> Java with .... never mind Creating jobs.

Periodic 17y 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 17y ago

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

thstart 17y ago

I found in IBM Archives John Backus' (Fortran) thoughts on programming: “Von Neumann’s concept was brilliant. of course, and worked fine 30 years ago,” said Backus. ‘But...here’s my highly oversimplified analysis of the von Neumann computer. It consists of two boxes. One is the central processing unit, where the calculations take place, and the other is the store, or memory. Traffic between them takes place, figuratively speaking, through a narrow passage that I call the von Neumann bottleneck. Because it is just that. You see, the purpose of a program is to make a big change in the store. But how does it do it? By huffing and puffing words (a computer word is only 32 bits — 0s” and ‘l’s”) back and forth through the tiny passage between the store and the CPU. One word at a time.” The result, says Backus, is that the programmer is left with an enormous task of how to get things out of the store, combine and pump them back into the store so that the ultimate result is achieved. Everything that can be said in a conventional programming language has to be thought of in advance, making the language huge and inflexible. “And because it takes pages and pages of gobbledygook to describe how a programming language works, it’s hard to prove that a given program actually does what it is supposed to. Therefore, programmers must learn not only this enormously complicated language but, to prove their programs will work, they must also learn a highly technical logical system in which to reason about them. Here is a link where I put together some information: http://blog.thstart.com/2009/07/scienceibm-archives-john-backus-page-3.html http://blog.thstart.com/2009/07/scienceibm-archives-john-bac...

jzachary 17y ago

Pity he didn't learn Lisp.

peregrine 17y ago
He did. Its right before Ruby and Python.
- jzachary 17y ago
  I know. I was being sarcastic.

brianobush 17y 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.