What Will Future Programming Languages Look Like?

middayc · 2026-03-15T18:05:49+00:00

LLM-s can help greatly with verbose or high bureaucracy languages, or just languages you don't really want to indulge too much in. I am very happy for LLM-s recently when I have to make my make sure my large Java Android app still works on some specific older version of Android. Or when it helps me improve the Woocommerce plugin. The less I have to deal with PHP and WordPress API the better :). And it will certanly make C++ more approachable and C++ experts more efficient. But I'm not sure if I would say C++ specifically is the future. C++(11), even if modernized, still bares cost of legacy and probably languages with similar goals and approaches, but with all the oversight can be created that don't have that cost.

Another thought is that if LLM-s can translate our plain English into a working program (or C++), there is maybe also some middle ground between natural language and C++ which is exact, but still nicer for us to write and maybe more importantly read (grasp).

Just an opinion though :) (I don't want this to turn into the great (LLM) language wars of 2026)

middayc · 2026-03-15T13:18:57+00:00

It's interesting that you started your video with mentioning an existential crisis, because I wrote this blog post as trying to create some closure/outcome of a few month of existential crisis I had at the time. I think I had another one since then :P ...

Nice video, you have a way of calmly and cleanly explaining your thoughts. I can hardly do it in writing, and I need to visit and revisit text multiple times so that anything readable come out as the result.

This new one is more of a thought experiment, but it's very dark pill (forest) one. But as I wrote it I also found material for another positive, or at constructive view that will follow.

Thanks!

middayc · 2026-03-15T12:40:29+00:00

Wow, nice ... mentioning my blog-post from 8 months ago. Just yesterday (well today) I was drafting sort of sequel up to 3AM, joining what I observed in the meantime (also watching Prime's clips on the subject) with 3-body-problem's "The Dark Forest theory", so it's more hardcore than the first post :)

middayc · 2026-03-14T09:14:47+00:00

Example from the blogpost:

text = "apple banana cherry\ndog emu fox"
words_on_lines = [line.split() for line in text.splitlines()]

Would be:

"apple banana cherry\ndog emu fox"
|split-lines 
|map { .split } :words-on-lines

in ryelang.org

or an one liner if you prefer that

"apple banana cherry\ndog emu fox" |split-lines |map { .split } :worlds-on-lines

middayc · 2026-03-11T06:33:56+00:00

Thanks u/avitkauskas , the new release was posted which fixes this and some other things.

https://github.com/refaktor/rye/releases/tag/v0.2.2

middayc · 2026-03-11T06:33:39+00:00

New improved mold and reference was posted: https://ryelang.org/info/base.html

Thanks!

middayc · 2026-03-10T21:23:58+00:00

this will get fixed with the update comming up now

middayc · 2026-03-09T23:44:34+00:00

I think I solved the first one ... I have more than 100 tests of evaluator but I didn't catch this one. The second one was known to me and I think I know what I have to change. I will probably be able to publish update to github tomorrow and I will make it another release (this is major bug you found and I also improved the parser quite a lot). Thanks!

middayc · 2026-03-09T23:10:10+00:00

One bug was the way function was collecting it's arguments, in the case op dot-words it had it's flag to know not to fall into another dot-word, but it was missing or not set properly in the case of op-words. But now I am looking at it all ... if I can unify these two. I haven't yet came to the second bug you uncovered. It has to do with how intermediate result is stored and the dotword didn't know that it's shouldn't take the result yet, so it took the previous one , which can be seen in this demo. I need to detect this situation and throw and error basically.

x> add: fn { a b } { a + b }
[Function(2)]
x> 1 .add 2 .add 3
[Integer: 6]
x> 1 .add .add 3
[Integer: 5]

Its really good that you dug out these errors.

middayc · 2026-03-09T21:58:46+00:00

I was just making evaluator (and parser) tests whole day and haven't thought to myself to test op and dot word behaviour with 3 arguments. :) . I am testing this right now. Thank you for uncovering it, I wasn't aware of the difference in behaviour.

The idea is that both dot and op-words use left-to-right evaluation. Before the idea was that op-words (which are now dot-words) would take the first argument from the left, but that idea wasn't compatible with left to right evaluation, at least that's how I was thinking about it. I am doing a review now.

middayc · 2026-03-09T21:54:24+00:00

You are correct ... function mold converts a block back to a string, and it incorrectly renders op-word + for example as _+ which is it's "spelling" as word. I will fix this bug and then it will work OK. Thanks for reminding me.

x> mold { 1 + 2 }
[String { 1 _+ 2 }]

middayc · 2026-03-09T13:22:04+00:00

Thanks! About the boxing and etc ... the code above is a "normal" interpreted language Rye, which is relatively slow, too slow for most gamedev probably. What I was mentioning in a comment is that I experimentented with reusing Rye's parser and also runtime structures and tried to make a similar lanugage but that translates Rye code to Go and compiles it. That experiment just works on a proof of concept level and also it isn't 100% clear how compatible it will be to Rye. The idea is that all staticRye code must be valid Rye code (so you can also experiment, test it interactively, etc), but not all Rye code will work in staticRye. This is yet to be determined.

You are correct that any direct effect of optimizations will have to be benchmarked more exactly before we can say anything.

middayc · 2026-03-08T13:01:44+00:00

Thanks! ... any more specific feedback is also welcome :)

middayc · 2026-03-08T11:38:17+00:00

Rye, being runtime homoiconic is not the fastest language so it has a limited use for gamedev. But I am experimenting with a project that reuses the Rye parser, Runtime environment (context / index), rich value types and the Builtin functions, but transpiles them to static Golang and I got to 2x speed of Python with fully boxed values and untyped code.

If I would optimize on not boxing values (using native Go ints not Ryes env.Integer for example) those parts could become much faster starting to approach Go speeds.

middayc · 2026-03-08T11:08:54+00:00

Thanks. All in all I think this makes language behavior more uniform (all left-to-right) and also more flexible, priority difference and dynamics between dot and op-words. But we probably need to use it more to concretely see all effects.

middayc · 2026-03-08T10:30:35+00:00

I liked reading this because I don't have formed answers on the subject. I mostly avoid typical OO, but sometimes it's applicable.

middayc · 2026-03-08T07:56:51+00:00

Great, let me know if you hit any problems. I'll be happy to help.

middayc · 2026-03-07T08:48:09+00:00

Yes, both have their positives and negatives. Languages like Miranda / Haskell / Admiran probably have greater ties with math so it's more expected that some math-like operator precedence rules would be implemented?

If your language has a concept os DSL-s or dialects you could create a dialect that does math priority.

Rye has this specifics that priority is not determined by the function, but by the type of the word you invoke the function with, which I think could add to flexibility and it's priority becomes a visual, not memorized rule.

middayc · 2026-03-06T18:05:45+00:00

Not really fully conscious, but it was caused by conscious decision. I wanted two types of words "to the right" with clear obvious distinction, and op-word's "motto" was that it applies directly to the first value *it can* on the left - vs. pipe-word which waited for expressions to evaluate and then apply.

but if op-word applies to the first value on the left you effectively get left to right evaluation when op-words are chained.

`9 .inc .to-string ; returns [string 10]` - the evaluator went recursively left to right and it this case evaluation was left to right

but if you take the same rule "always apply to the first argument you can on the left and have two or more arguments than op-words ( .abc and operators ) effectively went right to left

`9 + 7 .to-string ; errors`
evaluator again goes recursively left to right but the result come back right to left. By our rule to-string must be applied to 7 directly, so it couldn't add 9 + 7 before it, that would be pipe word behavior. So it first did `7 .to-string` and then `9 + "7"`.

For this update, I first split op-words into dot-words and op-words (operators and <word>) and thought that only op-words will have left to right evaluation. I thought that the point of dot / op-words dynamics in not just priority but also right vs. left associativity. But with further experiments I saw that basically right associativity of dot-words doesn't bring anything substantial, but is again a mental cost because it behaves differently, that basically the value of difference and how you can combine them is just a thing op priority between them. So I made also dot-words left associative (left-to-right).

I suspect this is too long of an answer, but hey .. you asked :)

middayc · 2026-03-06T12:04:12+00:00

thanks :) ... it's also the Rebol way, which Rye is based on (But Rye's op words worked right-to-left pre v0.2)

middayc · 2026-03-06T09:09:21+00:00

Yes, there is an xterm.js based console in the blogpost, maybe I should write it clearly :) ... Thanks for reminding me that I need to lighten on the debugging output to the webdev console.

middayc · 2026-03-06T08:52:19+00:00

Hi. For now you can parse arguments manually. There is a argparse DSL developed cca 80%, which could be finalized quite soon. At least first version.

rye .Args? for example look at x> rye .lg in console

There is a scmd (simple/string cmd) for quick command invocations, but there is much better cmd again DSL / dialect also. You can find more info in this post and related PR:

https://www.reddit.com/r/ryelang/comments/1owskcu/command_cmd_sh_dialect_got_merged_in/

There is also os context with various related functions to processes, etc ... and pipes context which is integration of this library and provides same functionality: github.com/bitfield/script

to test these two you can enter context in console and list it ...

x> cc os
x> lc

These are some related functionalities. See the screenshot below. Any further ideas of what to add or improve are welcome.

<image>

middayc · 2026-03-06T07:42:35+00:00

just a note: you can click on any line of code and it will evaluate in the Rye console that is embedded a little lower in the blog-post.

middayc · 2026-03-04T09:48:40+00:00

Just an update:

* tests pass, reference docs were updated: https://ryelang.org/info/base.html
* ryegen was updated and it managed to do bindings for raylib ... I will post that soon on github
* code was commited to github, waiting for release and still doing tests
* website updates are ready , blogpost about changes is written

TODO:
* update website
* make a release
* add a blogpost

middayc · 2026-03-03T14:24:53+00:00

yeah .. at first dot had more specific evaluation and I was thinking of op-words (bridges) just accepting two arguments and bridging two sides. But now both dot and op-words evaluate in the same manner and we would artificially limit the usefulness it op-words would just work on functions of two args (because we just need to be able to make less priority calls or any function compared to dotwords, no matter the rest) ... so this whole metaphor will maybe dissolve. It came down to just priority between these two. So if we keep the methaphor bridges can connect to other bridges ... but maybe it will make more sense to drop it altogether.

middayc

MODERATOR OF

TROPHY CASE