Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The New Haskell Homepage

new-www.haskell.org

Post reply on HN
Print view View original

211–220 of 258 posts

Re: The New Haskell Homepage

#211

Post by adrusi »

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 are a couple of Prelude functions that are broken, most notably `head` and `tail`. The problem is that they use non-exhaustive pattern matching in their definition:

    head :: [a] -> a
    head a:_ = a

    tail :: [a] -> [a]
    head _:as = as
Fortunately, use of these functions is unidiomatic, not just because they're one of the only ways that haskell programs can crash, but because they're less clear than the alternative, pattern matching. The haskell compiler will give you a warning by default if you write a function that performs a non-exhaustive match.

tl;dr: head and tail are mistakes, but they're never used.

Re: The New Haskell Homepage

#212

Post by [deleted] »

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…

[deleted]

Re: The New Haskell Homepage

#213

Post by forrestthewoods »

freyrs3 wrote: post #178
forrestthewoods wrote: post #109

Earlier quoted context omitted.

Not really. No. And that's the problem! You're right that semantics are what make the languages truly different. However it is literally impossible to even begin to understand semantics if you don't know the syntax. That's what is so frustrating. It might as well be written in Kanji. That's how meaningless it is to me and, I believe, most programmers.

What you're saying is like arguing that the Japanese should switch from Kanji to Latin characters because more people worldwide use them. That's the language, it's not going to change. It's just silly to criticize Haskell/Japanese for not being immediately understandable without study.

No. That's wrong. Completely wrong.

All I'm asking for is a Kanji to Latin dictionary. It's not about changing Haskell syntax. And it's not about "studying" the syntax. Haskell has funny syntax with funny symbols. That's totally fine. I just need someone to say "see this symbol? that means cat!" Most tutorials do a terrible, terrible job of that.

Re: The New Haskell Homepage

#214

Post by sparkie »

adrusi wrote: post #211
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 are a couple of Prelude functions that are broken, most notably `head` and `tail`. The problem is that they use non-exhaustive pattern matching in their definition: head :: [a] -> a head a:_ = a tail :: [a] -> [a] head _:as = as Fortunately, use of these functions is unidiomatic, not just because they're one of the only ways that haskell programs can crash, but because they're less clear than the alternative, p…

I picked head and tail as primary examples, but it's not limited to them. As I discussed in the link I've posted to a discussion yesterday, one can easily create their own incomplete pattern matching by mistake, without the compiler complaining, by using records. eg:

    data List a = Nil | Cons { head :: a, tail :: List a }
I encounter this misfeature of Haskell frequently - records and sum types don't mix, because they lead to an incomplete pattern match in the record fields.

Yes, it's unidiomatic Haskell, but a beginner does not know this, and just because it's conventional to avoid using it, does not mean it isn't still there - anyone could make this mistake.

Re: The New Haskell Homepage

#215

Post by qubitcoder »

thinkr wrote: post #181
akurilin wrote: post #112

Earlier quoted context omitted.

Yours isn't an uncommon reaction, don't sweat it. I remember being thoroughly confused by what I was reading back when I started learning Clojure, after years in C# and ruby. At first I thought no normal human being could understand just what the heck was happening amongst all of those parentheses, but eventually it became second nature. Now I've probably written a good 50KLOC in the language and to me it feels seman…

Out of curiosity, was there a specific reason you went from Clojure to Haskell or was it more about exploring a new language? I ask because I am currently learning Clojure, but wonder if there is something unique that Haskell offers.

It's wonderful to see so many comments on Haskell! I began learning Haskell about a year ago. Coming from the world of C/Java/Ruby/Python, venturing into Haskell has been a phenomenal experience. While frustrating in the beginning, the payoff has been worth it. For me personally, I still wake up excited by the language & what’s left to discovery.

Aside from its technical merits, there's a certain expressive beauty and power to it. For example, I recently wanted to write a command-line version of 2048 in Haskell. Instead of being bogged down in the minutia of keeping track of array indexes and state variables, it was simply a matter of transposing lists (corresponding to board rotations). The entire game fit onto a single screen of code that reads like English (once you’re accustomed to the syntax - please don’t be scared off by that!)

I spent some time learning Clojure. From my limited experience, it’s certainly easier to get up to speed writing working programs with Clojure. The simplicity of LISP syntax is hard to beat. And the fact that it runs atop the JVM makes things like cross-platform GUI programming a breeze compared to Haskell. But while macros are powerful, it really doesn’t compare to the flexibility & composability of Haskell. Haskell provides some powerful abstractions which make building software easier, and these capabilities simply aren’t possible in other languages — check out the Tony Morris videos on monads & monad transformers for more details [1]. He also explores why these abstractions, if they’re indeed so powerful, aren’t currently more prevalent in software engineering. He’s dedicated to changing that.

LYAH is a great resource, but it can be a bit verbose at times.For those interested in diving into the language right away, I recommend checking out the University of Virginia CS 1501 Haskell lectures [2]. They start with the basics and gradually build up to more advanced concepts like functors, monoids, monads, etc. They even have a section on category theory at the end.

For a great intro to web development with Haskell, see Ryan Trinkle’s talk on creating a link shorter (using the Snap web framework with a PostgreSQL backend). [3] Live demo [4]

For a more formal CS-style introduction to Haskell, see the lectures by Prof. Dr. Jürgen Giesl. [5]

[1](http://vimeo.com/robmanthey/videos/page:6/sort:alphabetical/)

[2](http://shuklan.com/haskell/index.html#)

[3](http://vimeo.com/59109358)

[4](http://memoi.se/)

[5](https://www.youtube.com/channel/UC9ZJ-o00b2t79v6er1O-eBQ/vid...)

Re: The New Haskell Homepage

#216

Post by Tyr42 »

thinkr wrote: post #181
akurilin wrote: post #112

Earlier quoted context omitted.

Yours isn't an uncommon reaction, don't sweat it. I remember being thoroughly confused by what I was reading back when I started learning Clojure, after years in C# and ruby. At first I thought no normal human being could understand just what the heck was happening amongst all of those parentheses, but eventually it became second nature. Now I've probably written a good 50KLOC in the language and to me it feels seman…

Out of curiosity, was there a specific reason you went from Clojure to Haskell or was it more about exploring a new language? I ask because I am currently learning Clojure, but wonder if there is something unique that Haskell offers.

Well, I'm a Haskeller who's just leaning some Clojure, and I kinda miss the compiler catching dumb type errors sooner.

But the data-structures that are built in are pretty slick.

Re: The New Haskell Homepage

#217

Post by sparkie »

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?

What makes it easier is immutability - if given an empty list, the only place that could've made this list empty is the place it was constructed - because there's no way some other function can come and delete items from it. A function which "removes" items from a list doesn't actually do such thing - it creates a brand new one and adds all the same elements except the items you requested being removed.

In this way, there's only one possible path that the list could've come from - through the pure functions which use it - until head is reached. Given that each function is referentially transparent, applying the same input list to a function in the debugger will always produce the same result, so it's simple to call a function with some sample data in ghci, and the result you get will be the same result you get in the compiled program.

Debugging/tracing is perhaps more difficult than with tooling you might already be familiar with - but it's much more rare that you need to even use them, because it's obvious what values a function should return - they don't have any state which could influence otherwise.

Re: The New Haskell Homepage

#218

Post by matdes »

forrestthewoods wrote: post #95

I get paid to write C++ code. I'm pretty good at it. I understand it's normal usage syntax very well. I don't fucking know what a god damn thing means in Haskell. λ 5 + 7 12 :: Num a => a What the christ? The 12 I get. Got it. The colons? Not sure. I think it's just a dumb separator. Num is type! What the hell is a => a? I have no idea. In the top they have an example. primes = sieve[2..] where sieve (p:xs) = p : sie…

" λ 5 + 7 12 :: Num a => a What the christ? The 12 I get. Got it. The colons? Not sure. I think it's just a dumb separator. Num is type! What the hell is a => a? I have no idea."

:: means "the stuff after this is the type signature"

Normally, a type signature can be as simple as something like

'x' :: Char

which is the type signature of the character 'x'. Looking at the type signature of 12 shows two parts "Num a =>" and "a". This can be read as "it returns a generic type `a` that must be an instance of the type class Num", which sounds really complicated but isn't.

The "Num a =>" is a type class constraint on the returned type "a". Type classes are basically like interfaces, they set up constraints and methods that need to be implemented for that type, analogous to how in other languages a class can implement an interface. For example, the Eq type class mandates you define the (==) and (/=) methods for that type, analogous to how something like the interface Comparable in Java requires you to define the compareTo method.

Thus the concrete type "Integer" is an instance of type class "Eq" because it implements those (==) and (/=)

Num is an example of a type class, just like Eq. But Num requires you to define a few more methods

  class Num a where
  (+) :: a -> a -> a
  (*) :: a -> a -> a
  (-) :: a -> a -> a
  negate :: a -> a
  abs :: a -> a
  signum :: a -> a
  fromInteger :: Integer -> a
So all of the things you think of as "numbers" are all types that implement "Num", e.g. an Integer, a Float, a Double.

So going back, "12 :: Num a => a" means 12 can be any type which implements Num, which is really just a fancy way of saying "this number can be cast into any numeric type". You can perform this casting manually!

  λ (5 + 7) :: Integer
 12:: Integer
  
  λ (5 + 7) :: Float
  12.0:: Float

Re: The New Haskell Homepage

#219

Post by Tyr42 »

exDM69 wrote: post #179
hss54 wrote: post #52

Please, get rid off the primes example, as it is horrible inefficient (in the sense of, "Ok, let's find the first n primes by a simple well-known algorithm, like the Sieve of Eratosthenes") and a simple (non-pure) array-based approach will kick its ass. Such a toy-example just contributes to the wrong belief that Haskell is just useful in academics or teaching. Some time ago I did implement the sieve in several langu…

> Please, get rid off the primes example, as it is horrible inefficient (in the sense of, "Ok, let's find the first n primes by a simple well-known algorithm, like the Sieve of Eratosthenes") and a simple (non-pure) array-based approach will kick its ass. The primes example may be a bit awkward for people with no background in math but it's also an excellent example to demonstrate lazy evaluation in Haskell. The inte…

It's just as if you showed off insertion sort. Even if it looks good, it's not the best algorithm to show off.

Re: The New Haskell Homepage

#220

Post by akurilin »

thinkr wrote: post #181
akurilin wrote: post #112

Earlier quoted context omitted.

Yours isn't an uncommon reaction, don't sweat it. I remember being thoroughly confused by what I was reading back when I started learning Clojure, after years in C# and ruby. At first I thought no normal human being could understand just what the heck was happening amongst all of those parentheses, but eventually it became second nature. Now I've probably written a good 50KLOC in the language and to me it feels seman…

Out of curiosity, was there a specific reason you went from Clojure to Haskell or was it more about exploring a new language? I ask because I am currently learning Clojure, but wonder if there is something unique that Haskell offers.

For me it's mostly about codebase scaling, refactoring and maintainability. Clojure is liberating and exciting when you're writing a tiny little project, but it's a whole other experience when you need to refactor dozens of files because you changed the format of the data being passed around, or you're changing an internal API that's called from a hundred different places.

You better have perfect code coverage, or you'll have no clue why and where something broke (the sink/source problem) or perhaps you won't even find out for a while because that scenario wasn't sufficiently tested and it slips into production. Having a compiler nag you about type inconsistencies is incredibly helpful in these scenarios.

The other big one is working with large blobs of data. Our product has a large analytics component to it, and massaging giant, deeply nested maps representing a certain compendium of statistics is really tough without the compiler spotting you. None of this is an issue when you have to satisfy a certain type, the compiler will basically give you a checklist of things to fix when you change something.

With Haskell you're getting all of the benefits of Clojure (expressiveness, leverage etc), plus the really useful addition of types and enforced purity on top.

Here's another clojurian's experience with switching to Haskell: http://bitemyapp.com/posts/2014-04-29-meditations-on-learnin...

Post reply on HN