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

The Haskell user experience

rickdzekman.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: The Haskell user experience

#21

Post by haxeny1 »

TazeTSchnitzel wrote: post #4

The Haskell Platform obscuring Cabal's existence bit me. I didn't know how to use Cabal, so for a while I didn't install any packages, or know the correct way to build them.

I can relate to that because it took me a while to using cabal repl actively as i code. Once i discovered cabal repl, I found that i could test my database (yesod) business logic during my normal development cycle. This was very re-assuring to me, coming from an oo, java background. Writing tests is nice, although having a small function to test a particular usecase while development is quite empowering. The only caveat, being, I seem to have to export my tests as part of the main module. There are ways to restructure it, say creating DBObject (export crud/management) DBObject.Internal (will all methods exported).

This is one place i miss the selective export of features that Eiffel provides. I am still not certain as to why other languages (except perhaps sather) completely ignored this seemingly simple syntactic feature that would have saved so many of us from creating parallel hierarchies as in java or artificial structures in haskell.

Re: The Haskell user experience

#22

Post by AnimalMuppet »

platz wrote: post #19
sfvisser wrote: post #9

Earlier quoted context omitted.

> Trying to debug a memory leak caused by insufficient strictness --- why do I need to care about this? The runtime should just take care of it for me; the whole point of a lazy language is that I shouldn't have to care when evaluation happens. This is a completely wrong assumption. The point of laziness is not so you won't have to care about evaluation order. Everyone would like to have a language in which you don't…

intuition about lazy evaluation order can be very misleading

Is it fair to say that in Haskell, you have to think about evaluation order less, but when you do, it's harder?

Re: The Haskell user experience

#23

Post by AnimalMuppet »

> But at the end of the day I’m still a Developer in an Academic world. And more and more Haskell is attracting the kinds of developers who don’t know Lambda Calculus or Type Theory.

Haskell's ability to become a major language depends on its ability to attract, and keep, that kind of developer. There aren't enough developers who will learn all the theory in order to learn a programming language for Haskell to become one of the dominant languages.

Re: The Haskell user experience

#24

Post by safewayclubcard »

david-given wrote: post #2

My experience with learning Haskell was: When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem. When it's…

> Trying to find where an a out-of-bounds list error was happening

I agree that in some real world runtime debugging, haskell falls short, due to the strictness that it imposes and how observation through debugging can change how the code executes. I have also spent a week or more tracking down a memory bug that was solved by a single `!` (to add strictness).

But the glory of haskell, is that you really don't need to debug runtime code. If you take advantage of the types

Having used haskell for about 5 years now, I think anywhere that you can even have an out-of-bounds list error is an anti-pattern. You should restructure your data to match the type.

Using list lookups aren't what lists are for. Unless you are implementing a specific algorithm, manipulation and access of lists should only be done via folds, maps, pattern matching or similar functions.

If you are accessing members of a list directly by their index, you want a different data structure

Re: The Haskell user experience

#25

Post by jonnybgood »

AnimalMuppet wrote: post #22
platz wrote: post #19

Earlier quoted context omitted.

intuition about lazy evaluation order can be very misleading

Is it fair to say that in Haskell, you have to think about evaluation order less, but when you do, it's harder?

When you hit that difficult to reason about evaluation order in Haskell, it'll take that time you thought you gained.

Re: The Haskell user experience

#26

Post by Arnor »

marcosdumay wrote: post #20

Haskell has all the features of languages that become mainstream and mandated top-down on workplaces. I wouldn't be much surprised if in a decade people start complaining about Haskell-shops they way we complain about Java-shops now. (But then, no language could get there without a marketing budget...) Haskell lets big teams collaborate very well, makes it hard to bad coders to destroy an entire project, consist in a…

That package looks useful. Thanks for sharing!

Re: The Haskell user experience

#27

Post by oconnore »

AnimalMuppet wrote: post #22
platz wrote: post #19

Earlier quoted context omitted.

intuition about lazy evaluation order can be very misleading

Is it fair to say that in Haskell, you have to think about evaluation order less, but when you do, it's harder?

I think it can be unexpected if you're used to other semantics, but the behavior of laziness is very well defined.

    > let x = [1 .. 100] :: [Int]
    > seq x () -- force the first cons
    > :sprint x
    x = 1 : _ -- we evaluated the first cons
    > foldr (\e l -> e + l) 0 x
    5050 -- printing this value forces foldr to complete
    > :sprint x
    x = [1,2,3,4,5...100] -- all conses evaluated

Re: The Haskell user experience

#28

Post by safewayclubcard »

platz wrote: post #19
sfvisser wrote: post #9

Earlier quoted context omitted.

> Trying to debug a memory leak caused by insufficient strictness --- why do I need to care about this? The runtime should just take care of it for me; the whole point of a lazy language is that I shouldn't have to care when evaluation happens. This is a completely wrong assumption. The point of laziness is not so you won't have to care about evaluation order. Everyone would like to have a language in which you don't…

intuition about lazy evaluation order can be very misleading

I agree with this statement.

I think lazy evaluation is very hard, especially when you are dealing with a codebase of of say 50 files with structures containing other structures, the line between lazy and strict is very hard to see.

The difficulty learning lazy evaluation skill goes from

* 0 where you know nothing to 5 where you sort of understand.

* 5 - 90 is a space where you think you know what it is, but you really don't. You'll probably get yourself in trouble more than helping.

* 90-100 is when you grok it and can use it effectively.

I am an avid haskell user for a few years and I am still 50/50 on most of my conclusions about laziness without asking someone else.

Re: The Haskell user experience

#29

Post by creichert »

david-given wrote: post #2

My experience with learning Haskell was: When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem. When it's…

> Lack of information on a runtime exception.

The -xc runtime option does just that, with a stack trace[0].

  ./app +RTS -xc
> Total lack of debugging tools

I wouldn't exactly say there is a total lack. To name a few:

Thread Scope: https://wiki.haskell.org/ThreadScope

Event Log: https://ghc.haskell.org/trac/ghc/wiki/EventLog (capable of live monitoring)

GHCi Debugger: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

EKG: https://hackage.haskell.org/package/ekg

I also consider type system features to be a very useful form of tooling:

Typed Holes: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Deferring Type Errors: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Partial Type Signatures: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

[0] - Can't direct link, look for -xc here: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Re: The Haskell user experience

#30

Post by baldfat »

kmicklas wrote: post #16
baldfat wrote: post #5

Personally I switched from learning Haskell to learning Racket and couldn't be happier. On the other side of banging my head I think Cabal is the biggest disappointment of my experience and it was the worst package management headaches for my own private builds. Now that I am done with a book of Haskell and being a total hack at Haskell with very little skills (I did learn quite a bit of Lambda Calculus along the way…

> I think there is a BIG reason why Haskell has not grown in popularity in language usage and is beat by Scheme and almost beat out by ML. Is it? I would think there is easily WAY more Haskell currently in use in both industry and academia than Scheme. Certainly the mindshare is much, much larger. I have no idea where ML is, but it seems like it should be roughly on the same order as Haskell, and surely beating Schem…

Well take this with a HUGE grain of salt but:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

Also : http://langpop.com/

Post reply on HN