https://store.steampowered.com/app/2724650/The_Bustling_World/

:)

😆

I guess it’s a question of whether you’re designing a system from scratch, or having to deal with an existing one. I took the original question to mean the former, but yeah it’s not much help if you’ve already got classes and you have to figure out how to make them play nice together.

Having worked for nearly two decades in a functional language now, that’s precisely how I feel about the imperative style.

🎉

After working with Clojure where dev workflow is interactive, I can’t imagine going back to writing a bunch of code and then trying to compile it all at once. Being able to run your code as you write it saves you an incredible amount of headache.

Oh yeah, GRIS was fantastic as well. I really love their art direction in both games.

a classic

yeah any time you have to do something under pressure basically :)

it is highly technical and JVM specific :)

Portal

it’s art

Yeah, WASM definitely looks promising. It’s also worth noting that you can treat Js as a compile target using something like Elm or ClojureScript. These languages have decent semantics that insulate you from a lot of the underlying insanity. For example, stuff like equality works the way you’d expect it to. I’ve worked on a few large frontend apps with ClojureScript and it was pretty nice as long as you didn’t need to interop with the Js ecosystem.

many such stories

Coroutines are indeed much easier to work with, and I find it shocking that they didn’t catch on in Js world. In general though, I find plain sync code is just much easier to reason about and far less error prone. If you can keep IO at the edges, async’s not too bad, but in a lot of cases you need to do some IO deep within your logic, and that’s when things start to fall apart. Now you have to make everything async, error handling in particular becomes a pain. I think having async is nice as an opt in, but it shouldn’t be the default.

Those are the arguments I’ve seen most commonly as well. In practice, I don’t find they hold up in practice either. The downsides of having a janky foundation for the backend far outweigh any perceived benefits of having a single full stack platform. Also, async style is just far more painful to work with.

I actually think that everybody should learn a functional language like Scheme first because it teaches you to think about state explicitly. It’s very easy for somebody who learned a functional language to pick up an imperative one, but it’s very hard for people to go the other way around.

It is an abomination. I get that you have no choice but use Js in the browser, but you can use anything you want server side. Yet, people willingly choose to use one of the most horrific ecosystems out there.

It is important to keep in mind that any software ends up being a living thing. Even if you know all the requirements up front, which you almost never do, they’re inevitably going to change down the road. Customers will want new features, business might pivot what they’re doing, and so on. It’s pretty much inevitable that the software will keep evolving. It’s key to recognize this and design things in modular fashion so you can evolve things in a sane way as the need for changes comes up. That said, I find you can start small and figure out what the MVP looks like, then go from there. You can draw out the bare minimum and then use that to interrogate the project manager to make sure it matches what they’re expecting.