I've been saying this for years, but now that Bartosz says it... :p https://bartoszmilewski.com/2021/02/16/functorio/ (For once, the HN discussion has some interesting and relatable thoughts.)

I assume Factorio assemblers consume the objects you feed them? Which functional languages do this?

I am obliged to point out that this bit..

In Factorio, the nesting of functors is drastically limited. It’s possible to produce belts, and you can put them on belts, so you can have a beltful of belts, 

Belt Belt

. Similarly you can store chests inside chests. But you can’t have belts of loaded belts. You can’t pick a belt filled with copper plates and put it on another belt. In other words, you cannot transport beltfuls of stuff.

... is something you can do in Hest. And it's bonkers. And it's weird. And I don't like it. It hurts to think about. And thanks to this article, I now know why.

Realistically, that wouldn’t make much sense in real world, but in Functorio, this is exactly what we need to implement monads.

Ah. Monads. Didn't see you come in. There's beer in the fridge. I'm going out. I'll be back.. later.

So you're saying Hest has monads? 🤯

Such a cool idea. I knew where he was going after the first paragraph. And yet I never thought of it.

@shalabh — It has something. You can put conveyors (loaded with stuff) on conveyors. But it's weird to think about, and I don't like it, and I'm kinda just ignoring that it is even possible for now. It's emergent from Hest's elements in the way that, say, (absent ASLR, etc) using pointers to that point at your own code is emergent. You can do it but.. don't. Conveyors conveying conveyors even looks weird. They tend to wander around unpredictably. So maybe a good term for them would be "nomads".

I've seen the invisible-middle demo before, and kinda nodded along. But the bezier curve, whaa, what the heck is even that? Is it a single curve? Extremely mind-bending.

The bezier curve thing is just... me dialling-in what I want Hest to look like. It's not actually doing any computation*. It's literally just using the 3 essential language primitives (points, edges, and conveyance) to do the geometric construction of a bezier curve. It's playing off the fact that the programming tools are art tools. (* thank goodness, because I don't want to even start to think about what it means to do multiple nested layers of conveyors. Gross gross yuck no get it out of my body)

No, not yet. It's been on my mind to do that. Especially if I do end up taking some time off from Mu.

It's been a while, but I seem to remember "points carrying points" being close to the essence of Bezier curves even if you're not doing visual programming. So, if that's a natural way to implement them in Hest, neato.

The thought of making a programming language feel like a video game is (very) exciting, but I've concluded in the past that a lot of the fun in video games is making incremental, measurable progress towards goals. Video games usually set this up by creating webs of artificial hurdles, and you obviously don't want to be doing that in a PL. For example, in Factorio you periodically run into bottlenecks in your factory, for example a belt reaches its capacity, or you start running low on a resource. It's fun to resolve these artificial constraints, and that's what most of Factorio is about. There's no analogue of these things for writing code 😕 (except perhaps performance optimization, which is rarely "fun").

Disagree, I think? The hurdles don't have to be artificial to be fun. There are lots of times in programming when you can make incremental, measurable progress. If you've got your abstractions and data model set up right, you can crunch your way through e.g. UI or web request handling (recent examples for me). At its best, writing video game code itself feels the same. TDD is (in my understanding) in large part a way to make that feedback loop more repeatable.

I've definitely had fun programming before, don't get me wrong 😛. But much of my time spent in the IDE is struggling to figure out what low-level thing needs to be done next, and the correct steps to accomplish it (and then of course, figuring out that you've done something wrong, and trying to figure out why it's wrong). That deep, low-level problem-solving is definitely not as fun as running around building conveyer belts. It tends to be much more mentally exhausting.

a lot of the fun in video games is making incremental, measurable progress towards goals. [lots of good thoughts excised for brevity] There's no analogue of these things for writing code

I don't believe that that's true. I can't prove it, but it doesn't feel right. But I would totally agree with There's no known analogue of these things for writing code. I have it as one of my ambient background shower-thought processing tasks to figure out how to design game dynamics (to borrow the sorta dated "mechanics / dynamics / aesthetics" framework) that encode programming-related tasks, such that you can enjoy playing with these dynamics in a game-y system while still accomplishing actual creative / expressive work (loathe to say productive work, but sub that in if that thought doesn't irritate you the way it does me). It's easy to imagine a ton of kinda-bad "gamification"-y visions. The most well-known bad example is probably Github's contribution tracking. It incentivizes opening and closing a lot of low-value issues, and making a lot of tiny low-value commits. But Github also fosters the social motivation to write good docs, which is very good (and very conventional) dynamics design. I think once we're playing in the "Factorio is my IDE" space, there's plenty of unexplored possibility and very little should be taken as a given.

If you can prove me wrong, you'll be a legend Ivan 😍. I'm ready to implement (steal 😏) promising ideas at a moment's notice. But yeah, the key point is not to add artificial elements to the act of programming, such that you're able to "score points" and get dopamine hits whilst doing very little actual work. I definitely see gamification working for chores like code review, which can be quite rote.

Yes, the key is to make sure the goals or "points" are real. This probably means they need to be self-defined, seeing how measuring software productivity is an open problem and will likely remain that way forever. I just remembered: possibly the most video-game-like experience I've had while "programming" was my brief experience trying to prove things in Coq. Real goals (of a sort, these were practice problems), with a little dopamine hit when I proved each one, including subgoals. Sometimes I had to think creatively, sometimes I could just grind through. Similar to the TDD example, I guess, treating a spec as the goal. If it's not exactly a research direction in itself, I think this is at least a potential payoff of improving the ergonomics of formal methods.

Isn't it folklore that programming can never be "fun" all the time, because by definition, if you can keep your mental taxation low, then it's because you're doing rote work, and rote work can (and should) be automated/abstracted?

I don't think fun comes from low mental taxation, but rather operating at the edge of one's capabilities. (See: Flow, &c). Tooling drives me crazy primarily when it breaks my flow states and makes me deal with nonsense rather than focusing my attention on the problem I'm trying to solve.

gary’s mod is a great example of a game that doesn’t seem to have artificial hurdles except those imposed by the players

I am confused by @Nick Smith talking about fun and programming. My experience is all the opposite. Or I misunderstood something? I have lots of fun in doing any of my programming activities. At least as much as playing games. Maybe more. In fact, writing this makes me realize one thing: I once used to take lots of time playing games, and at some time I do it less. And it seems that corresponds to the time when I start coding more and more (at university)!

[...] except perhaps performance optimization, which is rarely "fun"

I usually have lots of fun doing this kind of task.

@ogadaki You (and many in this community) may find programming consistently fun, but I think you’d find most software engineers disagree 😅. Regardless, take my comments on the topic with a grain of salt... I haven’t really thought deeply about this topic. Jack’s comments about Flow have reminded me that a level of challenge is required for fun to manifest.

You are right: around me I meet lots of people that don't have as much fun doing programming as I do, they are doing well as a job and even slightly enjoy it, but they don't have particularly fun about it. Which is totally OK. Even more, I guess this is to take into account when designing programming environments: don't assume all people have fun or will do it for fun.