Hacker News Reader

1. You can not really juge the source code of a language if you don't the language. Reading alot of functional code is almost always easier then OO code because of pure functions. Look at this video for example at the videos witch can be found here http://www.janestcapital.com/technology/ocaml.php

2. The learning curve of those languages is not bigger then the learning curve of other languages. Time time I spend with making pretty OO designs in school was way bigger then the time it took me to learn clojure and FP in general but this of course is a issue we can not solve. I just don't like it if people say something as if it is a fact.

3. Is it more convenient to do this array.select &:even? better then (filter even? array)

The later seams more intuitive to me and I didn't have to learn more syntax.

4. In Lisp not every DSL looks like Lisp.

"The learning curve of those languages is not bigger then the learning curve of other languages."

If only it wasn't for the fact that reality and history has proven otherwise...

Any source for that utterly outlandish claim?

Utterly outlandish? Please.

The only proof we have of something being easier to learn, beside anecdotal evidence ("oh, I tried it and it was easy") is statistical empirical evidence, i.e people actually learning it. Well, people are not actually learning those languages. They are learning the "other ones".

(Where by people, I mean: a significant percentage of people, > 1%. I'm sure me, you and that "professional programmer who gives a shit about Haskell" do not a significant percentage make).

Even in universities, students find functional languages difficult, and opt-out of those classes.

The Homecomputer on witch most programmer learned where to slow for functional languages of that time. So FP could only be used in specialized domains.

Most programmers went form basic (lack of alternative) to C then C++ and now Java thats a path of simularity. Most where never exposed to functional programming and now the all have a hard time to switching there OO brain off.

> I also find Lisp / Haskell and ML to be really ugly

Wow.

> I don't appreciate that ML doesn't have a simple concept like operator overloading

ML operators are nothing more than functions. The issue of "operator overloading" comes from the type system and the simplicity of the language.

> or that in LISP every DSL still looks like LISP

You might want to read on Scheme reader macros.

> I don't like that a Smalltalk application is not portable between implementations

It's true that you don't have this issue in Ruby as the "standard" is simply the original implementation (aka there is no standard at all, and not really any competing implementation).

> or that applications are big, monolithic images of the virtual machine with everything included, even the IDE.

That definitely isn't the case. That's not the case in GNU Smalltalk, and most commercial smalltalk let you create a stripped production image which contains only the necessary code.

> It's true that you don't have this issue in Ruby as the "standard" is simply the original implementation (aka there is no standard at all, and not really any competing implementation).

Check out https://github.com/rubyspec/rubyspec.

And there are plenty of competing implementations: JRuby, Rubinius, MagLev, etc.

Not to mention the impending ISO standard.

Checking out an effort to extract a viable specification from an implementation which manages to be incompatible with itself every other release? Why?

The C# compiler in .NET also has incompatibilities with the ECMA standard. Need I mention C++, the most widely used and at the same time poorly implemented language ISO standard ever?

In fact, can you mention a single language with a standard that doesn't brake compatibility with its standard?

And yet the point is moot, because compatibility between implementations is manageable for popular languages like Javascript, C++ and yes, Ruby (JRuby, Rubinius). That's not the case for Smaltalk.

or that in LISP every DSL still looks like LISP

<bait>When your language is already at the top of the beauty chart, why would you write a DSL that is not also beautiful?</bait>

It is really a programmer choice. Lisp programmers generally love the way Lisp looks because of the advantages awarded by those looks (check Myth #7 here: http://www.algo.be/cl/myths.htm). But you can certainly create a DSL that requires more extensive string parsing, and CL provides a lot of help towards that end, including native translations of strings to Lisp objects where your parser needs them.

while we're complaining - my big problem with, really, programming languages in general, these days, is that they're getting good at making it easy to do complicated things within a process but unfortunately typical development projects are getting to be more distributed, which means that the nice abstractions your languages provide usually can't extend across your entire application, so you end up dumbing things down, relying on stuff like web frameworks which imo tend to be a bunch of hacks, etc. (This is probably the reason for the current popularity of dynamic/untyped languages - why bother specifying types when the invariants they create will only hold across part of your application anyway?)

I'd like to see more effort put toward creating programming environments that provide clean abstractions that span entire multi-process distributed applications.