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

191–200 of 213 posts

Re: Becoming Productive in Haskell

#191

Post by djur »

arbsn wrote: post #140
x0054 wrote: post #139

Could you guys explain to me what Haskell would be mostly useful for. For instance, can it be used to make a web app backend or a GUI app? Or is it mostly for mathematical calculations and such. I tried to pick up Haskell once, but I guess I just couldn't get it. I mean, I got the core concepts, wrote a bunch of starter code, like prime checker and the like. But after going through several tutorial chapters, I still…

What confuses you about using Haskell for writing Web/Desktop/Mobile apps? System.IO exposes all the primitive input/output functionality one would expect in Swift, Python, or PHP, and there is an abundance of higher-level libraries for networking, parsing, graphics, etc. Haskell even has a fairly usable C FFI. Haskell is a general purpose programming language.

A popular introductory text like Learn You A Haskell doesn't introduce IO until chapter 9. It never gets beyond simple toy programs and the only further resource suggested (in the FAQ) is Real World Haskell.

RWH is well-written and covers some real-world tasks, but some of its examples are outdated enough that they don't even compile anymore (at least, I encountered that scenario a year ago or so) and Haskellers will frequently warn people that parts of it are out of date (see elsewhere in these comments).

I actually think one of the shortcomings of Haskell's approach to new developers is that it _is_ very much a general purpose programming language and sold as such. Other languages have extremely popular frameworks or applications which serve to attract newcomers. People teach Swift or Objective-C to write iOS apps, Java for Android apps, JavaScript to do web apps, Ruby to write web backends in Rails, C# to write games in Unity... hell, people learn Java to make Minecraft mods. The closest thing I can think of for Haskell is Xmonad, which doesn't exactly have mass appeal.

Someone else suggested "Write Yourself A Scheme" as a good practical introduction, and that in itself says a lot about who Haskell appeals to -- people who are interested in programming languages. The MLs and Haskell remind me of Brian Eno's line about how the first Velvet Underground album only sold 30,000 copies, but "everyone who bought one of those 30,000 copies started a band".

Re: Becoming Productive in Haskell

#192

Post by sridca »

gr8b8m8-88 wrote: post #168
throwaway232 wrote: post #148

Earlier quoted context omitted.

so men want sex more than women because of some statistic that you didn't even bother to fully pull out of your ass? nice

Here's a study (scroll to page 6 for the table): http://www.hawaii.edu/hivandaids/Gender_Differences_in_Porno... Now combine that with some data from Christian Rudder's Dataclysm (just a link to a info-pic + summary article here): http://www.bloomberg.com/bw/articles/2014-09-04/mining-okcup... Men consume a lot more porn than women and hunt for casual sex a lot more than women. Actually, if you weren't so rustled, yo…

Taking only graphic porn into consideration is a bias; women consume 'porn' in the form of romance novels.

"By and large, men prefer images and graphic sex sites; women prefer erotic stories and romance sites." - http://rescuefreedom.org/parallax/wp-content/uploads/2015/01...

Re: Becoming Productive in Haskell

#193

Post by wetmore »

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

The bank Standard Chartered[1] uses it, and instead of GHC they use their own compiler. There's some more info in this job posting[2].

[1] http://en.wikipedia.org/wiki/Standard_Chartered [2] https://donsbot.wordpress.com/2014/08/17/haskell-development...

Re: Becoming Productive in Haskell

#194

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.…

On your edit, I also didn't make that claim. All my premises are open.

Re: Becoming Productive in Haskell

#195

Post by dasil003 »

jayvanguard wrote: post #115
Guvante wrote: post #112

Earlier quoted context omitted.

While your point isn't invalid it is important to keep in mind that popularity is not a valid proxy for quality. Also he is focusing on large companies who have huge reasons they can't use Haskell, mostly related to internal resources. If you have several hundred Java engineers (for example) you literally cannot just switch to Haskell, it wouldn't work.

Completely agreed about quality. Popularity is highly correlated to actual utility though. Lisp falls into the same category. High quality and very interesting but it will never, ever gain widespread use. Don't believe me? A half century of proof exists. Haskell is already at a quarter century. Both are very cool and everyone should learn them to some degree because they will make you a better programmer but neither…

I would be wary of painting Haskell and Lisp with the same brush. Yes, on first glance they both appear to be "difficult" languages that are over the heads of the average programmer. However they take very different approaches.

Lisp gives the programmer maximum raw expressive power. This appeals to lone wolves and autodidacts, but it completely punts on the issues of standards, teamwork and maintainability.

Haskell on the other hand, promises a direct solution to a huge swath of problems that are experienced across the board in software development today. The pitch is essentially an extension of what Sun used to sell Java in the 90s: it makes your code safer and more maintainable. Except Java only really did that for memory management in a C-dominated world, the type system gives you barely anything in that regard, so you still have just as many NullPointerExceptions as you suffer from lack of types in languages like Ruby. Haskell type system gives you infinitely more meaningful safety, but with suitable state-of-the-art functional abstractions to minimize the pain of acquiring it.

The only catch is the learning curve is steep, but as more and more programmers scale that wall, the benefits to performance and maintainability will become apparent to the pointy hairs. Lisp never really had an equivalent value proposition, except in a few narrow fields where its expressiveness and plasticity were key.

Re: Becoming Productive in Haskell

#196

Post by codygman »

windlep wrote: post #177
bsummer4 wrote: post #110

Earlier quoted context omitted.

Could you name some of these libraries? IME, most of the libraries that are needed for common things are very mature.

I tried to write a Haskell websocket server, the library is quite nice, but it leaked memory (space leak? fragmentation? some of both?): https://github.com/jaspervdj/websockets/issues/72 The author helped me narrow it down to some issues with how ghc by default allocates a stack space that is rarely enough, and once it starts growing the stack space the RAM per connection gets pretty ridiculous. Using higher default…

Great comments and better bug reports, just want to mention it actually says to always re-use Session in the wreq tutorial[0]. Perhaps it should be stated more prominently, repeated, or even both.

    For non-trivial applications, we’ll always want to use a Session to efficiently and correctly handle multiple requests.

    The Session API provides two important features:

    When we issue multiple HTTP requests to the same server, a Session will reuse TCP and TLS connections for us. (The simpler API we’ve discussed so far does not do this.) This greatly improves efficiency.
0: http://www.serpentine.com/wreq/tutorial.html#session

Re: Becoming Productive in Haskell

#197

Post by cousin_it »

vilhelm_s wrote: post #91
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 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,…

The quote is from Fred Brooks (author of "The Mythical Man-Month"), and it goes like this:

> Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.

I don't think it's about exploratory programming. It's more about reading other people's code.

Re: Becoming Productive in Haskell

#198

Post by [deleted] »

sridca wrote: post #192
gr8b8m8-88 wrote: post #168

Earlier quoted context omitted.

Here's a study (scroll to page 6 for the table): http://www.hawaii.edu/hivandaids/Gender_Differences_in_Porno... Now combine that with some data from Christian Rudder's Dataclysm (just a link to a info-pic + summary article here): http://www.bloomberg.com/bw/articles/2014-09-04/mining-okcup... Men consume a lot more porn than women and hunt for casual sex a lot more than women. Actually, if you weren't so rustled, yo…

Taking only graphic porn into consideration is a bias; women consume 'porn' in the form of romance novels. "By and large, men prefer images and graphic sex sites; women prefer erotic stories and romance sites." - http://rescuefreedom.org/parallax/wp-content/uploads/2015/01...

[deleted]

Re: Becoming Productive in Haskell

#199

Post by julian_perrott »

agarden wrote: post #188
julian_perrott wrote: post #5

Nice article, i've been learning Haskell for about a month solving kata on http://www.codeswars.com/ using https://www.fpcomplete.com/ as my IDE. I'm finding it quite a learning curve understanding what library functions there are and how to use them. The code I write often ends up being quite different to the other solutions on codewars. I'm missing Visual Studio, are there any realy good Haskell IDEs out there? for…

lamdu has some interesting features: http://peaker.github.io/lamdu/

Love the Bret Victor talk mentioned on the Lamdu page: https://vimeo.com/36579366 "Bret Victor - Inventing on Principle"

Re: Becoming Productive in Haskell

#200

Post by dmytrish »

jonnybgood wrote: post #176
krick wrote: post #87

Earlier quoted context omitted.

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

I heard Haskell is a poor choice for real-time systems and numeric computation. It's kinda ironic that a language as "mathy" as Haskell is such a poor choice for doing actual math. Assuming these things are true.

This definition of "the real math" is quite arguable. Doing a lot of computations efficiently is a realm of modeling and statistics; that does not clarify the very nature of computation, the inner laws of formal systems. Haskell is much more about "what computation is" than about "how to do computations".

Besides that, from mathematician's point of view, "efficient numerical computation" is a necessary and useful practically, but very ugly thing. Speaking of C-like types `int`/`long`/`uint32_t`: they are only a crude approximation of natural numbers, they are a ring modulo 2n, which we pretend to use as natural/integer numbers, silently failing when this range wraps up.

And that is not the end of the story: for integer numbers we can at least specify what mathematical model describes them (a ring modulo some power of two), for floating point numbers it is impossible: set of possible IEEE 754 values is a very weird and irregular finite set of values (NaN, +Inf, -Inf, +0, -0, exponential distribution of points density with min/max bounds) with complex modes of failure. Associative law, distributive law, commutative law? The very equality check? Forget about it, floating point numbers have none of that.

Post reply on HN