Live data from Hacker News

How we secretly introduced Haskell and got away with it

tech.channable.com

101–110 of 188 posts

Re: How we secretly introduced Haskell and got away with it

#101

> No messing around with virtualenvs and requirement files. Everybody builds with the same dependency versions. No more “works on my machine” and “did you install the latest requirements?”. While this is nice, of course, I'm not sure that is outcome is unique to Haskell/Stack. It seems like you could accomplish a similar level of reproducibility by building a Docker image or bundling dependencies in some other way.

My understanding is that Docker only stays reproducible if after every change you kill the container and start a new one. Otherwise a particular change may only be working because of a side-effect of a change you introduced earlier and then deleted.

This isn't a huge issue, but still it's nice in declarative systems like Stack and NixOS not to have to worry about that kind of thing.

Re: How we secretly introduced Haskell and got away with it

#102

I'm the author of the post. I'll be happy to answer any of your questions :)

Not a question, but with regards to:

> * We use all of the five different string types. It is annoying, but it is not a major problem.

cs[1] and the OverloadedStrings extension is all you need, in my experience.

[1] https://www.stackage.org/haddock/lts-8.3/string-conversions-...

Re: How we secretly introduced Haskell and got away with it

#104
You can deploy Python code as a static binary that includes the interpreter along with all dependencies. I heavily use this in production and life is great - deployment means copying one single binary, reverting means running an older one instead. No external dependencies, no pip upgrades, just libc.

https://github.com/pyinstaller/pyinstaller

Re: How we secretly introduced Haskell and got away with it

#105
post #59

Earlier quoted context omitted.

My personal suspicion is that the problem there wasn't OOP, it was frameworks.

I think OOP will always run into the problem that it requires a taxonomical theory about your problem, which never holds up in reality. (This is just another way of saying, inheritance has to be a forest/bundle of disjoint trees. Yes, there's multiple inheritance, but I'm pretty sure acknowledging that is a mortal sin among OO types.) Haskell is slightly better, since typeclasses are less topologically constrained, b…

The problem is people not using abstract taxonomies.

If people keep trying to force code organization around the business jargon, they will keep getting the same awful result. It does not matter if they are writing OOP, Abstract Data Types, FP, or direct bits manipulation with assembly.

Re: How we secretly introduced Haskell and got away with it

#106
post #38

I'm just starting with Haskell and PureScript. So far I'm liking the latter better. It solves a few of their gripes with respect to strings, laziness and records, plus has a more granular/extendable effects system and cleans up the standard typeclass hierarchy. Also `head []` doesn't crash. Of course Haskell is more mature, has support for multithreading and STM, compiles to native, so it's more performant. But PureS…

> It solves a few of their gripes with respect to strings, laziness and records, plus has a more granular/extendable effects system and cleans up the standard typeclass hierarchy. Also `head []` doesn't crash.

Check out ClassyPrelude[1]. It's a (n opinionated) alternate Prelude that wraps many things up into much more "modern" interfaces. `head` has been replaced with `headMay` (which, as you can figure, returns a `Maybe a`). Most functions can now handle `Text` fairly seamlessly. For an application developer, it's fantastic.

[1]: https://hackage.haskell.org/package/classy-prelude

Re: How we secretly introduced Haskell and got away with it

#107
post #73

Haskell is a bad language, in my opinion, because you can't tell what the O(n) run-time is for any operation. Instead you just have to "trust" that it'll be fast enough. More on this: https://www.reddit.com/r/haskell/comments/1f48dc/what_does_t... All of the answers seem insufficient. Basically you can't estimate Haskell run-time unless you are very familiar with the internal Haskell engine.

Completely untrue. I'm not a Haskell evangelist (I appreciate it for what it is) but I thought I would at the very least point out that most of the documentation for basic data structures (i.e. Data.List[1]) not only are well-documented but have a link on the far-right side of the documentation site that directly shows you the source code and it's usually easy to tell what it's doing. Any developer should be able to grok that code and determine the run-time complexity.

[1] https://hackage.haskell.org/package/base-4.9.1.0/docs/Data-L...

Re: How we secretly introduced Haskell and got away with it

#108
post #73

Haskell is a bad language, in my opinion, because you can't tell what the O(n) run-time is for any operation. Instead you just have to "trust" that it'll be fast enough. More on this: https://www.reddit.com/r/haskell/comments/1f48dc/what_does_t... All of the answers seem insufficient. Basically you can't estimate Haskell run-time unless you are very familiar with the internal Haskell engine.

As a huge Haskell proponent: this is a totally legitimate question, sorry you're being downvoted.

Writing extremely performant Haskell is a very specialized skill. Happily, Haskell is still extremely fast even without fine optimizations.

It depends on what you want to do: if you're writing a moon lander and don't know anything about GHC internals you may be overreaching yourself=) But for most things like web apps etc. knowing the basics is enough.

Re: How we secretly introduced Haskell and got away with it

#109
post #6

In the 1990s I did research on the efficacy claims of object oriented programming versus procedural programming. This article bares a striking resemblance in the claims. Case study after case study showed that object oriented code had less bugs due to compilers catching bugs, etc. However, almost every study was similar to this report: it was a re-write from procedural to object-oriented. There exists strong evidence…

What about skill too? Assuming the same programmer(s) worked on the same projects, they would be more skilled when coming to do the second project. Experience.

Re: How we secretly introduced Haskell and got away with it

#110
post #12
post #2

The comparison between Stack and Python build tools is striking: > No messing around with virtualenvs and requirement files. Everybody builds with the same dependency versions. No more “works on my machine” and “did you install the latest requirements?”. I wonder why the Python ecosystem, which is much more mature, doesn't provide a build tool as delightful as Stack (which is less than 2 years old).

I wonder why the Python ecosystem, which is much more mature I hope I'm not being too pedantic but Python's ecosystem is much larger than Haskell's, it isn't really more mature . Haskell and Python are very similar in age as languages go.

I don't really know how to compare.

Python's ecosystem is certainly much more complete, and stable in the sense that radically new concepts don't appear every day.

Haskell's ecosystem is more reliable in the sense that this feature you are using will probably not disappear in a year, and libraries have less conflicts.

Post reply on HN