Hacker News Reader

Comment by dschiptsov | Hacker News Reader

Perfection is achieved not when there is nothing more to add, but when there is nothing more to remove.)

When one programs a computer (in a way it suggested in TAOCP) and you know your data, your memory layout and your CPU instruction set nothing could beat it.

Of course, there are tasks so massive, that a decent compiler could save lots and lots of man hours, but it is a completely different story.

No Haskell (leave alone J* ) could beat a code by people who know what they do close to the metal.

In some languages the code could be shorter much more readable and elegant that C, but of course, it is not Haskell, or J* .

Thoughtfully crafted Common Lisp could be close to an ideal.)

View on HN

Lisp's homoiconicity comes with the cost of some extra syntactic weight that Haskell doesn't have to bear. (It's also nice that "lambda" is considered so important that it's given a single character in Haskell).

I'm not familiar with J*, and it seems to be difficult to search for. Do you have a reference so I can go learn about it?

http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Has...

http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Com...

I prefer Erlang.

http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Erl...

And your illustration is particularly good for showing how much more "sane" (actually, in many ways) Erlang is. And how elegantly different Python could be.

J* is my own abbreviation for Java and Javascript.)

I prefer Erlang.

Just out of curiosity, why is that? (With reference to the linked example, I mean.) Clearly they're in the same league, and so it's a close call. From my perspective, I like that Haskell reserved the single vertical bar for the list comprehension notation, so that it would be as close to familiar set-comprehension notation as possible. I also like how Haskell takes advantage of how the cons operator already implies in the pattern-matching that you're working with a list, and so the square brackets become unnecessary, whereas Erlang needs the noisy extra layer of brackets on top of the parenthesis needed for the pattern.

But once languages get this elegant, it's a close comparison. They're both beautiful to my eyes.

I think the sytnax of Erlang is much more elegant, because it was build around the fundamental idea of pattern matching as a core feature of the language.

When you have a few good ideas put together, you could get an elegant solution. When you just stuff everything inside (like Clojure) or went to extremes (like Haskell) all you got is just a mess.

Erlang syntax, however, is noisy due to all those punctuation, but it is elegant nevertheless.

  map(Fun, [H|T]) -> [Fun(H)|map(Fun, T)];
  map(Fun, []) -> [].
 
  member(H, [H|T]) -> true;
  member(H, [_|T] -> member(H, T);
  member(H, []) -> false.

This is intuitive, readable, but noisy.)

I'm not sure I follow you. Is the pattern-matching in Haskell somehow not 'core' enough? Both qsort examples linked in this thread use pattern matching.

All I'm trying to say that Erlang syntax is much more intuitive and readable, being derived from Prolog.

I honestly can't see why should I use Haskell (except for being so clever) when I have Erlang, or at least one real advantage.

well, let's look.

map f (h:t) = f h:map f t

map f [] = []

member x (h:t) = x == h || member x t

member _ [] = False

I think the only difference is that you can't match for equality directly in the pattern.

Reply on news.ycombinator.com