Live data from Hacker News

How we secretly introduced Haskell and got away with it

tech.channable.com

151–160 of 188 posts

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

#151

There are various mature options for scheduling jobs with dependencies between them. Why did you choose to write your own, regardless of the language?

Good question! None of the existing options that we investigated supported all of our requirements. In particular, all the arrows that can exist in the dependency graph are known ahead of time, but the nodes are not. This means that a job can depend on a job that does not exist yet. (A user can add extra feeds to download, and the merge job should wait for them, even if it had been submitted already.) Furthermore we have a few specific constraints such as “per project, only one of job type x or y may be running at the same time”.

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

#152
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…

I think PureScript should catch on. The runtime performance story is much more predictable than Haskell, it integrates trivially with the most valuable target platform: JS, it has small output, fixes the warts of Haskell and yet is still pure.

Aside from apps at work, I made some simple physics demos with it http://chrisdone.com/toys/ Perfomance seems good.

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

#153

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

Did you try PyPy? If so, how did it perform? If not, why not? PyPy adoption is at only 1% or so, and it'd be nice to see more PyPy usage.

The real issue with the Python scheduler was its algorithmic complexity. Using a faster implementation would have bought us a few extra months or maybe even year, but it would only have postponed the need for a real solution.

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

#154

Earlier quoted context omitted.

> I wonder if PureScript would have been a better choice. I have an aversion (based for a large part on prejudice) of things that involve Javascript and its ecosystem :) I hear many good things about Purescript’s effect system, but I haven’t studied it in detail. This is definitely one of the areas where there is room for improvement in Haskell. Regarding the type class hierarchy and head being partial, those weren’t…

You don't have to study its effect system in detail, there's not much to it. Instead of IO a you have Eff e a, where e is a record of effects, using PureScript's records support. The neat thing is that statements in the Eff monad tend to get compiled to x; y; z in the resulting JavaScript, which is great, you don't pay a performance penalty. Check out the source code in this demo: http://chrisdone.com/toys/elastic-co…

That was informative, thanks!

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

#156
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…

This is so true. I usually write things three times: the first time to get a feel for the space, the second to solve the problem at hand. This then gives me actual understanding and them I'm ready to really solve the problem, usually with a fraction of the memory requirements and one or more orders of speed gain and less code to boot. Very rarely do I hit anything near to an optimal solution the first time out of the…

Bingo.

1st iteration: 'does it' (barely) but kinda looks hacky 2cnd iteration: better. actually works. 3rd iteration: looks clean, concise, pro, something to be proud of!

3rd time is a charm in software.

It's unbelievable how much clearer and more concise the code is 3rd time around.

If you can ever actually get away with this on a project ... highly recommended.

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

#157

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…

> That's all well and good except for the fact that your standards are impossible to reach. Right, yes. Perhaps this entire exercise is a complete waste of time. Perhaps we should be investing in skilled people who understand their problem domain and then just trust them to do the best they can, rather than trying to find silver bullets inside programming languages.

If it was a complete waste of time, we might as well write our web apps in machine language. There's never been a side-by-side study comparing machine language to modern languages that meets the scientific bar put forth. So even though you can't definitively prove causation, the history of programming languages has demonstrated that multiple substantial advances have absolutely happened. There's no reason to think there can't be more.

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

#158
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 et…

[deleted]

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

#159

Earlier quoted context omitted.

This is so true. I usually write things three times: the first time to get a feel for the space, the second to solve the problem at hand. This then gives me actual understanding and them I'm ready to really solve the problem, usually with a fraction of the memory requirements and one or more orders of speed gain and less code to boot. Very rarely do I hit anything near to an optimal solution the first time out of the…

Bingo. 1st iteration: 'does it' (barely) but kinda looks hacky 2cnd iteration: better. actually works. 3rd iteration: looks clean, concise, pro, something to be proud of! 3rd time is a charm in software. It's unbelievable how much clearer and more concise the code is 3rd time around. If you can ever actually get away with this on a project ... highly recommended.

I would love to have the opportunity to do this is my working life projects as most of the time while I'm doing iteration1, I have various others breathing down my neck about getting the next list of tasks in the sprint done as well. Time, and keeping others away is my hurdle.

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

#160
post #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-...

I like the prototude prelude replacement for its lack of partial functions and toS function to do string conversions
Post reply on HN