Multi-single-tasking: Brainstorming, half-baked... I would have ignored Ceptre in the past. It claims to be a language for writing games. The very idea makes me yawn. But, one of the guys at the Torlisp monthly meetup is deeply into robotics and Scheme and another guy, in the film industry, uses Racket for hobbying in game programming. My own interest is in concurrency and simplicity and compiler-writing. These fields are all related. Watching the 2015 Strangeloop presentation about Ceptre piqued my interest. Ceptre is logic programming, but with a twist - it has a built-in notion of explicit ordering. I thought that I could knock off a better game language using my diagrams of state machines. I continued to learn about Ceptre. Aside: Ohm-JS has built-in explicit ordering and is “not” context-free. I have to wonder if Ceptre is to generalized formalism as PEG (Ohm-JS) is to context-free grammar formalisms. Dunno yet. FYI, I watched the Ceptre talk. I then read the paper and now am reading the thesis. And in the background (foreground?) I am trying to convert Dungeon Crawler (.ceptre) into PROLOG. I think that Ceptre can be simplified down to a small handful of primitives which are easy to express in PROLOG or Lisp or JS or ..., but they are not the first thing that you think of when programming PROLOG. From there, of course, I would expect to generate code for Dungeon Crawler in Lisp and JS and Python and … In the back of my mind is the question “Is This Steam Engine Time?” (Paul Morrison). Are we seeing a shift away from single-threaded languages (Python, JS, Rust, Haskell, lambda calculus, etc.) to ???. Certainly, hardware in 2022++ is drastically different from hardware in 1950 and we should be finding better ways to cope with this New Reality (“The Great Reset in Computing”)… FYI: The drastic difference in hardware is the reality that we now have cheap CPUs and cheap memory. Both of these notions were completely unimaginable in 1950. Instead of crushing our hardware with bloatware like Linux, we can simply throw rPIs at a problem, each running single-threaded programs. There is no need to fake out multitasking anymore. Multicore is just a clumsy way to bridge across the two drastic realities, i.e. to force-fit 1 CPU programming languages onto many-CPU-programming. In fact, we shouldn’t even call CPUs CPUs anymore, since there’s nothing Central about them. Early adopters of 1950s computing built games. Maybe early adopters of 2022++ computing will build new kinds of games with 1,000s of PUs, for example 1 processor for each player and for each NPC. Ceptre: [ https://futureofcoding.slack.com/archives/C5U3SEW6A/p1674614304225439 Call/Return https://futureofcoding.slack.com/archives/C5T9GPWFL/p1675094970899729?thread_ts=1674396396.762359&cid=C5T9GPWFL I have not investigated this, but it, too, appears to be barking up the same tree: FBP (Flow Based Programming) https://jpaulm.github.io/fbp/

Very interesting line of thought. The first quote in the flow based link "The real world is asynchronous: don't try to force everything into a synchronous framework derived from the architecture of early computers." as well as your thoughts around cpus not being central anymore and cheap cpu/memory... I think they all really do follow on what you're highlighting as the death of single threaded programming languages

Thanks for your comments, and causing me to think / clarify! Trickle-down: I think that industry doesn’t adopt the current solutions because developers haven’t really solved the issues in a palatable manner. Developers haven’t solved the issues in a palatable manner because developers think that the issues are difficult. Developers think that the issues are difficult because they don’t have the language for dealing with such concepts easily. Developers are bought into the Silver Bullet of Functional Programming which helps them deal with fancy calculators but shoots them in their own feet for other kinds of problems. Real Physicists deal with this kind of thing by inventing new notations. Software developers have been coerced into thinking that there is but one notation (all popular programming languages are based on functions).

Makes sense! I forgot to think about that. I wonder how does one go about building the tooling and ecosystem around these new ideas? Developer tooling is expensive to build but harder to monetise? About the inventing new notations, I really love that and the reference to physics. I wasn't aware that they did that... but thinking about DSLs and how we seem to invent new languages or libraries (pseudo DSLs in my book) when there is a vastly new domain in computing... it connects a lot of dots for me

“This part really makes me sad, and I want to do something about it” I would be happy to expand, if you want to tolerate more bloviation from me...

Yes absolutely, eager to learn more

here’s a start - a quickie note on how to build a simple pattern matcher and then a suggestion on creating a DSL to help with the task https://publish.obsidian.md/programmingsimplicity/2023-03-12-Simple+Example+of+a+Transpiler+Using+Ohm-JS

Sorry this got lost in my feed. I'll take a look tomorrow, thanks for pinging 😄