Live data from Hacker News

Becoming Productive in Haskell

mechanical-elephant.com

111–120 of 213 posts

Re: Becoming Productive in Haskell

#111
post #57
post #49

Earlier quoted context omitted.

Maybe someone can correct me here, but that kind of approach seems ill-founded to me when after a couple examples, people are already talking about different things using the same terminology. The article says "A list is a Functor". Now you're saying "Either is a Functor". But those two things don't have the same nature. Maybe what the author meant "The [] list constructor is a Functor"? I'm not sure what is gained b…

There's no subset, no garbling; Functor literally has one member, map (fmap in Haskell but that's a historical artefact).

More specifically, a pedagogical artifact. Originally, fmap was spelled map. The list-specialized map was added to make teaching easier.

Re: Becoming Productive in Haskell

#112

Earlier quoted context omitted.

The Haskell wiki has a page called "Haskell in industry" [0] which lists all the people using Haskell in the real-world. Some notable ones include: * Facebook Haxl, an abstraction around remote data access [1] * Microsoft Bond, a cross-platform framework for working with schematized data [2] * Google Ganeti, a cluster virtual server management tool [3] * Intel Haskell research compiler, a custom Haskell compiler used…

Anytime a technology needs to publish a list of "who's actually using this in the real world" the answer is not all that many (relative to other peer technologies). Most projects in those lists fall into the following categories: 1. It is just a small team or even one person using it and they're doing it because they really want to use that technology badly. 2. The project is some side research thing or trivially sma…

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.

Re: Becoming Productive in Haskell

#113
post #87

Earlier quoted context omitted.

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

If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that). While quite fast, it is not in the league of low level programming languages. If you need ridiculous speeds, you don't have another choice but to use C, C++ or Fortran. Python has a lot of very useful modules. If I can solve my problem with b…

Haskell does support mutable arrays. Your code that does the mutating will have to live in IO (or perhaps ST), but the downsides of that are exaggerated.

Re: Becoming Productive in Haskell

#114
post #87

Earlier quoted context omitted.

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

If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that). While quite fast, it is not in the league of low level programming languages. If you need ridiculous speeds, you don't have another choice but to use C, C++ or Fortran. Python has a lot of very useful modules. If I can solve my problem with b…

I mean, there are Data.Vector.Mutable, though I haven't needed to use them yet.

Re: Becoming Productive in Haskell

#115

Earlier quoted context omitted.

Anytime a technology needs to publish a list of "who's actually using this in the real world" the answer is not all that many (relative to other peer technologies). Most projects in those lists fall into the following categories: 1. It is just a small team or even one person using it and they're doing it because they really want to use that technology badly. 2. The project is some side research thing or trivially sma…

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 will ever be used widely. They just aren't appropriate for most general purpose programming tasks.

Re: Becoming Productive in Haskell

#116

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…

No. The debugging time, refactor/rewrite time of writing in scripting languages is substantially longer, harder work, and distinctly unpleasant compared to just thinking and using good tools to do it right in Haskell.

In Haskell, I'll often have a problem and just stare at my laptop and think for an hour. Then write a dozen lines of simple, straightforward code. The code is easy to test, and the problem is marked as "solved" instead of "seems to work" as happens in scripting languages.

Edit: auto complete fixes

Re: Becoming Productive in Haskell

#117

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…

Different languages lead to different exploratory behaviors.

Haskell makes it very safe to change your code, but it adds some initial costs. Scripting languages make it very unsafe to change the code, unless you spend a lot of time writing tests, but then they stop being fast to iterate.

Re: Becoming Productive in Haskell

#118

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…

Absolutely, Haskell has a richness of concepts to it that's entirely in a class of its own... but that being said, Haskell is to programming what sex is to life (for a woman... because men's natural enjoyment of sex throws off my following analogy). Granted there is richness and joy in finally discovering it, one needs to realize it's important that one isn't forced into it too early. Haskell demands a lot of thinking up front and therefore requires a programmer of a certain logical / organizational maturity in order for the process not to be frustrating and painful (or even traumatizing). Haskell (like C, Lisp, and the arcane slog known as Erlang) should rarely be someone's first language.

And that's where Ruby, Python, Javascript, and to some extent Matlab come in. For whatever else people may say about them later (they don't scale, they're a roadblock, they're a mess, null is not a function, etc.), they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex.

After all, programming, like literally everything else, is 99% human and 1% logic, machines, data, "scaling", etc. Programs are written by people for people (incidentally they can also be read by a computer), so it's incredible important that the 99% of that equation (you the programmer) don't become discouraged at the onset by an extremely elegant, expressive, but rather rapey language before you're ready for it. In that sense, it's absolutely okay to be "seduced" by an easy scripting language in the beginning. Eventually, though, when you start lamenting about "undefined is not a function" and how that could be so easily avoided when proper type-checking, that's your body telling you that you're ready for Haskell now.

Re: Becoming Productive in Haskell

#119

I really like Haskell, but one of the main problems I've had (that I don't see many people cite) is that the libraries just aren't made for use under serious load/concurrency. Many of the people that have written these libraries, and use them are not using them in high-performance, memory-sensitive areas (production use at companies). There are Haskell libs of course that are used in these environments, and the compa…

Haskell has a problem in that people think about the basic libraries as deprecated, but won't deprecate them due to backward compatibility. Thus, people starting on it will get plenty of slow and unsafe constructs, while people used to it only look at the fast and safe ones.

There should be warnings all over the Prelude and basic libraries documentation.

Re: Becoming Productive in Haskell

#120
post #23

Whenever I try to be productive in Haskell I end up taking the research phase too far and end up over-my-head in category theory that I don't understand. I'm never productive in Haskell.

Start by coding. Be prepared to rewrite your first big project once or twice (good thing is that you'll realize it needs a rewrite sooner, rather than later - anyway, don't start with something too big), but start coding. You won't learn it by reading.
Post reply on HN