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

131–140 of 188 posts

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

#131

Post by Ruud-v-A »

kisstheblade wrote: post #99

Always when I see haskell demonstrations eveyrthing looks like just interface declarations. You can do beautiful interfaces with eg. java also. But where is the meat where anything actually happens? I rarely see that in these posts. Yes I could look up the source but I don't have time to read through it randomly. This looks just so nice and stuff just magically works?: runWorkerLoop :: (MonadBackingStore m, MonadLogg…

The runWorkerLoop function logs a few lines and sends out an initial job request (by enqueueing an event in Redis). It then calls the nested function `go`, which dequeues one event of a TBQueue (a thread-safe bounded queue), matches on the event, and calls the right function to handle it. If the event was not a "stop" event, `go` calls itself to do the next iteration of the loop. `go` takes a WorkerState as argument, which is how it keeps track of which jobs are running, and whether there is an unanswered job request.

In reality the signature is a bit uglier, I simplified it for the post because the point was about effects. In particular we also pass in the configuration, Redis connection details, and a callback to manipulate the TBQueue.

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

#132

Post by twic »

cpeterso wrote: post #74
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.

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…

It's the same story in Java - inheritance used to be the first sledgehammer you reached for whenever you saw a nut, but these days it's barely used. Effective Java, the definitive text on the proper way to write Java, tells you to avoid inheritance [1], and that was published in 2008.

[1] https://books.google.co.uk/books?id=ka2VUBqHiWkC&lpg=PA81&ot...

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

#134

Post by goatlover »

colorint wrote: post #79
curtis wrote: 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…

But then you end up growing your taxonomy ad-hoc. Also, Python does multiple inheritance sanely, and so does Eiffel.

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

#135

Post by twic »

Ruud-v-A wrote: post #122
Lev1a wrote: post #4

Earlier quoted context omitted.

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…

Indeed, Rust + Cargo and Haskell + Stack are very similar in this regard. Both have great package managers, and both produce a shippable executable with only a few dependencies on system libraries. One notable difference is that Stack downloads the compiler, whereas for Rust, every version of the language comes with a compiler and a Cargo. This ensures that you can check out a year-old commit and still build your pro…

> for Rust the compiler version is not pinned

Oh, you just need another layer of abstraction! Install rustup, and then (from memory, might be slightly wrong):

  rustup install 1.15.1
  rustup run 1.15.1 cargo build
rustup will take care of getting hold of the right versions of cargo and rustc, and then use them to run the build. I admit that it's not as nice as having the build tool download the right version of everything, but it does work, and you could hide this inside a pretty small shell script or function if you wanted it to be neater.

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

#136

Post by chrisdone »

Ruud-v-A wrote: post #124
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 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-collision-balls/ There is still some overhead for currying, but there's a lot of room for decurrying saturated calls.

You might be happy to hear there is a PureScript native compiler. I'm also averse to JS things, I use PS but don't use the node-based tools to build it.

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

#137

Post by chrisdone »

platz wrote: post #86
arianvanp wrote: post #77

Earlier quoted context omitted.

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. T…

The hard thing to swallow with purescript is whether row types are really worth the complexity they add.

I think it's a much easier pill to swallow than laziness.

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

#138

Post by tigershark »

NegatioN wrote: post #21
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…

Wouldn't a complete rewrite of a module usually be a lot easier if the program is procedural? I think that is one of the big factors stopping that from actually happening with OO code. A rewrite is a lot harder if you tap into what exists elsewhere in the codebase. I bet you have a lot more insight into this than me though.

I don't really think so. With OOP you can easily replace whatever part of the system you want. Obviously if you have written OO code, not if you have written a mixed procedural-spaghetti code in an OO language. You "just" write an implementation for your interfaces that makes all the unit, integration and acceptance tests green. With procedural programming you have no interfaces and more importantly testing was non-existent. Seriously, I thought that in 2017 the advantages of OOP over procedural were obvious, I fell like that I have time-traveled to 15-20 years ago where it was still debatable.

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

#139

Post by astrobe_ »

sdflkd wrote: post #121
astrobe_ wrote: post #115

Earlier quoted context omitted.

I'm not a C evangelist, but I would point out that most documentation of standard C function is very detailed and its code is shown in its man page. Any developer should be able to grok that code and determine its safety. Mattaku...

They really should be able to.

You're completely missing the point: people are not computers. They make mistakes, including while they check things. That's why you don't want to rely on tests, but rather on formal proof.
Post reply on HN