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

71–80 of 188 posts

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

#71

Post by hueving »

mightybyte wrote: post #31
Eridrus wrote: post #27

Earlier quoted context omitted.

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…

Doing a rewrite in a different language and justifying language choice by a successful outcome of the rewrite is grasping at straws to justify the language change.

Every time I've been involved in a rewrite, including ones using the same language before/after, the outcome has been good. The act of doing a full rewrite is where the benefit comes from, it's hard to separate that from a language switch.

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

#72

Post by dllthomas »

arianvanp wrote: post #23
baldfat wrote: post #18

Earlier quoted context omitted.

Cabal made me never use Haskell every again. I work in two different locations and at home. All three locations never worked the same and all had different issues with Cabal. After hours and hours of trying different things I walked away into the wonderland of Racket.

They're working really hard on improving it though . Cabal 2.0 will have a nix-style build system, in which multiple verions of the same dependency can be installed globally (so no separate sandbox per project). This will solve most problems of where cabal breaks down. This gives us almost the same usefulness as Stack. However, you will have to make sure that there is actually a feasible build plan, by setting up you…

> relaxing but also gives you less control

More like "leads you to typically exercise less control". You can override versions of packages in a stack snapshot.

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

#73

Post by xyzzy4 »

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.

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

#74

Post by cpeterso »

kabdib wrote: post #49
mybrid wrote: 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…

Given the awfulness of so many OOP-based frameworks that I encountered in the 90s, I began to seriously consider that OOP wasn't a better paradigm for most things and that instead it was worse , and simply caused people to rewrite code to the point that it overcame the procrustean bed of inheritance and whatever other tools the language of choice was providing.

It is interesting that Go and Rust eschewed OOP inheritance for simple encapsulation. Information hiding, not implementation inheritance, turned out to be the big practical benefit of OOP. Inheritance leads to fragile code because it allows unseen dependencies on private implementation details in far-flung classes and files.

Many C++ game engines also moved away from huge class hierarchies of game objects to property-based game objects that were collections of behavior handlers.

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

#75

Post by moron4hire »

mightybyte wrote: post #25
mybrid wrote: 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…

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

#76

Post by chowells »

contravariant wrote: post #35

> 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 kn…

It's not about side effects, it's about bookkeeping. When you have a type that indicates that you can do IO, but you're also carrying around bookkeeping data implicitly for things like configurations and data sources, forkIO represents a hard problem.

If the implicit configuration is updated, there's no way to communicate that across threads. The same is true with all the other things monadic layering can provide. How do you call a continuation that points to a different thread? That doesn't even make sense.

So.. Why lie in your type and pretend that those things all make sense? Why not make the type explicit about what makes sense and what doesn't? That way, when someone wants to do something that has no a priori way of making sense, they're required to define how to handle it, such that it makes sense in their specific use case. And that's what the post says they did.

All in all, it's things working as designed. Places where you need to stop and think are set up such that you need to stop and think to use them, instead of barging ahead unaware of the issues.

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

#77

Post by arianvanp »

chowells wrote: post #68
daxfohl wrote: 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 can't imagine using a haskell-like language without laziness. It's what makes it possible to actually write small reusable functions. Tell me, have you ever used foldr in Purescript? It just doesn't lead to reusable logic there, so I have no idea why you would. But in Haskell, foldr is used everywhere. Laziness means that logic built with it is actually reusable.

Folds are used in purescript all the time! Sure a foldr is less useful because it doesn't have the nice lazy preserving properties, but you can have strict left folds, which are tail recursive, and thus run in constant space.

Elm, another haskell-like, _strict_ language, models entire applications around the strict left fold over events https://guide.elm-lang.org/architecture/

We actually do the same in Jobmachine. The application is driven by a strict left fold over incoming events and current state.

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

#78

Post by tombone12 »

dwc wrote: post #24
mybrid wrote: 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…

There's a lot of truth in that. A few days ago I wrote a comment about rewriting a program from C++ to C and coming in at about 1/4th the code size. However, I didn't mention C or C++ in that comment because the real savings came from reevaluating requirements, lessons learned, refactoring, et al. Some time back, someone here on HN posted a comment about rewriting a Java app in... Java. Same basic story of large savi…

I don't know how I came across it, but Thomson's Rule for First-Time Telescope Makers seems relevant here:

: "It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror."

http://wiki.c2.com/?TelescopeRule

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

#79

Post by colorint »

curtis wrote: post #59
kabdib wrote: post #49

Earlier quoted context omitted.

Given the awfulness of so many OOP-based frameworks that I encountered in the 90s, I began to seriously consider that OOP wasn't a better paradigm for most things and that instead it was worse , and simply caused people to rewrite code to the point that it overcame the procrustean bed of inheritance and whatever other tools the language of choice was providing.

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, but I suspect requiring ANY categorical theory about your problem is going to create mischief in the long run.

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

#80

Post by TinyBig »

arianvanp wrote: post #20

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

"Our lead developer Robert usually comes in a bit later, so we had about an hour to build a working prototype" - why did you only have an hour? What would have happened if the working prototype was not done when he came in?
Post reply on HN