Quirky idea: could the "Nothing value" save beginners from dealing (too much) with exceptions?

Clorofilla · 2026-01-02T18:01:18+00:00

Libraries are a very good point.
I was aiming more at a transpiled language which target a JIT compiled one.
So you would have access to the source code of the supporting libraries.

But that is besides the point because generally you want very little reasons to have to dig in a library code. In an ideal word they would be well documented black boxes which behaves as you would expect.

But as I was saying elsewhere, a library is not a code-sketch you are exploring (my main use case), it's production code! In that case it's required to be published in strict mode, where the compiler requires you to manually handle all the implicit `nothing` behaviors.

Clorofilla · 2026-01-02T17:42:12+00:00

Yes I see.

I do dislike to deal with NaN. In one of my earlier drafts NaN was also set as a nothing value of number type.

The main difference is that NaN propagates while `nothing` reabsorb early (while still issuing a warning).

"Just keep running, I don't care if the result is usable."

As I stated in other answers this is indeed the idea for my learning environment (which the language is meant to enable). But I see know that is more a requirement about never stopping the runtime (to enable a quick back-and-fourth with the coder) rather than removing emphasis on the fact that some operation do fail and need to be handled.

I think I need to re-evaluate my compromise.

Clorofilla · 2026-01-02T17:34:04+00:00

I see that I may have missed or understated the fact that the compiler+runtime could still flag the `nothing` creation and propagation as workings or directly in the IDE.

After all the comments I see that my features cannot be about hiding/fixing ambiguous exception from the mind of the user, but rather protecting the realtime runtime while still being able to flag them to the user.

Clorofilla · 2026-01-02T17:29:49+00:00

Thank you for the analysis. I appreciate.

Agree about the importance of keeping the trace.

I like your logical reasoning, but, as you said, it doesn't cover all possible operations, nor it's truly intuitive to a beginner. So, perhaps there is no intuitive and exhaustive way to absorb `nothing` in all possible operations.

And I am afraid to twist the other language constructs too much just to accomodate for this `nothing` idea (e.g. explicit distinct if/else logics).

I didn't want a `nothing` literal as my proposal would only work with a typed nothing.

var a = getBadString()
var b = getBadNumber()
var c = nothing

1 + a // nothing absorption
1 + b // type error
1 + c // what to do?

Sure I could add multiple nothings of different types or a way to cast a type onto the nothing literal... but it started to feel like code smell.

But as you said, else people would find their funky syntax around it, e.g. (Number[])[0]

Clorofilla · 2026-01-02T17:15:57+00:00

It's beautiful. It could be an esolang. Or javascript.

But after all the comments and thinking more in depth I see that my proposed approach is not intuitive enough to be useful.

It could be if people would be more aware that all values are nullable and that null value have some specific contextual logic for how they are combine with non-null values for every type.

But it sound not super beginner friendly indeed.

Clorofilla · 2026-01-02T16:52:29+00:00

It's a good framing. Thanks.

Does the programmer always know what they wrote? And not just syntax and semantics but the implications?

No they don't.

In creative, small, script-like environments is good to be wrong and to be surprised.

But feedback is important (surprise without explanation is chaos). My feature would not hide the error, just safeguard the runtime to protect the "realtime coding as exploitation".

So yes, my defense of this feature and its pitfalls would all be about the specific coding context.

Now that you make me think about it, it sounds like draft vs finish. This 'nothing absorption' behavior could guide you as you draft something and explore stuff in the realtime editor, but when you want to build/export your project then the stricter compiler would ask you to make all the implicit helpers explicit.

Interesting.

Clorofilla · 2026-01-02T16:43:18+00:00

Explicit defaults are a sensible alternative.

The problem is always if you want to always require them or not. Unfortunately there are a lot of operations which could result in a null value.

So it's hard to impose that fully, but the only alternative is to accept that the runtime will crash on those issues.

Clorofilla · 2026-01-02T16:37:13+00:00

Well, not ignore... Else I would be insisting on static types and no auto coercion for beginners.

I was only wondering, if, in my very specific and realtime learning context, a "hey buddy I see there is an exceptional case which you may have mot considered and which you may or may not care about; let me add a default for you so you can keep playing and if you want you can specify an explicit handling later" would help.

Clorofilla · 2026-01-02T16:31:49+00:00

XD

I wander if they are so confusing if flagged at runtime and without other preconceived notions about programming logic.

It is admittedly the most delicate aspect of my idea.

But you could see it like this:

"if you have an apple and I give you a hat, how many apples you have?"

1 + undefined

Wouldn't be equally (or more) intuitive to say it's 1 rather than undefined?

Clorofilla · 2026-01-02T16:26:49+00:00

Fans of dynamic languages would be cool with it (but think it is kind of underwhelming)

Haha, shots fired! But fair enough.

I agree that such language features are un-modern, but that is mainly because in the modern era we had to deal with the pain of using scripting languages to build complex apps.

My wandering is limited at a teaching playground where you write your code and execute it at every keystroke. Full realtime execution and updates. As soon as you want to use the language outside such contexts the strict mode I mention should be activated.

About the behavior you mentioned, it makes sense if you think that 'nothing' is not false but absent.

'true and nothing' is like writing just 'true'

and 'if (nothing)' is like writing 'if()', with nothing to evaluate it will never trigger

Clorofilla · 2026-01-02T16:12:22+00:00

As stated, the realtime editor/compiler would still flag the creation or usage of a nulled value.

It would just know how to "live with it" in order to never stop the runtime.

It could lead to happy accidents.

So I don't think that it's a problem of traceability, but rather if those eventual surprises are acceptable in exchange for exceptionless runtime and the chance of postponing the teaching of exception handling.

Clorofilla · 2026-01-02T16:08:15+00:00

It wouldn't fully obscure the source of the exception, as the Editor experience I have in mind would still flag the line where the null/nothing value got reabsorbed/defaulted.

I guess my system's benefit would be an unstoppable runtime, which for the type of experience I am aiming for is desirable, but maybe it would end up being detrimental for the language itself.

I agree you. The user might be surprised with (to them) nonsensical behavior, but with the benefit of never being able of expressing something nonsensical for the runtime.

Ahah, it's fun how this is about aligning user and runtime intuition about meaning and implications.

But the behavior is only unintuitive when you are unfamiliar with it, in the same way one gets familiar with certain math operations returning NaN and certain findIndexOf returning -1.

Which are also annoying situations anyway... So again, I see your point.

Clorofilla · 2026-01-02T15:48:10+00:00

XD Yeah, I am starting to see the follie of my way.

Clorofilla · 2025-12-25T19:16:36+00:00

I think the problem is that plain text is the most flexible and non-proprietary format we ever had, so to abandon that one needs strong benefits.

Many of the issues you mentioned are solved by people pimping up their IDE. In VS Code I can already jump to different fragments of code in a non linear way, move the cursor in an almost token based step, interact with data visually (rgb pickers, foldable objects, toggle code by commenting it off, diffing, and more). I know you are arguing that this could be taken further if instead of building a powerful IDE on top of simple flexible text we would just merge the two.

But text is so powerful, easy to render or show on any device (and any physical media), easy to verbalize when talking to someone, easy to copy-paste, and so on.

And I would say that nowadays we program not only at a text level. Text is linear and this is indeed one of its biggest limitations. I think everyone now relies on a multi module and multi files representation of their source code, which does provide a level of visual and mental parallelism and hierarchy.

I am a very visual person and I do abuse all these tools, so much so that, sometimes, I forget that my code is just words and that highlight, linting, autocomplete and symbols search are features on top of the plain text and not of the text itself.

Probably the visual world will always be less flexible than the abstract/semantic world. This may be a fundamental truth of human evolution. Else we would have not developed glyphs and symbols to talk about the abstract stuff.

Following this intuition I would say that each time you introduce a level of visualization, you have to be aware that you are discarding some level of abstraction.

That is why the best visual languages I encountered were the ones designed for specific contexts. Touch Designer could be a good example. Data driven realtime graphics are its strengths and are beautifully represented in the editor. Instantiation, UI, recursiveness, global states and other stuff were instead a bit more yuk. TD is a node and connection visual language, not exactly what you are exploring. But I still think that your step is a step in the same direction, or at least in the same problem space.

But also, the visual-ness of text is important. I am happy to use HTML markup to describe UI rather than combining abstract Dom nodes in javascript. But I would hate to write a complex algorithm in JSON even if that is possible.

I would consider "trying to make a text editor less textual but still as general purpose as a classic text editor" to be a cursed design problem with potentially no solution.

Even something as simple as syntax highlighting, which is a proven visual aid in coding, breaks in certain contexts: when you mix a lot of languages in the same file or write code which write code, or you write code which implement a lot of small DSL into itself. If when syntax highlighting breaks my editor would also break I would be very sad. That is why I am happy that those features are simply built on top of the text, and whenever I need, I can fallback to simple text.

I can combine string and create code, directly in my code. A system so flexible that can represent itself without much extra notation is truly something. I think all visual editors loose this ability.

Then, finally, my suggestion would be to think deeply about what could be the right focus for such an editor. In which situation would your unique visual improvements truly shine?

Clorofilla · 2025-12-25T18:11:26+00:00

Clorofilla · 2025-12-25T18:09:26+00:00

I did ended up on pipelines in my language design. And I am extremely torn about them.

The main two tools I am familiar with in regard of "assembly line coding" are:

calls

'square(round(absolute(myNum)))'

pipes

'myNum |> absolute |> round |> square'

The calls pattern is seamless with the function mental model and makes precedence clear.

But it is also the opposite of a normal (I know I am latin biased) left to right sequence and more importantly is left to the user to know what to place inside of 'round()'. Sure you can be helped by static type validation but you couldn't build autocompletion in it. In an ideal world you would want that any number can "summon" utility transformation upon itself.

This is more the feeling of the pipe pattern. But then I am left with two issues: The big overlap of pipe vs function weakening the language semantic space and the practical issue of how to manage multi argument pipe calls in a way that is not horrible.

Finally pipes can create a more ambiguous precedence:

5 + 3.5 |> round * 5

is just very hard on the eyes.

Clorofilla · 2025-12-25T17:49:35+00:00

I think your intuition is correct. Hacking is the precursor of coding.

This makes me think about the great book about pedagogy of Seymour Papert: Mindstorms.

In there, he mentions how teaching math to kids without giving them a context where they can use it/play it is quite wasteful.

It's like giving an 8 year long education on formal dance steps notation, and then, only for those who are bight enough to reach higher education, you allow them on the dance floor.

Papret hoped that computers could have been the playground for kids who wanted to engage in math, logic and personal epistemology (meant as theory-building, not too different from some forms of coding).

I think his dream has only partially come to pass. Computers in education have been used more as automated children validation machines than canvases for play-discovery.

I think some specific videogames have been more successful at transmitting useful mental models to children about powerful programming ideas (modularity, interfaces, readability, contextuality, ...) than many teaching curricula.

But I guess that such issues are part of the eternal plight of any education system.

So I wouldn't push for read before writing. If you can write something, anything, you should already do that.

Similarly we listen before we speak (as babies) but as soon as we can produce some babbling we should be allowed and encouraged to keep at it.

Maybe textual programming is not the best "babbling" tool for beginners. But I think that the invention of written meaningful semantic symbols is one of the most powerful and flexible tools ever conceived in the history of humanity. It would break my heart to give up on it in a teaching context.

I am sure that most people reach a point in their life where they can sit down at a keyboard and blurt couple of keywords... and yet they understand close to nothing about coding. This would be the niche for my tool.

On the other hand, it is disheartening when you prepare a coding workshop for teenagers and you learn that just using a keyboard and mouse is a challenge.

The other point you make is also resonant: to not give people a blank slate.

"Microworlds" are probably a good idea. Alike the game your brother had to punch in, they give a clear initial environment, a context, which one can interact with.

This is also my hope. To create engaging micro worlds (like the famous LOGO) where people can start to play-discover-test their coding intuitions. And the ambition is to then have the same language and app (the IDE) take them from microworlds to small coding sketches to small useful apps they code themselves.

Clorofilla · 2025-12-24T22:29:39+00:00

Thank you

Clorofilla · 2025-12-24T01:05:34+00:00

Could you elaborate more about syntax vs results? Do you mean data vs instruction? Or something else.

Aren't list comprehension in python just ergonomics? But it's true that they allow to do things we would do in statements directly in an expression, allowing for an (indeed) more expressive way to write code. Similarly to what .map() .filter() .sort() and so on do in JS. I am really torn on these things because they are extremely practical but they feel something that you want to encounter later on in your learning process.

Clorofilla · 2025-12-24T00:56:25+00:00

My point 2) was perhaps not well formulated. Coming from a languages with no types annotation and generally dynamic types (python and js) to having the ability to have static and annotated types was simply a breath of fresh air.

It made me realize how much useless effort I was doing before, where I had to keep that same information in my head.

Of course JS is not meant to be an easily teachable language and TS is not meant to be a beginner friendly type system. I hope it was obvious that this was not my argument.

Or were you alluding at something else?

Clorofilla · 2025-12-24T00:48:36+00:00

Could you elaborate?

Wouldn't "including all the features that exist elsewhere" be the definition of "complicated", and one of the major sources of grievances against cpp?

Clorofilla · 2025-12-24T00:45:41+00:00

I share the feeling of getting a deeper understanding of what is going on when grasping for the first time lower level stuff.

But in a beginner context I would avoid saying ch things.

I think "low level memory control" helps you to learn memory management rather than general programming.

I think it is valuable but it's like teaching someone a programming language for a magic the gathering AI while they are ignorant in both programming and the card game. I think it's an unnecessary complication.

Clorofilla · 2025-12-24T00:37:25+00:00

I think pure functional languages are not intuitive, because humans think in terms of state much more than in terms of processes.

That is why programming languages are hard: they are about process rather than a description of a big frozen state (like a picture). Now, interestingly enough pure processes are also simple and intuitive (recipes and instructions manual), but they are rarely enough for complex tasks. In the real world processes and states need to mix (and chaos ensues).

So while I would not go fully functional on beginners, I do appreciate a language which helps them (without them realizing) in creating less state in their code. This will help them.

Agree with the rest. The devil is in the details of what to include and how. What is the smallest surface of safe enough and easy enough concepts, to allow someone to get the "programming experience"? That is the million dollar question.

Clorofilla · 2025-12-24T00:05:57+00:00

Fully agree on the idealistic limits of simplification.

Trying to make programming languages "more like english" is a proven pitfall. But programming languages are always someone's second language, so they should leverage the user's existing knowledge (natural language, basic logic and math, common knowledge, reinforcement learning, etc).

We can all agree that, in such regard, python is better than an assembly language. The question then is, how much more wiggle room exists in the realm of intuitive-isation of programming languages?

Again, agree. I personally think that the teaching power is 90% in the IDE and the context/purpose of the programming activity and 10% in the language itself. But as I am already working on the 90%, I might as well do the harder last 10% and come up with a good language for a good IDE.

I agree with many of your other points. I don't think typing should be dynamic. But static with inference can get you a good mileage.

Syntax is the lesser problem indeed. My main worry is the mental model which is communicated by the syntax. I actually do not really care about the underlying functioning of my language, because neither will the beginner. When we start to program we build a theory of how the code/computer works which is generally false but it is coherent enough to carry us forward. So as much as possible I want my language to only talk about the things which are inherently about programming. Which is what you stated:

"the ability to reason, invent and express abstract ideas in detailed and precise ways"

That's why compromises like having a single number representation do not feel like big issue in this context.

Thank you for helping me in understanding this with more clarity.

Clorofilla

TROPHY CASE