

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

======
gdp
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
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
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".

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

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

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

~~~
gaius
You say that, but people have written 50,000-line Tcl scripts for controlling
oil rigs...

~~~
akeefer
Of course . . . you can also use a flat rock to hammer in nails when framing a
house, but a framing hammer might be a better idea. Doesn't mean it can't be
done, though, especially if you're really good with rocks and already have
them lying around, whereas you'd have to go to the hardware store just to buy
the framing hammer.

My point was not "language X can't do project type Y," but rather that the
things that put a language in the sweet spot for certain types of projects
kind of inevitably pull it out of the sweet spot for other types of projects.
I.e. it really is always about trade-offs. Sometimes the mere fact that you
know how to use a given language is enough of a win to outweigh any potential
benefits of switching to another language.

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

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

~~~
dkersten
A great language will make crappy programming harder.

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

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

~~~
edw519
_Who cares who's a good programmer and who's not?_

The poor soul who has to maintain your crap.

 _it doesn't matter as long as I end up with a product people want to use_

It does matter when it comes to maintaining that code base. When maintaining
crappy code, only bad things can happen:

    
    
      1. It takes too long.
      2. It costs too much.
      3. It doesn't get done at all.
    

"cool stuff" and "completely inept" are contradictory terms.

You may not care, but enough of us do that you should get better at your craft
and spare the rest of us.

~~~
unalone
You're making the assumption that I code things that require maintenance from
other people, and that I code for a living. I code for fun, and I make small
things that other people happen to enjoy, things simple enough that once I get
them working the first time, they don't break. When I work on major projects,
my partner's the programmer, not me.

~~~
olliesaunders
Language designers want to create languages that professionals will use.
Maintenance is a problem for any professional. You're lucky not to have to
deal with that problem but that doesn't mean language designers are mistaken
for engaging in attempting to find a solution to that problem just because it
doesn't affect you.

~~~
unalone
Please let me answer you in one thread before you repeat your counterargument.
I've answered this as you posted this second one.

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

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

------
jzachary
Pity he didn't learn Lisp.

~~~
peregrine
He did. Its right before Ruby and Python.

~~~
jzachary
I know. I was being sarcastic.

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

