The New Haskell Homepage • Hacker News Board

Re: The New Haskell Homepage

#201

Post by rtfeldman » Wed, Jul 09, 2014, 3:56 PM UTC

wtetzner wrote: post #190

sparkie wrote: post #189

> How often do programs crash because of an unexpected null value? Haskell programs never do! > head [] error "Prelude.head: empty list" Ok, so you don't call it `null`, but it still crashes the program. Its deceptive to claim null isn't present because it's conventional to avoid using "error" in favor of Maybe, but it's still there, and used throughout Prelude. The REPL on the site hides these errors too, which is g…

There's a difference between crashing and returning null. If head returned null on an empty list, that null could be passed around to different places in the program before it crashed from a null pointer exception. There can be unexpected crashes in Haskell, but not because of null.

Yeah. A major reason null is called the "billion dollar mistake" is that once you finally do get a NullPointerException (or the like), it can take a huge amount of time to track down where the null value originated.

If you take the head of an empty list in Haskell, you get an exception right away. Not a poisoning of the well, like you do in so many other languages.

That's absolutely a benefit of Haskell worth touting.

Re: The New Haskell Homepage

#202

Post by lenkite » Wed, Jul 09, 2014, 3:58 PM UTC

Pacabel wrote: post #46

thoughtpolice wrote: post #24

Please note this homepage is NOT final and it's going to see revisions before we push it out to the actual website, including many tweaks to the content and probably some styling tweaks too. There are a lot of other things we still need to do as well, like ensure all redirects and subpages work properly. Source: I'm one of the Haskell.org administrators, and we pushed this out only today.

Is there a practical reason why there's so much empty space with this new design, and why so little valuable content and functionality is visible by default? Viewing the existing site in a desktop browser, I get to see the description of Haskell, and a bunch of useful links about learning it, downloading an implementation, using it, and participating in the community. Recent news items and upcoming events are also vi…

The real reason is that one of the standard bootstrap layout examples was used. The 'bootstrapped' web today is extraordinarily boring. It is the same big banner followed by striped two column grid again and again and again.

Re: The New Haskell Homepage

#203

Post by [deleted] » Wed, Jul 09, 2014, 4:24 PM UTC

rtfeldman wrote: post #196

cousin_it wrote: post #156

Earlier quoted context omitted.

That's a horrible algorithm though, it takes exponential time. Any good implementation of Fibonacci numbers would be logarithmic in the number of arithmetic operations and polynomial in overall running time (because the numbers get bigger). Here's a good implementation in Haskell: http://nayuki.eigenstate.org/res/fast-fibonacci-algorithms/f... , and the same in Python: http://nayuki.eigenstate.org/res/fast-fibonacci-…

Remember, the target audience is newcomers to Haskell. The purpose of a code sample is to give them a glimpse into the syntax of the language, which should be understandable enough that it piques their interest to learn more. It would be to the detriment of haskell.org to showcase a superior algorithm that is harder for newcomers to follow.

[deleted]

Re: The New Haskell Homepage

#204

Post by dragonwriter » Wed, Jul 09, 2014, 4:32 PM UTC

rtfeldman wrote: post #198

ufo wrote: post #183

Earlier quoted context omitted.

Your example doesnt highlight lazyness like the sieve one does. I would expect to see something like this instead: fibonacci :: [Integer] fibonacci = 1 : 1 : zipWith (+) fibonacci (tail fibonacci)

True, but remember that, say, a Rubyist arriving at haskell.org has no knowledge of: * what zipWith does * that (+) is a function being passed, not an operator being invoked * cons syntax for 1 : 1 : ... * how this could terminate (having no preexisting knowledge of laziness, remember) A better goal than "show off all the features of Haskell" is "show a Haskell example that's understandable, demonstrates a clear bene…

> True, but remember that, say, a Rubyist arriving at haskell.org has no knowledge of:

> * what zipWith does

haskell:

  zipWith f xs ys

ruby:

  xs.lazy.zip(ys).map(&f)

While Ruby doesn't have a method of the same name, its not exactly foreign.

> * that (+) is a function being passed, not an operator being invoked

Again, sure, Haskell has different syntax than ruby, but the parens signal something special is going on here.

> * cons syntax for 1 : 1 : ...

Sure, but if you know what the Fibonacci sequence is -- and the reason it and primes are almost without exception the two things chosen for these infinite stream examples in every language is because its presumed that programmers do, its pretty easy to get the idea of what is being done from knowing what the function is trying to do and looking at the values presented.

> * how this could terminate (having no preexisting knowledge of laziness, remember)

A Rubyist that has no knowledge of laziness isn't a very knowledgable Rubyist, since laziness is an important and central concept in Ruby's Enumerable module (one of the core modules most frequently used by Rubyists.)

Re: The New Haskell Homepage

#205

Post by T-hawk » Wed, Jul 09, 2014, 4:56 PM UTC

rtfeldman wrote: post #201

wtetzner wrote: post #190

Earlier quoted context omitted.

There's a difference between crashing and returning null. If head returned null on an empty list, that null could be passed around to different places in the program before it crashed from a null pointer exception. There can be unexpected crashes in Haskell, but not because of null.

Yeah. A major reason null is called the "billion dollar mistake" is that once you finally do get a NullPointerException (or the like), it can take a huge amount of time to track down where the null value originated. If you take the head of an empty list in Haskell, you get an exception right away. Not a poisoning of the well, like you do in so many other languages. That's absolutely a benefit of Haskell worth touting…

That's still the same problem, isn't it? You still have to track down where the empty list originated, just as the null value in C.

I'm not a Haskeller, but do the language and tools make that easier than in other ecosystems?

Re: The New Haskell Homepage

#206

Post by mike_ivanov » Wed, Jul 09, 2014, 4:59 PM UTC

This page would seriously benefit from a few random kitten pictures.

Re: The New Haskell Homepage

#207

Post by sparkie » Wed, Jul 09, 2014, 5:01 PM UTC

progman wrote: post #149

Many people know C++ and Java but have no sense for functional programming. It would help them to read equivalent known code to compare it with Haskell. For instance FP Complete's Introduction to Haskell presents some ugly Java code which can be written in two elegant lines in Haskell (video around 03:25 min). http://www.youtube.com/watch?v=Fqi0Xu2Enaw

This gets brought up often, but side-by-side comparisons don't really work, because the languages are too different for them to be meaningful for anything but trivial expressions. To really understand Haskell, you need to somewhat unlearn Java - or at least, stop thinking in it (in terms of objects, state and method calling).

I think a good approach to thinking differently is to look how data structures are done - most programmers recognize arrays, lists, stacks and queues, but might be confused as to how you would implement such thing without side effects. A great resource to explain this is Okasaki's Purely Functional Data Structures[1], although it doesn't use Haskell at all, the ideas are relevant, and you can work through all of the examples implementing Haskell equivalents.

[1]:https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

Re: The New Haskell Homepage

#208

Post by new_test » Wed, Jul 09, 2014, 5:05 PM UTC

Off-topic: I want to learn a functional programming language, and I was thinking to go with Scheme (because, you know, SICP...) Would there be any advantage for me to go with Haskell instead?

Re: The New Haskell Homepage

#209

Post by [deleted] » Wed, Jul 09, 2014, 5:19 PM UTC

T-hawk wrote: post #205

rtfeldman wrote: post #201

Earlier quoted context omitted.

Yeah. A major reason null is called the "billion dollar mistake" is that once you finally do get a NullPointerException (or the like), it can take a huge amount of time to track down where the null value originated. If you take the head of an empty list in Haskell, you get an exception right away. Not a poisoning of the well, like you do in so many other languages. That's absolutely a benefit of Haskell worth touting…

That's still the same problem, isn't it? You still have to track down where the empty list originated, just as the null value in C. I'm not a Haskeller, but do the language and tools make that easier than in other ecosystems?

[deleted]

Re: The New Haskell Homepage

#210

Post by freyrs3 » Wed, Jul 09, 2014, 5:19 PM UTC

T-hawk wrote: post #205

rtfeldman wrote: post #201

Earlier quoted context omitted.

Yeah. A major reason null is called the "billion dollar mistake" is that once you finally do get a NullPointerException (or the like), it can take a huge amount of time to track down where the null value originated. If you take the head of an empty list in Haskell, you get an exception right away. Not a poisoning of the well, like you do in so many other languages. That's absolutely a benefit of Haskell worth touting…

That's still the same problem, isn't it? You still have to track down where the empty list originated, just as the null value in C. I'm not a Haskeller, but do the language and tools make that easier than in other ecosystems?

The difference is the program halts immediately at the place in the program where the semantics break down. Unlike in C where you can program with nulls and pass them around, potentially smearing the problem around the entire program.