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

81–90 of 188 posts

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

#81

Post by willtim »

xyzzy4 wrote: 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.

The complexity of many Haskell collection APIs is actually documented unlike with many other languages. These complexities are not changed by the runtime. Only constant factors and memory use are affected by optimisations and this is no different to any other high-level language that actually optimises code.

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

#82

Post by Lev1a »

scriptkiddy wrote: post #67
Lev1a wrote: post #48

Earlier quoted context omitted.

Could you give an example of what "system libraries" would pose a problem in my example of using Rust with cargo? Also note that by "no runtime installed" I mean no runtime as in "no Python runtime", "no JVM" etc. not necessarily "no libc" EDIT: formatting

>Could you give an example of what "system libraries" would pose a problem in my example of using Rust with cargo? Specifically things like xorg libs, libmpeg, libsdl, and such. Not that Rust would have a problem interfacing with them, just that they would need to be present regardless of whether or not someone was just trying to run a distributed binary. Agreed that you wouldn't need a VM like CPython or the JVM. Ho…

> Specifically things like xorg libs, libmpeg, libsdl, and such. Not that Rust would have a problem interfacing with them, just that they would need to be present regardless of whether or not someone was just trying to run a distributed binary.

That's why stuff like that is AFAIK usually either distributed with the binary or is absolutely required to have present on the system, regardless of the PL, if you want to/can only distribute a "naked" binary.

> Agreed that you wouldn't need a VM like CPython or the JVM. However, Rust isn't unique in that department. Almost all languages that compile to binary executables have this advantage.

Didn't mean to suggest this is unique to Rust, which is why I wrote

> because Rust is a compiled language.

EDIT: formatting

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

#83

Post by [deleted] »

willtim wrote: post #81
xyzzy4 wrote: 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.

The complexity of many Haskell collection APIs is actually documented unlike with many other languages. These complexities are not changed by the runtime. Only constant factors and memory use are affected by optimisations and this is no different to any other high-level language that actually optimises code.

[deleted]

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

#84

Post by paulryanrogers »

kbenson wrote: post #46
z3t4 wrote: post #29

Earlier quoted context omitted.

Articles like: We switched from language X to language Y with the conclusion that language Y is better smile My favorite is when they make another post half a year later saying they changed from Y to Z. It seems that following the trend and using the latest and greatest tools doesn't necessary mean the new tools are better, but that you got to rewrite your applications from scratch, with much more knowledge about the…

> My favorite is when they make another post half a year later saying they changed from Y to Z. Sometimes I wonder if the real subtext is "we have such high turnover that almost nobody was around when the first system was designed. We rewrote it in a new language, and now we're all much happier because we all understand it much better, having been involved in its design." Wait a year, repeat.

Being a hold over employee through 4 rewrites I'd say that can be one factor. Another is that the business landscape changes too. So all these factors combined make it difficult to say for certain which of them had an objective impact.

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

#85

Post by jacquesm »

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…

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 gate.

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

#86

Post by platz »

arianvanp wrote: post #77
chowells wrote: post #68

Earlier quoted context omitted.

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

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

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

#87

Post by chowells »

arianvanp wrote: post #77
chowells wrote: post #68

Earlier quoted context omitted.

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

There's a reason I said foldr. In Haskell, even foldl is implemented with foldr. It's that powerful of a tool. In contrast, foldl is far weaker, and necessarily strict in its input. It loses nothing moving to mandatory strictness. But foldr loses everything.

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

#88

Post by dllthomas »

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…

That sounds about right.

At the shallowest level, we can't pass `m ()` to forkIO unless m ~ IO, 'cause the types don't match.

But beyond that, there is the question of how that extra context would be passed through. For something like ReaderT this is straightforward. But consider StateT - `set` in one thread can't be visible in the other.

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

#89

Post by snowcrshd »

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.

> I can't imagine using a haskell-like language without laziness. It's what makes it possible to actually write small reusable functions.

I don't understand your point. Why is laziness a requirement to write small reusable functions? Are you thinking about currying?

OCaml is (relatively) similar to Haskell and is not lazy. Function currying does not require laziness.

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

#90

Post by darksaints »

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…

There are many calls for, and proposals to include, some form of inheritance in Rust. Among other things, people have found that Rust is poorly suited to modeling HTML/XML hierarchies, retained mode GUIs, industrial simulations, code specialization, and some forms of video games. Inheritance is a missed feature.

What is clear to me is that Rust does incredibly well without it, but wouldn't be hurt by having it. Most of the egregious sins of OOP are mitigated by having far better abstractions available in Rust. ML-style modules, ADTs with pattern matching, type classes, first class functions, etc. Much like scala, if you give them capable FP, OOP stops being abused and starts being used appropriately.

Post reply on HN