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

Becoming Productive in Haskell

mechanical-elephant.com

Post reply on HN
Print view View original

91–100 of 213 posts

Re: Becoming Productive in Haskell

#91

Post by vilhelm_s »

seanmcdirmid wrote: post #77
jplahn wrote: post #71

Earlier quoted context omitted.

I think that's an interesting point, _if_ people actually do that. That said, I'm wary of the claim of 1/10th time and being able to iterate 3 or 4 times per every one iteration with Haskell. Sure, maybe when you're starting out, but once you become proficient I don't think that would be the case anymore. And, there's no guarantee that 3rd or 4th iteration will be as good as the well thought out Haskell code, since t…

The point is that a scripting language is a "program to think" language, while haskell is often seen as a "think to program" language (at least when described as in the top level post). That you have to do more thinking and planning when using haskell (supposedly) doesn't help when the problem you are working on is not well understood and requires exploration (where you are forced to do exploration in your head...or…

I think part of it may be that it helps with thinking, but with a different kind of thinking than scripting languages?

There's that Perlis quote: "Show me your data structures, and I won't usually need your code; it'll be obvious". For me, a lot of thinking about programs involves thinking about the types of data involved, and there Haskell gives a language to talk about it. You can start writing down your datatypes, and the function types, directly in your emacs buffer (leaving the function bodies as just "undefined" at first). By contrast, if you are programming in some untyped language like Scheme, you have to do all that work inside comments---e.g. if you write a compiler you maybe start by writing a huge comment saying "this is the grammar I expect input expressions to follow". Having a type language around kind of helps by providing a notation.

I guess there is some other kind of exploratory thinking which untyped langauges provide a good notation for? But in my life I have mostly worked in typed languages, so I don't have any concrete idea of what it is.

Re: Becoming Productive in Haskell

#92

Post by dllthomas »

krick wrote: post #87
QuantumRoar wrote: post #48

Earlier quoted context omitted.

I didn't try to say that Haskell is the best language for everything. I also wouldn't want to do everything in Haskell. But as you are pointing out, you learned a lot from Haskell and you are using its lessons in production. The best a language can do is to fill a niche and to be very good at that particular thing. You should always use the language that is most suited for your problem, whatever that is. But there ar…

> I also wouldn't want to do everything in Haskell. Examples, please? And why?

Lack of dependent types? :-P

Re: Becoming Productive in Haskell

#93

Post by danneu »

IanCal wrote: post #2

I really liked this article, in particular the sections around learning things like Functor and Monad (if you haven't read the article, don't worry, it's not a list of new explanations that's why I like it). A minor wording recommendation: > better in every measure(lower complexity, speed, readability, extensibility) Apart from a missing space before the parenthesis, this reads like there was lower complexity, lower…

Could just change "lower complexity" to "simplicity".

Re: Becoming Productive in Haskell

#94

Post by prajjwal »

As someone who recently groked some of the higher order Haskell concepts, I found myself nodding at everything this says.

An RSS feed would be great.

Also, does anyone know what colorscheme this is using for the code samples? Looks nice.

Re: Becoming Productive in Haskell

#95

Post by musername »

harry8 wrote: post #9

I don't think I have ever used a haskell program written by someone else that wasn't ghc. Is that usual? Are there now a bunch of .debs for useful things other than writing haskell that are actually written in Haskell? I'm not trolling, it's just a good test of what something is useful for when it's been around a while is to ask "Well, what has it actually been used for?"

protoype for sel4 is written in .hs

Re: Becoming Productive in Haskell

#96

Post by michaelochurch »

1971genocide wrote: post #34
QuantumRoar wrote: post #25

Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…

And what makes the model of haskell any more superior to models developed in any other field like accounting, physics or chemistry ? I am sorry, haskell is just a huge roadblock to get things done in the real world. In the real world proffesional need to juggle all sorts of models. Haskell just says "Fcuk you ! its my way or the gonadway !". I need to juggle between json, matrix, html, etc. Each of them have hundreds…

I am sorry, haskell is just a huge roadblock to get things done in the real world.

Languages tend to suffer from an Iron Triangle: quick to write, quick execution, quick to learn-- pick 2. Haskell takes a long time to learn but it produces very high-quality executables and, once you know it, it's very productive.

While "quick execution" may seem separate from the type safety which is also a major selling point of Haskell-- and, arguably, a bigger one-- they're actually tightly coupled. Safe code can be optimized more aggressively, and it's often for the sake of performance that unsafe things are done... so the fact that Haskell can be robust and generate fast executables is a major win.

Haskell just says "Fcuk you ! its my way or the gonadway !"

It doesn't, but I am going to start saying this. Thank you for the inspiration.

Apparently mutation is a crime

Not so. Every program's main method has type signature IO (), which means that it does perform mutation. You just want to get as many functions as possible not to involve mutation because it's easier to reason about them. It's a similar principle to dependency injection, but more robust and clear.

However the implementation of haskell is not really ready for production or useful enough for the average developer.

I disagree. With Clojure and Scala, I've met people who've used them and moved away. Satisfaction rates seem to be about 60% with Scala (that is, 60% of teams or companies that make a major move to Scala are happy) and 90% with Clojure. I've never heard of anyone who's become unhappy with Haskell or rolled back on it.

One of the dangers of using Scala, for an example, is that, if that if your Scala deployment doesn't work out (or is sound but is blamed by the business for something unrelated) you can get stuck doing Java. Haskell, at least, doesn't have that problem.

Re: Becoming Productive in Haskell

#98

Post by lmm »

tormeh wrote: post #66
lmm wrote: post #4

> So, I started calling it Mappable. Mappable was easy for me to remember and was descriptive of what it did. A list is a Functor. A list is Mappable. I wish there was a language or library that was willing to take the Haskell functionality and just give it all names like this.

In Scala there aren't any names for functors that I'm aware of. I just though one day that "wouldn't it be practical if I could map an option instead of match-casing the meaning out?" and lo and behold it worked. Maybe we just don't need that much terminology.

You need a term for "thing that I can map" if you want to be able to write a function that takes a generic "thing that I can map". Which I do.

Re: Becoming Productive in Haskell

#99

Post by dllthomas »

david-given wrote: post #14

The author's comments on noise chime true with me: every time I give Haskell a try I end up struggling with frustrating and opaque vocabulary, sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they're completely unrelated to Haskell functors. I really like the author's suggestion of mentally translating Functor to Mappable. Are there any other synonyms for other Haske…

As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront.

I agree that a shared vocabulary is important, but standardizing in a way that makes the mathematical writings on the topic more accessible seems a big win. Moreover, "functor" is a bit more precise than "mappable" - a functor is a mapping that preserves structure. In what sense? The math can guide you. In this case, it means the functor laws.

That's not to say that coming up with other associations to help ease understanding is a problem - I have no problem with saying, "for now, think of Functor as 'mappable'". The equivalent for Monad would probably be "flatMappable", and Monoid would be "appendable".

Re: Becoming Productive in Haskell

#100

Post by estefan »

mightybyte wrote: post #84
estefan wrote: post #7

Nice article. I find FP incredibly elegant and I'd like to learn Haskell, but every time I search, there are never any jobs in it, so it seems like Scala is the better choice for where I live... Speaking of which, I found "Functional Programming in Scala" excellent for teaching someone with an imperative background how to "think functionally". Monads are explained in an easy to understand way. I can imagine that with…

If you wait for the jobs to come, you'll be late to the party. Very few people will want to hire someone who doesn't know Haskell for a Haskell development position. Learn it now so you'll be up to speed when more jobs start appearing. Or better yet, learn it and then create the Haskell jobs yourself.

A truly stupid comment.
Post reply on HN