Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we secretly introduced Haskell and got away with it

tech.channable.com

Post reply on HN
Print view View original

31–40 of 188 posts

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

#31

Post by mightybyte »

Eridrus wrote: post #27
mightybyte wrote: post #25

Earlier quoted context omitted.

That's all well and good except for the fact that your standards are impossible to reach. Even if I do write the exact same project with two different languages, there will always be differences in either the skill of the teams or, if the teams are the same, the amount of experience the team has when they tackle the project. What we can do is compare similar types of projects in different languages. And the things we…

It seems pretty easy to control for this, just write the functional version first, and if it is as big free your results obviously sidestep this criticism.

Not really. Even then you'll get criticism that the teams were more skilled in one language, or that they didn't use the best practices of the other language. Also, even if you could manage to normalize for all these variables. You're still only going to be comparing the cost to create the project. You're never going to get someone to maintain the two projects side-by-side for years and compare the total maintenance costs. That is where the biggest benefit of languages like Haskell comes.

The fact of the matter is there never will be absolute proof of these questions. The naysayers will always have straws to grasp at.

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

#32

Post by vkou »

chongli wrote: post #12
sid-kap wrote: 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.

Maturity comes from:

* Millions of person-hours being poured into a language...

* ...Over a long enough time period that the language can go through several develop-eval-improve cycles - that take real world use cases (And not one-liner bubble sort implementations) into account.

In this sense, it doesn't matter whether or not Haskell was invented in 1890, or 1990. #2 is required for maturity, but so is #1.

(I am not a huge Python fan.)

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

#33

Post by scriptkiddy »

Lev1a wrote: post #4
sid-kap wrote: 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).

The whole "Do you have the dependencies and a Python env installed? Noß Then you can't run this script/program." was one of the main reasons I switched from Python to Rust, where cargo as the (very good) package manager comes with the language and, because Rust is a compiled language, you build all the dependencies into your executable you aren't dependent(heh.) on the user having installed a runtime that maybe or ma…

I guess this is true if you don't need to interact with any system libraries.

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

#34

Post by chrisdone »

sid-kap wrote: 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).

Stack requires package sets (aka "snapshots"), which some kind of CI system (Stackage: http://stackage.org/) has to do a daily build job to see if they all build and pass tests together. That requires some money to keep running, and buy-in from package authors as there is a maintenance overhead each release. It took a few years for Stackage to get enough packages in it to be generally useful, and then we wrote the Stack tool which was able to default to using Stackage snapshots.

There was (and still is a little bit) of resistance to the whole idea of Stackage from the community; people liked the idea of build plans magically being figured out on demand, it's an interesting research problem (it can be hard to let go of an interesting problem when a solution side-steps it all together). I believe eventually many people changed their minds after experiencing the simplicity of using Stack and not having build hell be a substantial part of their development cycle.

Python would likely have to go through the same process. Although with Stack and Yarn providing frozen builds (and QuickLisp); the idea has some precedence, which makes it an easier idea to sell. I mean, Debian and a bunch of other OSes do it like this, but experience shows programmers don't pay attention to that.

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

#35

Post by contravariant »

> The issue here is that we cannot run runWorkerLoop and runFetchLoop with forkIO, because we don’t have the right transformer stack.

Am I understanding correctly that this is because, while you can lift e.g. runFetchLoop to something of type IO m (), it's not possible to convert use forkIO on it since it requires an input of type IO ()? Isn't that just a consequence of the fact that Haskell has no possible way of knowing if your side effects can be contained in the IO monad?

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

#37

Post by KurtMueller »

rkrzr wrote: post #19
eternalban wrote: post #15

> Our lead developer Robert usually comes in a bit later, so we had about an hour to build a working prototype. I'm guessing he is a Python developer and likely he is no longer the lead.

Don't worry, I'm still here.

Yes, but are you still the lead? :)

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

#38

Post by daxfohl »

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 PureScript integrates with JS libraries and seems "fast enough" in many cases. I think it's more interesting as a project too: the lack of runtime and laziness means the compiler code is orders of magnitude simpler than Haskell's, so I could see a larger community building around it if it catches on.

Given that they were on Python earlier, I wonder if PureScript would have been a better choice.

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

#39

Post by yawaramin »

guptaneil wrote: post #3

It looks like jobmachine is a private repo, maybe don't include the url in your blog post :)

If the URL to a private repo is not secure, then a whole bunch of people (including GitHub) have a big problem, and exposing jobmachine is the least of their worries ;-)
Post reply on HN