No wonder it felt like the author was living in a different universe.
> It's a transcript of the following talk by R. Martin with some substitutions made (SmallTalk -> Haskell, Ruby -> Rust, and others).
Another thread on this article: https://news.ycombinator.com/item?id=24449927
A large proportion of the talk linked below is based on the book “Crossing the Chasm".
The book was originally written for startups trying to break into the mainstream, and this talk adopts that book to programming laguage (or tools more generally), particularly regarding Haskell.
Gabriel Gonzalez – How to market Haskell to a mainstream programmer: https://www.youtube.com/watch?v=fNpsgTIpODA
Gabriel also suggests that in order to "cross the chasm" you have to offer a best-in-class experience in some area, and suggests that Haskellers adapt the language to facilitating building interpreters, which is it particularly well suited for.
So, base on the above, I don't think the OP's emphasis on the emotional analysis of Haskell programmers is anything more than the OP's just-so story, although the notion of parochialism may have some crossover with the concept of marketing.
I think this is the key. The motto that you mentioned is often clarified/refined as something like "avoid 'success at all costs'".
But these problems require money and expertise and marketing from people who already are in the field, so a bit of chicken-egg problem.
Arrogance is the last thing i would say about haskell community and i have interacted with them on reddit and irc. So not sure about that.
The thing about ignoring enterprise needs is that the enterprises need to invest in the things they want. Those that do contribute are using haskell in enterprises that fit their needs. Otherwise it is primarily a research driven language.
It's not very surprising that Go/Java is doing very well, looking at the investment done by the companies behind it.
Stack and stackage made package management much easier for me. I am an enthusiastic, but not great Haskell programmer so I like running the ‘hlint’ linter program for hints on improving my code.
My heart is really with Common Lisp, but Haskell is also a pleasure to use and the tooling seems much better to me than five years ago.
Haskell is really cool, but IMHO is held back from practical adoption by two things, one technical, one cultural:
- Lazy by default maps weirdly onto von Neumann machines. Laziness is cool but doesn’t pull it’s weight as the default. Performance in time and space is even harder to reason about than it already is on modern architectures, and debugging is...different.
- GHC extensions are like crack for the kind of people who overdo it with C++ templates. Pragmatic, legible Haskell in the RWH tradition isn’t safe from the type-theory zealots even in a production system. Cool research goes on in GHC, but it’s hard to keep everyone’s hand out of that cookie jar in prod.
And yes, reasoning about memory consumption and having each library give you 2 versions (strict and lazy) of their data structures is tiresome. Why can't strictness/lazyness be parameterized away?
I don’t think so. What killed Haskell in mainstream programming is its weird syntax. Rust looks like C so it passed that first sanity check. People hate that something so aesthetically basic could define the success of programming languages, but it seems pretty clear at this point. Languages have to basically look like C in order to be popular.
Nothing in Haskell was sufficiently interesting to justify overcoming the conceptual barriers and different culture.
[1]:http://dev.stephendiehl.com/hask/#eightfold-path-to-monad-sa...
[2]:Regular expression tutorials, by contrast, virtually never attempt to explain regular languages or automata theory, which is why nobody complains about having to learn formal language theory in order to use `sed`.
A surprisingly digestible (and concrete) explaination of monads (Ch 2): http://www.cse.chalmers.se/~rjmh/Papers/arrows.pdf
I program in C for a living, and no, Rust doesn't look like C. In fact, one of the things that keeps me away from learning Rust is that it is so complicated in terms of syntax.
Today I was reading this HN entry (https://news.ycombinator.com/item?id=24404628) and there is a little Rust code snippet towards the end, and I was thinking "this is so fck'd up, I'll never grasp Rust".
> Languages have to basically look like C
I wish they do.
> there is a little Rust code snippet towards the end, and I was thinking "this is so fck'd up, I'll never grasp Rust"
After you mentioned it, I had to try to read it, and not programming in Rust, I'm surprised that there was a need to "clone" the "references" to the single value which would be accessed by each spawned thread using the "Arc" "reference counter."
A question for those who really know Rust:
As it is a single value, in C or C++ I could do the atomic access without any "cloning" and doing "reference counting" with something like "Arc" and it would still be safe. What am I missing? Was it necessary in Rust or was it an example of a demonstration that did more than actually needed?
For me, it's always more than just syntax that is to understand.
First, it’s the first language I’ve used in any capacity where I can’t mentally map the syntax. The orders of precedence are way too complicated, and the end result is that I end up blindly throwing $’s at the code until eventually it works. I have no idea why it has to be this hard.
Second, indentation. Seriously, indentation. Haskell is one of those accursed languages, along with Python, where indentation is apparently just utterly broken. I have yet to see A Haskell editor that can offer much more than the ability to cycle through the possible indentation levels given the context. It’s maddeningly bad, and often most editors can’t clean it up after the fact either.
The problem is that highly valuing "first-principles thinking" is wrongfully attributed to arrogance and seen as "ignoring truths from the 'dirty' mainstream".
That kind of behavior is borderline toxic, and I hope it's not representative of the Haskell community.
If you're going to accuse me of being toxic, please be explicit with quotes and what specifically was toxic rather than unconstructive allegations.
Golang was publicly announced at the end of 2009.
-I used to hang out at lambda-the-ultimate, in which haskell was considered god sent and c++ a toy language. At the time, I was heavy into writing simulation software, which meant c++ all the way, so I tried to understand haskell and its advantages over c++, but my attempts ended up being mocked. I stopped visiting that site.
-I tried to open some debates about Haskell on reddit, where someone told me they will answer my haskell questions only if I told them a specific mathematical definition on some properties of functions. I didn't know the reply, I was a programmer after all, not a mathematician. Said person left me in the cold.
-again on reddit, I was trying the debate the usefulness of haskell regarding simulation software, which relies heavily on updating variables, but I never got straight answers. To this day, I still do not know if haskell code actually can update variables in place or it only simulates updating of variables. Someone suggested using lens, and although I understand the abstraction, it still has not solved my question if haskell can update variables in place.
Why I was so interested in this aspect, i.e. in place updating? I wrote simulation software and after that game software for a living, and it matters to me because I want to be able to reason about the performance of my program. I don't want to have data be duplicated behind my back.
To cut the long story short, my haskell questions go unanswered to this day, I was very disappointed, and since I have great experience in imperative programming languages, I usually write programs that are correct as soon as they are compiled, which is what the haskell advantage is supposed to be. So I don't see any benefit from haskell, and I won't recommend it to my company or my colleagues.
Am I wrong regarding haskell? perhaps, but I am not interested any more in 'trying out' languages of dubious gains, nor am I interested in dealing with juvenile behaviors. I tried Rust because it had a serious advantage over C++ (namely, object lifetimes), and I will recommend Rust, but my patience for and interest in haskell is virtually non-existent at this point.
Haskell can, in fact, update variables. Mostly through 2 mechanisms:
- ST (a computation containing local, mutable state, that cannot escape its scope) [1]
- IORef (mutable, thread-safe variables that only work in IO). [2]
The other (and usually more common way) of doing "mutable" state in Haskell is through State, which technically doesn't update the variable in-place, but simply modifies the variable and passes a copy to the rest of the computation (although, as far as I'm aware, a lot of the time this step gets optimized away).
That said, if your main field of expertise is simulation programs where performance and space efficiency are very important, then Haskell is probably not a great fit (cause not only is it based on a GC, it's also lazy, which can sometimes mess with the performance of your code, not speed-wise but memory usage-wise). Hopefully this could be mitigated in some way in the coming years when Linear types become viable for efficient resource usage (Linear types ideally could grant us some sort of Rust-like resource management)
[1] https://hackage.haskell.org/package/base-4.14.0.0/docs/Contr...
[2] https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-...
The very immutability of Haskell values means one has to use transactional logic - given current situation, compute situation at next step. C++ and many other languages tend to update values in-place and that brought me a lot of bugs to debug and, subsequently, made me use Haskell.
Laziness plays a critical role in free composition of parts of the system.
Let me present you some examples.
Single clock domain computing hardware can be thought as computations that compute values for every raising edge of a clock. It can be described as a function from infinite list of inputs to infinite list of outputs. The adder, for example, is just like this:
adder :: Num a => [a] -> [a] -> [a]
adder = zipWith (+)
register :: a -> [a] -> [a]
register = (:)
mealy :: ((input, state) -> (output, state)) -> state -> [input] -> [output]
mealy f resetState inputs = outputs
where
-- here comes shortcircuiting that relies on laziness:
outputsAndStates = map f (zip inputs (register resetState states))
outputs = map fst outputsAndStates
states = map snd outputsAndStates
Using regular map and other list functions and these two additions, one can simulate single clock domain hardware which amounts to almost anything that computes on silicon - within bounds of approximation; basically, one need to add delays for slower hardware somehow.
The trick with shortcircuiting above allows one to freely compose hardware simulation from different parts. You just put blocks there and they start to work. The function in Mealy machine is pure and total and can be tested (or verified) thoroughly in standard simple way.
https://stackoverflow.com/questions/57489844/how-does-readio...
IORef does not allow a value to mutate, it allows a pointer to a value to mutate.
Am I correct?
Does the ST Monad work in the same way? or does it truly allow values to be updated in place?
To address your more specific question, yes, Haskell can mutate data in place. See, for example, https://hackage.haskell.org/package/vector-0.12.0.1/docs/Dat.... On the other hand, unless you've got another compelling reason to use Haskell one wouldn't tend to say that Haskell stands out as a language to implement that kind of thing in.
[EDIT: Having looked at your history of commenting about Haskell on Reddit I'm not surprised that people took offence.]
I start discussions by disagreement though. If that is deemed offensive, what can I say.
Same here. It's simply not worth switching. And also Haskell is probably not going to provide much more productivity in lots of areas.
1) that's amazing, some of us aren't smart enough to do it without functional programming
2) I bet you could write 2-3x as much functional code and maintain the correctness. Reason being understanding doesn't require keeping track of mutable states in your head.
* marketing failure
* lazy by default
* GHC extensions
* its weird syntax
* its obsession with monad-as-burrito tutorials
* pretty hostile haskell-centric spaces
* not backed by a large company
* bad university classes
* tooling
* average developers are not “smart” enough to learn it
* no payback for learning Haskell skills
I'm not really sure whether it was because of the way it was taught or whether Haskell is inherently more difficult. I do think that a class like that might've hurt the language's adoption among the students though. (Or maybe my impression is simply biased by my own experience.)
I wanted to learn a functional programming language and did a lot of research about which language to start with. Initially I looked at Haskell but ended up going with F# because the tooling was a lot better and the documentation from Microsoft was really good. Also, I read quite a few posts by those who worked fulltime, paid F# jobs. I loved the functional style. I think it's a shame that it's not mainstream. But then when I tried to do something non trivial, like network programming, I had to use OOP C# style types in F#. That was just fugly and made the paradigm look weak because OOP constructs could do it more easily than functional constructs.
Other than the elegance of the functional programming paradigm, it didn't seem to offer much in terms of jobs because I can't really see large numbers of people suddenly picking up functional programming (which isn't easy) and building massive applications specially with the whole cloud based SaaS stuff that's happening right now.
If Haskell was indeed one of those "everybody wants to do it" languages, then making it easy to approach from the infrastructure perspective would be the first thing to do.
Having developed Haskell skills, what can one then do with them? Who in the world wants to have any Haskell code written badly enough to offer to pay to have it done?
If Rust dies, it will die just exactly the way almost every language did: its adoption rate was two or more orders of magnitude too slow, and the world moved on.
This is not inevitable: there are many other ways languages have died. Ada had a formal spec, billions of dollars in development contracts backing it, many industrial-grade compilers, thousands employed coding in it. It died because, ultimately, it wasn't enough better than C.
PL/I died. Algol died. All the various Pascals died. Ruby is in sharp decline. Death is the natural course for languages. Overcoming death requires a near-miracle.
COBOL, Fortran, C, C++, Python, Java, and Javascript managed it. It is too early to tell about Go or Rust, but it is not looking good for Rust, just based on the numbers. Rust's originators hoped to displace C, but very few move from C. Most who might have moved on from C did before there was a Rust, and the rest like it for its flaws, the way rock climbers like cliffs.
Rust will take few from C++ because Rust is less expressive, by design. The gap widens with each Standard release.
The languages Rust can practically steal users from do not suffer from the memory-safety problems Rust is promoted as solving. They have other problems it could help with. Go and Java are pathologically weak languages, and Python is pathologically slow and un-parallel.
There are things Rust adherents could do to increase its adoption rate, but they seem, by all indications, supremely and aggressively uninterested in even trying any of them. HN buzz, which Rust fans have run up to stratospheric heights, is very far from enough to sustain a language. So, Rust's prospects are dimming even as its apparent popularity peaks.
Examples being Swift, Ada/Spark, C++ lifetime analyzers, Chapel, ParaSail.
Then there are the Haskell, OCaml, Pony, Verona, Nim, D, Nim efforts on how to combine the best of both worlds GC (in whatever form) + affine types when needed.
But taking the world by storm and actually replacing C++ across Fortune 500's, specially given the contribution of many of them to ISO C++ and industry certifications, I see that as a multiple decades effort and even, as we can see from C++'s failure to take over C in certain domains, it is going to be a very steep uphill battle.
So in the end, we might just happen to get the usual mainstream languages with improved capabilities for managing resources, just like Haskell happened to bring LINQ to .NET world, followed by influencing Java streams and C++ ranges.
Are there any languages you can immediately answer these questions for? Are there any popular languages you can't answer these questions for?
I have some ideas, but I want to nail things down a bit more before attempting an answer if you don't mind.
That's not bad for a language that has "barely" hit 1.0 five or so years ago (next to C's 40-something years).
literally none of these is related to intelligence.
And even if they did, to assert that not wanting to learn Haskell has anything to do with "drive, intellectual curiosity and desire for a challenge" is ridiculous. There are a million reasons a person that exhibits all three of those qualities could opt not to.
GP didn't mention the word "intelligence"
Saying it is very inconsiderate of the efforts of everyone writing real world Haskell software.
Facebook uses Haskell, Github uses Haskell, etc... the metaphor doesn't hold and means this is just FUD.
On top of that, you're actually talking to a working professional Haskell programmer whose company depends on it.
Reading a book on abstract algebra is going to give you more concepts of Type Theory than learning Haskell.
So you may say that learning Haskell is intellectually useful, yet there are more challenging purely theoretic concepts which are more useful than Haskell.
I would go as far as saying that learning Haskell is just a "<smarts> poor man's excuse for not challenging themselves enough in the areas that actually matter".
What aspects of a book in abstract algebra introduce you to concepts of type theory, would you say?
Rust code uses "unsafe" and doesn't apologize about not being pure. Rust tries to minimize "unsafe" and encapsulate it, but acknowledges that it must exist.
What's the Rust equivalent of "A monad is just a monoid in the category of endofunctors, what's the problem?" I can't really think of one.
Maybe there's something in lifetimes (which can be pretty messy). Maybe: "Quit using doubly linked lists or the borrow checker will beat you senseless."
In addition, there are lots of alternatives to Haskell that are almost as good. That isn't true of Rust. If you need systems programming, you have C, C++, maybe Ada. Rust is trying to drive a fairly difficult wedge into that area, but if it succeeds, the alternatives are scarce.
When I read "A monad is just a monoid in the category of endofunctors, what's the problem?" I feel that someone thinks they are being clever by being confusing and unhelpful.
But when I read "Quit using doubly linked lists or the borrow checker will beat you senseless." I feel like someones trying to be helpful.
Rust? Well, talk about hip and groovy blah blah. About as great as C++. Full of complicated features, all pretty much focused on nitpicking, not expressivity. Could become hipster stuff for small projects. Enterprise? It's missing the point. There's no Machine Learning, no UI tools, no communications abstraction, no nothing. Just storage allocation without garbage collection.
Haskell will remain solid, but used by its aficionados. Rust will die as a niche language, and C/C++, sadly, will continue to dominate the low level coding, for better or for worse. Python and JavaScript will fill the UI centric space of Enterprise, with Python largely owning data centric stuff, and JS owning phone/tablet UX.
I was taught “monads” as: “ok, you wanted mutability? Here is how we program imperatively in Haskell”. Whole thing just hung together.
In terms of purely technical ability to catch certain set of bugs at compile-time, Rust as a language is one-two generations behind ATS, that supports refinement types and theorem proving, whilst staying on the industrial side of the "(industrial) C <-> (academic) Coq" spectrum.
hackage.haskell.org/package/base-4.14.0.0/docs/System-IO-Unsafe.html
Can you tho?
CppCon 2019: “Lifetime analysis for everyone”
Ocaml is designed to get stuff done, and the tooling and ecosystem strongly reflect that.
If something was going to kill Haskell, it would OCaml, not Javascript or some other language.
I would feel very comfortable running a business on OCaml, Haskell, not so much.
As a counter-point I'd say the opposite: I choose Haskell :)
> OCaml is ruthlessly practical and the culture around it is was one eminent pragmatism.
Is this a plus? Practical and pragmatism seem to be unlaterally considered a positive, but when does "pragmatism" just start to mean "unprincipled"? There's much talk about when being too principled gets in the way of getting things done, but I'm wondering what your position on the opposite is here.
What are your thoughts on 1) Real-world thinking 2) first-principles thining and 3) the balance of each that is ideal in software-engineering?
> Ocaml is designed to get stuff done, and the tooling and ecosystem strongly reflect that.
Haskell was designed to get stuff done too, just maybe not quite the same way. If you ever had an inkling of "maybe people in industry are outright dismissing research too fast" you might like it.
>> If something was going to kill Haskell, it would OCaml, not Javascript or some other language.
> I would feel very comfortable running a business on OCaml, Haskell, not so much.
I'd feel comfortable with either. I agree it'd have to be something at least as strongly typed as Ocaml to kill Haskell as well.
But, all in all, I like OCaml more than Haskell. Laziness by default is a mistake and GHC's ever growing list of language variants is kind of stupid. Moreover, Haskell's monad based effect system is a lot less useful than people think it is. In my mind, the main benefit of tracking effects is to enable aggressive compiler optimization, not increased safety.
Haskell's effect system imposes a heavy burden on the developer, with little benefit.
Ocaml imposes almost no burden in doing whatever the hell you want, but the language is messy and full of decades of hacks and eye sores.
I'm one of the rare souls that actually likes OCaml's OO system and I actually think that the language would be a lot better if the standard library and other code leveraged it. As it stands, functors aren't expressive enough for many use cases and function as shitty classes.
Here's what I want from a functional language:
Something that looks like OCaml, but get rid of the functors, cleans up the syntax, supports HKT, supports function polymorphism, supports easy to write macros (ppx is so fucking shitty), and make it have Nim like OO call syntax. Every function that takes a type as it's first argument can be called as a method using the dot syntax.
Also, have the language compile to a native executable, and make the executable and runtime really really small. OCaml gets a lot about performance right, but the 20mb executables (no tree shaking) is unacceptable.
Also, in case Ocaml turns out to be a better fit for any future projects I have a question:
What is the biggest advantage constituted in part or primarily from it's ruthless pragmatism?
Also the tool chain is miles better than Haskell. I'd even say that the build/package management and editor tooling is some of the best of any language.