sfvisser

AI models might transform how we use computers, but will it also change the outcome? Will it make society more productive, efficient and generate more growth? Or will it just provide more forms of entertainment, maybe provide some convenience. Or worse make the bureaucracies of life even more impenetrable?

Don’t know the answer, but as with software/internet in general we need to at least watch out for false sense of progress.

I personally hope the next big wave will be somewhere along the IoT line and physical automation, agri-tech, health-tech, where software transcends the virtual and finally start automating the physical.

They didn’t just ‘have’ a money printer, they ‘made’ one. Many others tried and failed. Say what you want about Zuck, but this some happy accident.

Libraries that have a scope defined implicitly by what accidentally works or doesn’t work can still be very annoying.

You're really fighting the wrong fight here. FP is not about prematurely writing reusable code.

It's about recognizing patterns in code that exist all over the place and reusing those existing patterns for the new code you're writing. This way you can break your new feature into say 20% newly written domain specific code and 80% reusing existing patterns. Patterns that help with composition, enforcing invariants, simplifying writing test-cases, and more clearly signaling intent.

For example, if you provide a monad instance for your "formatting notification objects" I will probably understand how to use your library without even reading a single line of implementation at all. Just by scanning a few type signatures.

This way you and your team mates have a huge head start in understanding your new addition to an existing code base. This is a great win for everyone!

Half joking. My point is that focusing on researchers isn’t that relevant, because the entire idea is a thought experiment. One that many people were philosophizing on before it became a ‘research’ topic.

> Many researchers have conjectured that the humankind is simulated along with the rest of the physical universe – a Simulation Hypothesis

I would rather say many philosophers or even many stoned college kids instead of many researchers.

Very nicely presented! Worked great on mobile.

A fun fact I came across recently is that the northernmost tip of Brazil is closer to Canada than it is to southernmost tip of Brazil. Incredibly counterintuitive,

Lol, looks pretty realistic to me. This is very much like how most tourist in the city behave!

I hope you realize these worker bees created an insane amount of value for their customers, their investors, their coworkers and for themselves.

Yes, more akin to what you’d normally call ‘compose’. Fun stuff nonetheless!

Maybe you can load a single interpreter instance once on app startup and reuse that in different contexts? Not much experience with this, but I assume there are possibilities.

This looks like a great way to add scripting capabilities to your rust app! Binding ops to build your own runtime seems easy enough.

Would be nice if there was an easy way to integrate TypeScript and have access to the type checker. So you could load code at runtime, type check it and run it when possible. This, combined with Deno running a sandboxed environment seems pretty useful!

Another interesting approach to copy-on-write for immutable collections (for example arrays) is where you actively mutate the array in place, but leave the original as a lazy description/view of how to get back to the before state.

From the outside the effect is the same, but the performance is optimized for accessing the updated collection and only possibly using the old value.

Great for cases where you want the immutability guarantee, but where it might be unlikely the old value is actually going to be used in the general case.

Economic growth is more than just using finite material resources. It’s technical innovation, labor productivity increase, efficiency improvements due to economies of scale, specialization, efficiently recycling scarce commodities, etc etc

Yes, we obviously need more economic growth, there simply is no alternative.

> Even if resource use (in terms of conservation of mass and energy) is fixed, you can still have economic improvements within that steady-state system, can't you?

Sure, technical innovations and efficiency improvements to get more for less is also economic growth. And therefore by definition not steady-state.

> Bezos got richer by making his employees poorer, for instance. He could have chosen to make his employees richer at the expense of making himself poorer.

No, they both got richer. Maybe Bezos had a chance to make his employees slightly more rich and himself less so, but ultimately no-one got poorer here.

Why is that “simply”? Why should we care more about biodiversity than construction and farming? I think really nothing is simple about this trade off.

I can see how this works, but my personal experience is that concurrent code that is finely scoped is easier to reason about than larger-scoped concurrency already anyways. Hardly a controversial statement, I guess. So if nurseries help me reasoning about finely scoped stuff even better that's great of course, but only solves part of 'the problem'. And maybe not the most interesting part.

Just quickly running a task to perform a handful of stuff concurrently for a single purpose (like doing a few network requests and packing the results) is hardly where I encounter big issues. The compositional behavior of Futures really helps here I think. A bunch of `Future<Result<A, Error>>` go a long way.

Read the article but honestly don’t fully understand it. How does using this not end up with one big nursery started somewhere in your main passed down everywhere and basically scoped to the entire app lifetime? Getting you in back in the same spot as before.

My (rust) code using Tokio starts a bunch of tasks in main that live for the entire lifetime of the app. They’re independent and communicate over channels with each other – and possibly the outside world.

Hard to see what problems this causes that Trio can fix. But maybe I’m zooming in on the wrong use case?

And you can weave effects into them just like normal functions, without losing the ability of composition. Fun stuff!

In defense of OO-style access pattern, they’re a lot simpler and syntactically well integrated into most languages. The flexibility of lenses is clearly visible in types (in most current implementations). Ideally you want to hide this when you don’t need the flexibility.

Are keypath like Haskell lenses? First class composable getters/setters?

Or just the getter part?

My toy FP language did. :) It’s perfectly possible to just parse a list of arguments and figure out currying in a later compiler stage. In my experience it even somewhat helps with producing nicer arity-specific error messages, which user might appreciate.

> In particular the common abstractions (Monad, Applicative, Functor) are used very differently in different libraries (everyone seems to want to write her own DSL), so it's hard to get comfortable with third party libraries.

I don’t see how this is true. These common abstraction make reading code incredibly easy most of the time. Many Haskell libraries are based on compositional building blocks. Seeing a monoid, functor or monad instance gets you 90% there in understanding the usage. It’s really the superpower of Haskell that I miss (and badly reimplement) in every other PL.

The fact that some things are more easily — or better, directly — expressable in some languages doesn’t necessarily imply your thinking is changed or that you can’t internalize the concept without access to that language.

I don’t have twenty different words for specific shades of green or types of snow, but can still easily recognize them and use them in my thinking.

Language shaping the way you think always feels off to me. Most languages are pretty much universal and unbiased and are capable of expressing an infinite amount of concepts. As easily as their negations, subtle variations, contextual dependencies, nuances, etc.

I think this is valid reasoning. Allowing to turn errors into warnings for dev builds would probably allow for fixing issues faster. Given the UX is good.

I use todo!() a ton when building as well. Sketching out data types and signatures before diving into implementation details.

> It's perfectly valid to trade off correctness for gains elsewehere.

Agreed, but no-one is disputing that, right? The problem is that very often saying correctness was given up in order to gain velocity and simplicity is simply a lie. Incorrectness can easily lead to slow development and tons of complexity.

It’s only fun when the trade-off is actually a trade-off.

The author clearly does understand language design. He probably even agrees with your description of go above, but simply describes it really doesn’t work for him.

Isn’t toTreeF just ‘out’ as in ‘newtype Fix f = In { out :: f (Fix f) }’ ?

No open source code base I can point to right now unfortunately.

But this is fun stuff, so I couldn't help creating a simple gist to demonstrate the concept: https://gist.github.com/sebastiaanvisser/cd6ee46356e3ecc8945...

The trick is to keep all the combinators specific to your data type. In Haskell you can derive your functor (and applicative/foldable/traversable) and have a single cata to rule them all. In Rust you build them specifically for every datatype. Less neat, but could still be totally worth it!