Apart from being a great language, Haskell also has a great community. I recommend learning the lang and interacting with the people (irc, #haskell on freenode for example). :)
Why GitHub used Haskell for Semantic
161–170 of 214 posts
Re: Why GitHub used Haskell for Semantic
#162I'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…
If you'll forgive the analogy, Haskell is kind of like the Mercedes of production-ready research-grade languages. You may not actually use haskell, but the features that haskell is pioneering are what you'll see trickling down into other languages, as language designers look over and borrow things. Some examples (though they're not all invented by haskell, but haskell has popularized them IMO): - non-nullable types -…
I once saw (here on HN) Haskell described as “primordial soup of type theory, from which other languages draw their good ideas from”.
Re: Why GitHub used Haskell for Semantic
#163Earlier quoted context omitted.
Using C# as an example, foreach and IEnumerable are baked into the language as is try/catch and more recently Async/Await. These are all just library functions in Haskell and often more general (e.g. forM in Haskell works for any Monad not just IO). Because they are library functions they can be changed/customized very easily. In C#, how could foreach be made to support a different stream type, exceptions be made che…
C# has LINQ. Implement Select and SelectMany extension methods for whatever you like, and you can use the LINQ syntax with your type just as easily as with IEnumerable. Foreach and async/await are baked in, that's true, but the LINQ syntax is easily extendable to new use cases.
I wonder why this is?
https://www.infoq.com/interviews/erik-meijer-linq/
(from "3. How does LINQ work?")
What we have done, and what the mathematicians call Monads, we have identified these sets of operations, we call them standard query operators; we have a list of about 25 standard operators that you can apply to any data model.
Re: Why GitHub used Haskell for Semantic
#164Earlier quoted context omitted.
This is a discussion of the phrase "such a feature would be entirely impossible" You're now explaining to me in response to my previous post that some languages are a better fit in certain dimensions to perform a data transform? I think this is a discussion that needs to end now.
I'd been addressing the snarky finishing line. The feature that was called "entirely impossible" was resumable exceptions . The difficulties are practical not theoretical, but it's not the difference between (r, err) and (Either r err).
Needed to stop but didn't for which clearly it is all my fault because someone is wrong on the internet!! Being snarky about features being only possible in $language is one of the few entirely appropriate uses of snark and you don't object to snark per se, do you?
Which feature of this discussed data transform is called "template meta-programming?" Excuse me, my bad, is called "resumable exceptions?" Or are resumable exceptions a language feature/idiom used with a particular choice of language to perform a data transform? Really. "The feature of using C++ is impossible with a different language selection." Come. On. It must rankle. It must.
Maybe this isn't just yet another "any criticism of a language boosterism piece must be met with fire and fury because I've invested time and want career payoff." Yeah maybe there's something else going on here but I genuinely can't see it. And it's a pattern also visible with rust boosterism articles (and I like rust too!) and clojure (again, it has some merit!) and even Haskell. Yeah, Haskell is fun! (No! Silence the Heretic. The emperor's threads are fine indeed! "Let me repeat what you just said but with me explaining it to you to show how stupid you really are." Yeah well I know I'm pretty stupid, often, but not so stupid as all that, yeah?)
Re: Why GitHub used Haskell for Semantic
#165Earlier quoted context omitted.
How far can you go without monads and category theory? I was looking at Clean which developed in parallel with Haskell and uses uniqueness typing instead of IO/mutation monads. Seems like it would be less offputting for a newcomer. Clean lacks community and a package manager, I believe which makes it less attractive. The language itself seems like a sweet spot for me.
Not used Clean, but it sounds interesting. What i'd love is an imperative language where you declare what effects a method can have and the compiler enforces them. E.g. if it promises not to mutate any parameters, it can only call functions that make the same promise etc.
Idris isn't imperative (Haskell-like with dependent types), but offers features like those:
http://docs.idris-lang.org/en/latest/effects/depeff.html
readInt : Eff Bool [STATE (Vect n Int), STDIO]
[STATE (Vect (S n) Int), STDIO]
logout : (store : Var) -> ST m () [store ::: Store LoggedIn :-> Store LoggedOut]
- https://github.com/idris-lang/Idris-dev/blob/master/libs/con...
- https://github.com/idris-lang/Idris-dev/blob/master/libs/eff...
I think it'd be possible to write similar effect systems in other dependently typed languages like ATS, which is a relatively imperative language (C+ML-like).
Re: Why GitHub used Haskell for Semantic
#166Earlier quoted context omitted.
I think it's hard to do just side-by-side comparison. Just imagine you just go back to 90s and convince C++ fans using Java. They are all general purpose programming languages, just with some better/different design decisions to make things safer or relatively more/less expressive. Similarly, the difficulty to explain Monad is Monad itself is pretty abstract and general. You can describe what it is, but it's hard to…
The "Monad" typeclass in Haskell is a unification of a bunch of things that are treated separately in other programming languages. By "unification" I mean the same kind of thing that physicists mean when they say that Maxwell unified light and electrical phenomena, or that Newton unified physics and astronomy. It is this unification that makes monads so powerful; one abstraction handles sequencing, exceptions, non-de…
i like to explain monads as the same sort of thinking process as a 'design pattern' in OOP. People who have done OOP would have heard of things like the visitor pattern. In OOP, patterns aren't unified in some class, but could be.
Monads (and type classes in general) are like design patterns in OOP, in that they encode a common use case. Except in haskall, you can encode this pattern into the language semantics.
Re: Why GitHub used Haskell for Semantic
#167> An example of this is the concept of resumable exceptions. During Semantic's interpretation passes, invalid code (unbound variables, type errors, infinite recursion) is recognized and handled based on the pass's calling context. ... Porting this to Java would require tremendous abuse of the try/catch/finally mechanism, as Java provides no way to separate control flow's policy and mechanism. And given Go's lack of e…
This is trivial to do in most languages (including Java and Go) if you just stop to think about it for a couple of minutes. Just pass some kind of context object down the call stack (or make it available as a global — make it thread-local if you need). Then when an error occurs, just call this handler and voilà!
This is, in fact, pretty much what Haskell does. Except this handler is in a typeclass instance, and this typeclass instance is passed down the call stack, it just doesn't appear in the parameter lists but in the type signatures. It's a bit lighter syntactically, but ultimately it's the same thing.
Re: Why GitHub used Haskell for Semantic
#168I don't like these posts (for any language, not only Haskell). Invariably they will list many points, most of which are subjective or tangential.
There are one or two core points (here I guess it is "Control Flow") that would benefit going into much deeper. I think, you'll find these points aren't as solid as they appear (cf. other threads in the comments).
Using Haskell is fine. You don't have to justify it. It's enough to like it, being comfortable and productive with it.
Own your gut. Don't make pseudo-truth argument lists to justify your decisions.
Re: Why GitHub used Haskell for Semantic
#169Earlier quoted context omitted.
I'd been addressing the snarky finishing line. The feature that was called "entirely impossible" was resumable exceptions . The difficulties are practical not theoretical, but it's not the difference between (r, err) and (Either r err).
Needed to stop but didn't for which clearly it is all my fault because someone is wrong on the internet!! Being snarky about features being only possible in $language is one of the few entirely appropriate uses of snark and you don't object to snark per se, do you? Which feature of this discussed data transform is called "template meta-programming?" Excuse me, my bad, is called "resumable exceptions?" Or are resumabl…
As far as I can tell, no one said resumable exeptions are only possible in Haskell. That would be pretty silly, as they didn't even originate there. In fact, they indicated it probably would be possible-but-awkward in Java. What was stated was that it wasn't possible in Go, and that seems to be correct, and have nothing to do with Haskell's choice to return (Either a b) where it's appropriate instead of (a, b).
It's certainly the case that whatever you wanted to use resumable exceptions for is very probably plenty possible in Go. But no one denied that. It's also possible to implement a language that's like Go but has resumable exceptions, either in Go or by modifying the Go compiler, but not only is that a huge project (which may permit "entirely impossible" as hyperbole) but the result is quite arguably not even Go anymore.
Re: Why GitHub used Haskell for Semantic
#170I don't like these posts (for any language, not only Haskell). Invariably they will list many points, most of which are subjective or tangential. There are one or two core points (here I guess it is "Control Flow") that would benefit going into much deeper. I think, you'll find these points aren't as solid as they appear (cf. other threads in the comments). Using Haskell is fine. You don't have to justify it. It's en…
I agree with you. It's sufficient to like using a tool and be productive with the tool to justify using it.
But sometimes, solid engineers who are productive with certain tools are working at the behest of unenlightened managers. Articles that say "BigCo uses X for Y because of Scientifically Sounding Reasons" help those engineers use the tools they like and are productive in.