There are various mature options for scheduling jobs with dependencies between them. Why did you choose to write your own, regardless of the language?
How we secretly introduced Haskell and got away with it
151–160 of 188 posts
Re: How we secretly introduced Haskell and got away with it
#152I'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…
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
#153I'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.
Re: How we secretly introduced Haskell and got away with it
#154Earlier 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…
Re: How we secretly introduced Haskell and got away with it
#155I'm the author of the post. I'll be happy to answer any of your questions :)
Re: How we secretly introduced Haskell and got away with it
#156In 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…
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
#157Earlier 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.
Re: How we secretly introduced Haskell and got away with it
#158Haskell 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…
Re: How we secretly introduced Haskell and got away with it
#159Earlier 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.
Re: How we secretly introduced Haskell and got away with it
#160I'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-...