Earlier quoted context omitted.
Why?
Because in its current form the subject and verb don't agree.
Only in American English. Groups are plural in British English. "The police are corrupt" vs "the police is corrupt".
Why GitHub used Haskell for Semantic
11–20 of 214 posts
Re: Why GitHub used Haskell for Semantic
#12I'm really curious why Haskell has seen so little adoption in industry. Is it just the difficulty? Or a chicken-and-egg effect with tooling and libraries? One thing I've wondered is if it actually isn't ideal for a lot of cases. FP is beautiful for certain things. But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space. For…
I havr never noticed immutable data structures to be more difficult to deal with. For the most part, because of monads and effects and such you can essentially write better imperative code in haskell. Im noy sure why youve decided that haskell is incapable of the syntactic appearance of mutation.
To be fair I haven't really used it, only read the core of the guide, so I may be mistaken.
But I've done a bit of Clojure, and I've done a bit of Immutable.js, and particularly when you have a deeply-structured piece of data, "mutating" something a few levels down gets really ugly. Now, maybe something about Haskell Enlightenment obviates this case entirely in a way I'm not seeing. But I also remember Haskell seemingly forcing you to push all your imperative code up to the surface layer of your otherwise pure program, which sounds great unless you need to do really meaningful things that are by nature imperative.
Re: Why GitHub used Haskell for Semantic
#13> given Go's lack of exceptions, such a feature would be entirely impossible. Haskell is a nice programming language, but ultimately if a program written in language A can run on your computer, a program can be written in language B that can run on your computer and do the same things. If you think "return foo, err" is a lot different than return "Left foo" or "Right err", then you might want to think more about how…
The point isn’t that the software couldn’t be written in Go; it’s that the language feature that makes that particular problem easier to deal with doesn’t exist.
You could write this tool in Go, but it would have an entirely different flow.
Re: Why GitHub used Haskell for Semantic
#14Earlier quoted context omitted.
Because in its current form the subject and verb don't agree.
Only in American English. Groups are plural in British English. "The police are corrupt" vs "the police is corrupt".
I have no idea if what you're saying is generally true, but I can say with certainty that no one would ever say "the police is corrupt" in American English.
Re: Why GitHub used Haskell for Semantic
#15Re: Why GitHub used Haskell for Semantic
#16Seems to be the same reason Facebook used it and one of the well-worn areas that Haskell has proven itself (language parsing/analysis).
The section about their day-to-day experience of programming serious software with Haskell compared to other languages is really interesting though.
Re: Why GitHub used Haskell for Semantic
#17Earlier quoted context omitted.
Only in American English. Groups are plural in British English. "The police are corrupt" vs "the police is corrupt".
I have no idea if what you're saying is generally true, but I can say with certainty that no one would ever say "the police is corrupt" in American English.
A better example might be a British soccer club, e.g. Chelsea are corrupt.
Re: Why GitHub used Haskell for Semantic
#18Earlier quoted context omitted.
I havr never noticed immutable data structures to be more difficult to deal with. For the most part, because of monads and effects and such you can essentially write better imperative code in haskell. Im noy sure why youve decided that haskell is incapable of the syntactic appearance of mutation.
To be fair I haven't really used it, only read the core of the guide, so I may be mistaken. But I've done a bit of Clojure, and I've done a bit of Immutable.js, and particularly when you have a deeply-structured piece of data, "mutating" something a few levels down gets really ugly. Now, maybe something about Haskell Enlightenment obviates this case entirely in a way I'm not seeing. But I also remember Haskell seemin…
"Now, maybe something about Haskell Enlightenment obviates this case entirely in a way I'm not seeing."
Many times the answer is that with a different structure you don't need deep mutation to be a critical part of your program. After all, "deep mutation" isn't considered a great idea in object-oriented languages either, where it constitutes a violation of the Law of Demeter [1], either in letter or in spirit (i.e., creating a chain of methods to set some deep value may in letter follow the Law but can still be a violation in principle).
But if you do need it, Haskell does have a rather nifty mechanism for mutation patterns to be first-class elements themselves through "lenses", which capture as a first-class value some access pattern and mutation pattern on a given value. And while one of its original purposes is to allow Haskell like
value %~ property1 ^. property2 =. newValue
You can even do really melty stuff like have a lens that will expand an int into its bits, allow you to manipulate those bits as if you had an array of bool, and then will re-pack them into the int for you. Lenses can take any arbitrary slice out of an object as long as you can express the extraction and the creation of a new object putting the stuff back, and then they can be composed together as-needed. It can be powerful, but it can get pretty brain-melty too.
Re: Why GitHub used Haskell for Semantic
#19I'm really curious why Haskell has seen so little adoption in industry. Is it just the difficulty? Or a chicken-and-egg effect with tooling and libraries? One thing I've wondered is if it actually isn't ideal for a lot of cases. FP is beautiful for certain things. But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space. For…
It's 100% the difficulty. Anyone saying otherwise is lying because they want Haskell to be popular, adopted it very early on in their career when they could really invest in it, or is a natural at this type of stuff and simply doesn't know any better.
I've learned about 10 different languages now and Haskell easily had the highest learning curve. Most languages I was able to get semi-usable in within a couple days, at least to do some minor stuff that works. But Haskell was a real commitment that took months until I was comfortable doing real stuff.
You have to learn about how to mutate data and how to manage state using monads and functors, how to query through complex objects using lenses, even getting it to parse some complex data coming from a JSON feed into a usable form requires a good understanding of the type system.
But ultimately besides when I first learned Clojure (my first exposure to FP), I don't think there's a language that has taught me as much about programming as Haskell. It was very rewarding and something I still continually dabble with and learn from on the side.
I've yet to pull the trigger and actually build a full side project with Haskell. Which is typically my biggest test. I've found Erlang/Elixir to be the far better middle ground from my day-to-day work in Ruby/JS when I want something modern, fast, and functional.
Once PureScript becomes stable I have a feeling I'll be diving harder into Haskell and may finally make that full commitment it requires for a real project.
Re: Why GitHub used Haskell for Semantic
#20I'm really curious why Haskell has seen so little adoption in industry. Is it just the difficulty? Or a chicken-and-egg effect with tooling and libraries? One thing I've wondered is if it actually isn't ideal for a lot of cases. FP is beautiful for certain things. But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space. For…
> The most successful languages let you be pure-functional where it makes sense and then stateful where it makes sense. Haskell doesn't, really (from my cursory reading about it).
This is absolutely wrong. Sorry to be so direct, but I want to make sure other people not familiar with Haskell don’t get the wrong impression.
Haskell is explicitly designed to separate purely functional and stateful code with a clear interface between them: monads. It does exactly what you are asking for.