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

81–90 of 213 posts

Re: Becoming Productive in Haskell

#81

Post by mightybyte »

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 strongly disagree. In Haskell the compiler helps me think a LOT more than other languages because it's checking more things for me. I don't have to explore things on the whiteboard, I can explore them in code and get very quick feedback about things I might have missed. I have built things in Haskell that I don't think I would have been able to build in other languages. The compiler is your friend, not your enemy. It's like having another developer there to bounce your ideas off of.

EDIT: Bottom line, I think Haskell also works well for people who "see programming as a cybernetic extension of their mind".

Re: Becoming Productive in Haskell

#82

Post by lclarkmichalek »

TazeTSchnitzel wrote: post #78
DanWaterworth wrote: post #64

Earlier quoted context omitted.

This is actually possible with the ConstraintKinds extension in GHC. type Mappable = Functor type NotScaryFluffyThing = Monad This makes Mappable a synonym for Functor and likewise for Monad. (This is not necessarily a good idea; it goes against the principle of least surprise, but it'll work).

Isn't aliasing types a core language feature?

Functor and Monad are technically not types but type classes (i.e. interface vs an implementing class), hence why simple/naive type aliasing is not enough.

Re: Becoming Productive in Haskell

#83

Post by seanmcdirmid »

mightybyte wrote: post #81
seanmcdirmid wrote: post #77

Earlier quoted context omitted.

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 strongly disagree. In Haskell the compiler helps me think a LOT more than other languages because it's checking more things for me. I don't have to explore things on the whiteboard, I can explore them in code and get very quick feedback about things I might have missed. I have built things in Haskell that I don't think I would have been able to build in other languages. The compiler is your friend, not your enemy.…

I didn't make a claim, especially that claim. If haskell requires a lot of up front thinking, then it might turn off those who see programming as a cybernetic extension of their mind (using the computer to help you think, vs. thinking to use the computer). I do not know if the premise was true, but was made by the top level post.

Re: Becoming Productive in Haskell

#84

Post by mightybyte »

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.

Re: Becoming Productive in Haskell

#85

Post by tome »

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?"

This is a standard that Haskell is held to a lot, but I'm not sure how robust a test it is. I never use programs written in Java, for example, and I use a program written in Scheme every week. That doesn't say much about their relative popularity, let alone their quality as programming languages.

Presumably I use server-side applications written in Java, but I've no way of telling. If server-side counts then most people with computers indirectly use Haskell via Facebook's Haxl project.

Re: Becoming Productive in Haskell

#86

Post by tragic »

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?"

I've mentioned this before, but there's a lot of music stuff written in Haskell - tidal[0] (DSL for live-coding electronic music, not the 'save Jay Z from penury for $20/month' initiative that has just clobbered its google results) and Euterpea[1] spring to mind.

[0] http://yaxu.org/tidal/ [1] http://haskell.cs.yale.edu/euterpea/

Re: Becoming Productive in Haskell

#87

Post by krick »

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

Earlier quoted context omitted.

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 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?

Re: Becoming Productive in Haskell

#88

Post by dllthomas »

imakesnowflakes wrote: post #70
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…

>While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?"... Wouldn't Scripting languages allows one to gradually build that understanding. Suppose you end up with a lot of complex code? Ditch it and build it from scratch. Usually takes around 1…

In my experience, to borrow seanmcdirmid's terminology below, one can use Haskell as a "program to think" language - and in fact Haskell brings some significant tools to the table that I miss when I'm using Python to feel around a problem, to the point that I often choose Haskell for this. In both languages, writing small pieces of code and examining their shape and their output can be helpful in growing my understanding of the solution space, but I find that Haskell tends to let me ask more complete questions with less complete code.

Re: Becoming Productive in Haskell

#89

Post by [deleted] »

wyager wrote: post #72
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.

That would be wrong. Functors also describe things that aren't necessarily "mappable". The actual definition of functor is more general than that.

[deleted]

Re: Becoming Productive in Haskell

#90

Post by TuringTest »

imakesnowflakes wrote: post #70
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…

>While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?"... Wouldn't Scripting languages allows one to gradually build that understanding. Suppose you end up with a lot of complex code? Ditch it and build it from scratch. Usually takes around 1…

> Wouldn't Scripting languages allows one to gradually build that understanding.

Lately I've reading this[1] academic paper about End-User Software Engineering. While not an easy read nor a good introduction if you've never read about End User Development, it delves precisely on methods for building tools that allow just that, while adding opportunistic checks to correct bugs.

[1]http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.360...

Post reply on HN