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).
Becoming Productive in Haskell
111–120 of 213 posts
Re: Becoming Productive in Haskell
#112Earlier 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…
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
#113Earlier 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…
Re: Becoming Productive in Haskell
#114Earlier 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…
Re: Becoming Productive in Haskell
#115Earlier 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.
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
#116Scripting 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 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
#117Scripting 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…
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
#118Scripting 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 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
#119I 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…
There should be warnings all over the Prelude and basic libraries documentation.
Re: Becoming Productive in Haskell
#120Whenever 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.