71–80 of 167 posts
I'm not experienced enough to know, but it does feel like Haskell prioritizes "clever" code. Very beautiful, but hard to understand at a glance.
Earlier quoted context omitted.
constexpr reduces general side effects. Can we reduce specific side effects? For one very important example, consider software transactional memory. It has general side effects in the implementation behind the scenes, but inside transaction code they are not allowed. What will C++ solution look like? stmconstexpr?
I thought STM was dead. Seems to be minimal adoption within clojure and all the hardware which tried to do it has been disabled for being broken. What makes it a particularly important example? The C++ plan of attack probably is more syntax though. Maybe parameterise constexpr, constexpr or similar.
[1] https://haskell-cafe.haskell.narkive.com/t6LSdcoE/is-there-a...
Also, the rule of thumb is that you have to use STM, and it is mandatory, if there are more than one developer working on a project or if you have more than one module in your solo project.
Earlier quoted context omitted.
constexpr reduces general side effects. Can we reduce specific side effects? For one very important example, consider software transactional memory. It has general side effects in the implementation behind the scenes, but inside transaction code they are not allowed. What will C++ solution look like? stmconstexpr?
I thought STM was dead. Seems to be minimal adoption within clojure and all the hardware which tried to do it has been disabled for being broken. What makes it a particularly important example? The C++ plan of attack probably is more syntax though. Maybe parameterise constexpr, constexpr or similar.
Clojure's STM implementation is missing crucial combinators to combine different STM actions compared to Haskell (e.g. Haskell's `orElse`), which makes it much less useful. It's also more difficult to remember how to compose STM actions in a dynamically typed language, since you can't directly inspect the action at the REPL in the same way you would do with a simple data structure, which means those few Clojure codebases which use STM don't tend to use it pervasively, but instead confine it to a single place, because it gets too easy to make the equivalent of type errors in Haskell (but which are much more difficult to diagnose because they're not really type errors from the perspective of Clojure).
Or to put it another way, Haskell's STM implementation focuses on STM actions as first-class entities, which allows you to have all sorts of reusable actions scattered around your codebase or even stored in data structures (e.g. a list of actions). This is also why there are combinators for combining different STM actions (e.g. `orElse`) rather than just operators on transactional references.
This means you can build up a rich library of actions in different places throughout your codebase, then at the "very last moment" in your program you atomically combine different STM actions together (ensuring through atomicity that they all see a consistent view of the world).
Clojure's STM implementation on the other hand focuses exclusively on transactional references, which means it's difficult to build up a library of STM action "lego pieces" that you can reuse throughout your codebase. You can try to retrofit the same thing, but then you run into mismatches between different actions which is what I alluded to with type errors. This lack of composability is my view as to why STM has mostly withered in Clojure.
Earlier quoted context omitted.
constexpr reduces general side effects. Can we reduce specific side effects? For one very important example, consider software transactional memory. It has general side effects in the implementation behind the scenes, but inside transaction code they are not allowed. What will C++ solution look like? stmconstexpr?
I thought STM was dead. Seems to be minimal adoption within clojure and all the hardware which tried to do it has been disabled for being broken. What makes it a particularly important example? The C++ plan of attack probably is more syntax though. Maybe parameterise constexpr, constexpr or similar.
STM simplifies parallel execution of atomic consistent transactions significantly.
Should probably look into Haskell. Have absolutely no clue what's it best suited for?
Thats not a knock on Haskell either, I have a more bog standard job than it likes.
> Haskell in Production Does not use Haskell. Is it just me or is this... weird?
I've talked to a lot of people using Haskell in production over the years, and one of the things I've consistently noticed is a disconnect between the Haskell features that are often touted, and the Haskell features that people use in production. This isn't always a quiet omission, like "we didn't end up using this" either. The best example is that a lot of people end up doing some significant work to disable lazy ev…
If you disable lazy evaluation, you would not be able to write arbitrary "where" sections, with definitions ordered as you want them, including tying-the-knot definitions, which are not exceptionally rare. So no one disables lazy evaluation. It is strict evaluation that is selectively enabled. I also have to say that focusing on the types in the compiler development was the right thing, but what was not right is not…
True of vanilla Haskell, but from the article:
> So we ended up with Mu, a whole-program compiler to a bytecode representation with a small runtime interpreter... Mu has a strict runtime, which makes program performance easier to analyse and predict – but prevents us from just copy-pasting some Haskell libraries that rely crucially on lazy evaluation.
If S&C is to count as a Haskell success story (which it's often touted as), then I think it's fair to point out that it's a codebase where strict evaluation is used throughout.
Earlier quoted context omitted.
>The reason that lazy evaluation leads to performance problems is that programmers don't know how to use it correctly It's because it's objectively harder to reason about performance with lazy evaluation as performance becomes non-local. You can no longer reason about a function's performance just by looking at its body, instead you have to know the nature of the inputs passed to it (whether they're thunks or materia…
> It's because it's objectively harder to reason about performance with lazy evaluation as performance becomes non-local. This is off-repeated, but has two interpretations. If you mean performance as in number of steps needed to reduce an expression, lazy evaluation is superior to strict evaluation. If you mean the indirection needed to access a thunk, well someone -- either the producer (strict) or the consumer (laz…
Here's a simple specific example. Take the Haskell expression [1..n], for some big n. There is no general answer to the question "what would be the performance implications of replacing [] with [1..n]" – it depends on the context of [].
In a strict language, you can say (roughly at least) that replacing [] with [1..n] will add at minimum a certain number of extra CPU cycles and a certain amount of additional allocation. This kind of reasoning is pretty rough and ready, but it is accurate enough to be useful for reasoning about performance in practice.
I note that Simon Peyton-Jones has said these exact words in a public talk:
"Laziness makes it much, much harder to reason about performance."
I think it's extremely unlikely that he's mistaken or confused on this point.
I'm shocked, in the first paragraph they assert that they handle 6 million lines of code. Is it common for the fintech industry to have codebases of that magnitude? I'm aware that for example OSes and browsers can achieve similar sizes (if I'm not wrong certainly more) but I'd have never thought that a fintech company could approach such size. It just seems way too much... Edit: Question out of ignorance for people t…
6 million is easy, in fact its probably a small-ish fraction of their total code as a firm. Especially for a bank where their processes are a bit more defined than (say) a hedge fund. What do you think fintech companies do? (I'm not entirely sure either but I can potentially give a flavour of finance coding in general) If you want to come up with prices for things then you'll need a bunch of mathematical optimization…
6 million sloc is indeed a fraction of what you’ll find in an investment bank. It’s also (I think) what makes it very interesting: an IB is a huge software system, with a mixture of extremely legacy (30y) and bleeding edge tech, and very strange human made rules.
wtf