81–90 of 190 posts
A decade ago a friend paid a local company to build him a many-core compute server. I was fairly certain they'd under-spec'd the power supply. My favorite stress test was to build 32 copies of GHC at once, daisy-chaining each new copy to build another. Keep it running.
His computer started billowing smoke.
Earlier quoted context omitted.
Stream API would be my first thought but I am not as familiar with Java. Maybe I should have said "ideas", I'm not sure there are any language level changes for Stream API.
> Stream API would be my first thought but I am not as familiar with Java. Can you name any design characteristics in Java's stream API that came from Haskell, rather than were already common in many languages when Haskell itself was designed? I can't.
> "The barrier to entry for GHC development remains impossibly high" Could not agree more. I've put in a couple merge requests to the ghc Haskell compiler, and it's very difficult to even figure out what's going on, nevermind make a meaningful contribution.
What is an easier compiler to get into? Interpreters do not count ;)
"Everyone should build GHC from source at least once...You will learn a lot about how the sausage gets made." A decade ago a friend paid a local company to build him a many-core compute server. I was fairly certain they'd under-spec'd the power supply. My favorite stress test was to build 32 copies of GHC at once, daisy-chaining each new copy to build another. Keep it running. His computer started billowing smoke.
I tried twice to get started with Haskell. I understand the language well enough, but the standard prelude gave me problems. I forget the details, but the first attempt involved reading ASCII strings from file. I had some issue with the standard string type and after a bunch of searching and trying other things, nothing worked. The second time I tried to use sockets. After a few days, I discovered sockets were both b…
It was a while since I was involved in that space, but at the time, you had things like the Text library to properly handle human text, ByteString to handle plain 8-bit arrays, Conduit and Pipes as two libraries to do streaming I/O (both network and file) with resource usage guarantees.
Earlier quoted context omitted.
> For example a lot of libraries use Lens. I want to understand Lens? It is not simple: check out the diagram on https://hackage.haskell.org/package/lens . You're making it seem harder that it really is. Yes, it's hard if the package documentation is all you have, but that's the hard way to learn. There are other online unofficial documentation and tutorials (of diverse quality). There's also a book ( https://leanpub…
Ah OK, things have moved on in recent years. Maybe there are more resources out there than I thought.
You can skip the theory and go straight to usage: https://www.youtube.com/watch?v=QZy4Yml3LTY
I wonder if increasing bloat is a permanent thing? Will software ever transition to a cycle of simplification? Has it ever gone through a simplification cycle in the past?
Physical engineering has some limits that push back on complexity. You can only cram so many gears into a Swiss watch. An item can only have so many parts before manfacturing becomes a nightmare.
What will push back on the complexity of software? Will it ever "break" in a way that we just do things differently?
And it would be strange to think that something like haskell could save us, when the compiler itself is such a beast. If something saves us, it will probably look more like FORTH or lisp or Prolog.
I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming acr…
Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a normal developer with working experience in Java, Python, or C++: * It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project. * It takes around 3 months of full-time participation in such a proj…
Compare that to Erlang's half a day to a day for onboarding, and one to two weeks before pushing stuff to prod.
I can't imagine any company that could afford three full-time weeks of onboarding.
> investing 3 months for life-long increased productivity (even if it's just a few percentage points; most feel the effect is larger)
The tales of increased productivity are purely anecdotal. Especially if you're talking about a few percentage points.