I've been using Haskell professionally for the last 5 years, I definitely hope I can continue!
How can you prevent code from creating a handle in a new place?
Resumable code is extremely helpful and I'm pretty sure you're describing a chicken and egg issue: if resumable code was readily available in general, people would use it a lot more and it would look like a very normal…
This is basically what we already have in Haskell. Debug functions that sidestep the typing system can be annotated with a warning and you can make this one an error while compiling for production. And in a more general…
First, you can write a function that's generic on the effects used, so you could write use it in a way that calls an LLM and use it elsewhere in a way that cannot, with the same logic. But I see the need to change the…
Do you know papers or technical reports that demonstrate the scalability of authorization-preserving search indexes? I don't doubt they exist but what we hear about are the opposite cases, where this was obviously not…
One typical way to resolve this is to use Voluntary Oblivious Compliance (VOC). In this capability-based pattern, every storage service could provide an opaque handler to a user that represents their authorization and…
My team builds frontends in Elm and backends in Haskell and we experience the opposite: FP made the code very easy to reason about and plugging things together is easy too.
John Carmack is already advocating for the use of Haskell for video games.
You need to sketch it and possibly implement it yourself because actual examples don't exist. QED
I read about them a few times, but I never saw them proposed as the main access to recursion. Are there examples of that use?
> So the compiler of your immutable language will still have to insert locks No it won't, not at the myriads of places they're needed when there are mutations all over the place. Of course there are mutations in FP, so…
> Neither C nor C++ have built-in immutable data structures First of all, yes they do, you can use const on structs and objects and methods to ensure your C/C++ data structure is immutable. But this is moot anyway: > so…
But once it is created, all pieces of code accessing it can be executed in any order because there will never be a write on it again.
Look for actual examples in the wild that weren't error prone and I'd be surprised you'll find any. I get that you can imagine it. I'm saying it wouldn't work in practice.
You're misunderstanding ZFS' persistent data structure. It's the whole point that it's not doing a copy then modifying something. Also no one claims there's one immutable data structure that's faster than all mutable…
Of course I use combinators more often than I write recursive functions. But if someone finds recursion less readable, I still think they're missing something crucial. And I don't think recursion is a GOTO that should…
Experimenting around the state of the art or reimplementing the state of the art ourselves while being informed by it would be fine. I guess it would be a great exercise, as you said.
Do you have examples of this idea that were implemented and weren't insanely error-prone?
A mutable data structure will have such data dependencies all around. An immutable data structure cannot, because it will never be written in after creation.
> It's literally not possible for this to be true When you need a state that you can rollback, an immutable data structure lets you share the parts of the structure that didn't change between states. That's what ZFS…
> Do you mean to say the compiler will insert locks? I think you're right, it's the compiler that'll insert the locks according to the semantics of the language. > For an out-of-order superscalar machine, mutability has…
When you use a mutable data structure, and your code is concurrent, you'll force the CPU to put locks everywhere in your code so that several cores won't see stale data in their internal caches. Even when you aren't…
Most so-called software engineers fail to do something crucial in engineering: they have zero knowledge about the scientific state of the art about programming. I agree that the absence of liability enables this.
Do you know an unsafe paradigm that has those advantages over, say, STM or Actors?
I've been using Haskell professionally for the last 5 years, I definitely hope I can continue!
How can you prevent code from creating a handle in a new place?
Resumable code is extremely helpful and I'm pretty sure you're describing a chicken and egg issue: if resumable code was readily available in general, people would use it a lot more and it would look like a very normal…
This is basically what we already have in Haskell. Debug functions that sidestep the typing system can be annotated with a warning and you can make this one an error while compiling for production. And in a more general…
First, you can write a function that's generic on the effects used, so you could write use it in a way that calls an LLM and use it elsewhere in a way that cannot, with the same logic. But I see the need to change the…
Do you know papers or technical reports that demonstrate the scalability of authorization-preserving search indexes? I don't doubt they exist but what we hear about are the opposite cases, where this was obviously not…
One typical way to resolve this is to use Voluntary Oblivious Compliance (VOC). In this capability-based pattern, every storage service could provide an opaque handler to a user that represents their authorization and…
My team builds frontends in Elm and backends in Haskell and we experience the opposite: FP made the code very easy to reason about and plugging things together is easy too.
John Carmack is already advocating for the use of Haskell for video games.
You need to sketch it and possibly implement it yourself because actual examples don't exist. QED
I read about them a few times, but I never saw them proposed as the main access to recursion. Are there examples of that use?
> So the compiler of your immutable language will still have to insert locks No it won't, not at the myriads of places they're needed when there are mutations all over the place. Of course there are mutations in FP, so…
> Neither C nor C++ have built-in immutable data structures First of all, yes they do, you can use const on structs and objects and methods to ensure your C/C++ data structure is immutable. But this is moot anyway: > so…
But once it is created, all pieces of code accessing it can be executed in any order because there will never be a write on it again.
Look for actual examples in the wild that weren't error prone and I'd be surprised you'll find any. I get that you can imagine it. I'm saying it wouldn't work in practice.
You're misunderstanding ZFS' persistent data structure. It's the whole point that it's not doing a copy then modifying something. Also no one claims there's one immutable data structure that's faster than all mutable…
Of course I use combinators more often than I write recursive functions. But if someone finds recursion less readable, I still think they're missing something crucial. And I don't think recursion is a GOTO that should…
Experimenting around the state of the art or reimplementing the state of the art ourselves while being informed by it would be fine. I guess it would be a great exercise, as you said.
Do you have examples of this idea that were implemented and weren't insanely error-prone?
A mutable data structure will have such data dependencies all around. An immutable data structure cannot, because it will never be written in after creation.
> It's literally not possible for this to be true When you need a state that you can rollback, an immutable data structure lets you share the parts of the structure that didn't change between states. That's what ZFS…
> Do you mean to say the compiler will insert locks? I think you're right, it's the compiler that'll insert the locks according to the semantics of the language. > For an out-of-order superscalar machine, mutability has…
When you use a mutable data structure, and your code is concurrent, you'll force the CPU to put locks everywhere in your code so that several cores won't see stale data in their internal caches. Even when you aren't…
Most so-called software engineers fail to do something crucial in engineering: they have zero knowledge about the scientific state of the art about programming. I agree that the absence of liability enables this.
Do you know an unsafe paradigm that has those advantages over, say, STM or Actors?