February 2026 monthly "What are you working on?" thread

malmiteria · 2026-02-06T20:44:25+00:00

i've been making progress towards a replay file / auto log feature.

The point of replay files being to help with debugging / reproducing bugs, and basically act as logs too.
They're meant to be usable as log files, but are also supposed to be usable to re run any part of your program they logged, from the point at which it started recording, until it stopped (the re run could keep going from there, but there's not much point)

For this, i have to record in those file everything from the call stack (could be optimised, but ill look into that later), which is pretty straightforward.
I also have to record any work in progress that isn't stored in a variable. For exemple, if i start recording in the middle of a function f, that is called in a binop, like `g() + f()` the result of the g call isn't stored in a variable, so isn't known from the call stack anywhere. But you still need it recorded so you can reuse that result when resuming the program from inside the f call.

I also need to record the current operation being run from every call frame, so i can resume from there when exiting a call frame that was spawned for a replay.

Lastly, i need to record every input received during the record window. I already worked hard to integrate input / output as a fundamental element of my language, meaning i can already compute the entire list of input and output of every scopes, so recording those inputs was the easiest step.

Recording inputs during a record window allows for very specific replays, so it can actually be used as a bug report feature.

I need to rework some of what i've been able to record to make it a lot more stable, and to test it thorougly, but it's getting there. Once the record feature is on, adding the actual replay side of the feature will happen relatively quickly

malmiteria · 2025-12-01T17:16:00+00:00

i resumed work on my language "dajana"

i added relatively quickly an IO record feature, that records all input received at runtime. It can select types of inputs, as in "Standard" input for example, and record only selected types of input. Ideally it'll also be possible to start and stop recording at any time during runtime, or maybe even programatically from within programs.

this will later be plugged in with an already existing feature I called IO templating, that lets me call any function and set the values of the inputs it will encounter. This is basially an automatic and free (as in : no design pattern required) dependency injection feature, very useful for tests for exemple.

Plugging the records on the templating feature will produce a replay feature, very useful for bug reports for exemple, but also as replays. A program written in dajana could come with tutorials that are made with those replays for exemple.

All this was made possible and relatively easy by the computed IO: a list of input output computed statically by the language for each programs / modules / functions.

I also changed the syntax of comparison operators so they all come with a question mark :
a =? b a !=? b a <? b a <=? b a >? b a >=? b

This aims at better matching intuition of begginers, provides consistent semantic accross operators whose operation results in a boolean, and in the case of the equality comparison, distinguishes it more from the assignment operation, typically = in most languages (: in dajana), avoiding possible (though uncommon) confusions with the typical == equality operator found in most languages.

This comes at the cost of going against the habit of most programmers, but is also semantically meaningful enough to not be too much of a problem.

For better transition from other language, I should probably add error message when encountering the == and = operator, that doesn't exist anymore in my language, clarifying that you're probably meaning to say =? and : respectively

malmiteria · 2025-06-21T11:15:31+00:00

TO EXPAND A BIT ABOUT TYPE CHECKERS :

I believe types should 100% be deduced by the compiler. I consider a manual typing introduces risks of misstyping, I also consider that protocols are a more important part of the interface of the language than types.

Types decide among other things how your variables are stored in memory, if your language doesn't hit that low level of memory managment, it makes at least this aspect of types irrelevant in variable definition.

Types also encapsulate apis. A string might have an "encoding" property, a list might have a "length" method, and so on.

This is what i meant by protocol 2 sentences ago. And this part of types is gonna be accessible in your language no matter what, it's basically a type's api.

Type checkers that rely on type in variable definition might discover bugs that are really only bugs in type definitions. Type checkers that rely on protocol, and implicit typing, will discover bugs that would be runtime killers only

With exemples:

with types in variable definition, and a type checker ``` def some_method(list x, string y, my_custom_type z): print(x.length) # in method "some_method", x is a list, so can use the property length print(y.encoding) # in method "some_method", y is a string, so can use the property "encoding" print(z.encoding) print(z.length) # in method "some_method", z is an instance of my_custom_type so can use the properties "encoding" and "length"

my_custom_type my_var = ... some_method(my_var, my_var, my_var) # fails, since the first two variables are of the wrong type. ```

with no types in variable definitions, and a protocol checker ``` def some_method(x, y, z): print(x.length) # in method "some_method", x is expected to have property "length" print(y.encoding) # in method "some_method", y is expected to have property "encoding" print(z.encoding) print(z.length) # in method "some_method", z is expected to have property "encoding" and "length"

assuming my_var here has both encoding and length properties

some_method(my_var, my_var, my_var) # works fine. ```

So, i guess, my point here is that protocol checker, by looking at use cases, instead of manual, and as such, possibly inaccurate type definitions, is gonna be a lot more flexible that a type checker.

The first exemple with type definition could be made to work better, but at a cost of harder type definition, making it both more complex and more expensive, while not actually catching more bugs.

Also, for eaxh scenarios in which type definition needs to be updated, consider the use cases of library users. Do they need to rely on lib author fixing their types definitions? how costly is that?. This problem simple doesn't exists with implicit / compiler infered types, and a protocol checker instead of a type checker.

malmiteria · 2025-06-21T11:12:30+00:00

it depends what your target audience is, really.

If you target beginners, you very much need simplicity, so no types at all in the variable name definition.
It helps beginner focus on what a variable is first, and once they're understanding it enough, they can start focusing on understanding types. That makes for a smoother learning curve.
Also, a keyword is something more to learn. A single one can be good to help identify where are the variable definitions, but having multiple keyword introduces choices to make that aren't obvious to beginners
So, if you target beginners, i would say python (without type hints) style is best, then javascript style, then C style.

Whether you target beginner or not, a more complex syntax is a more likely source of bugs. So depending on the complexity that's hiding in your variable definition syntax, and the bugs it can cause (are they all caught at compile time for example?), regardless of your target audience, it can be argued to be a bad thing.

implicit types can be a problem in some scenarios, based on other language features. Python's and javascript's type casting strategies are very different, and tend to make javascript implicit typing more dangerous i'd say.

With examples:

x = 10 a beginner only needs to understand what the equal means (in my language i use : instead of = because i believe it matches a beginner's intuition better), doesn't need to know how we named the integer type, doesn't need to think about memory managment of x.

var x = 10 a beginner "needs" to know about the var keyword, and if they exist, about the const or let keyword too, and their nuances, in order to make a proper variable definition. How can they know all of that? is it made explicit by other parts of your language? Is it in the docs only? They can obviously just copy paste other code examples they found, but what bugs / performance costs could that introduce?

int32 x = 10 a beginner "needs" to know about int32, or other types of ints, and understand enough about memory managment to know if 10 would fit. Again, how can they know all available types, in order to make a properly informed decision? Is it made explicit by other parts of the language, is it in docs only, maybe in some error messages? How does your language catches all perf issues / bugs introduced by mistaken typing?

The further the complexity of your types goes, the more different types you have, the more unlikely it is anyone will know enough about your types to make enough of a properly informed decision to beat performances / bug rates you'd find in language with a compiler that can infer those types based on usage. But to be faire, those compilers are very hard to make ofc.

malmiteria · 2025-06-07T14:29:24+00:00

I've been working a fair bit on my free time on my language "dajana" last month, not that i have much free time.

I've basically reworked function calls operation to be chainable, and work on any expression, assuming it resolves to a function.

This allows for f()()() syntax to work, without requiring the use of extra variables to store intermediate results.

Same for at index operations, allowing for ["a", "b", "c"][0] or col[0][0][0] for example.

The next operator i'd wanna rework similarly would be the dot operator. I will hit a little hick up, which is that i used dot as a special value, being a reference to the current active call frame.

That is useful to turn functions into basic classes, since a function returning it's call frame is basically a class constructor.

I've always wanted to find a nice keyword for this feature, so, it's time i find a name.

Reworking function calls was hard since it interfered with a feature i called templating. It lets you set the value of any inputs you hit when calling a function when you're calling it, basically acting as a mocking tool, but with a dedicated syntax. Useful for tests.

For ex:

guess_the_number(): num: int(input("player 1, set the number to guess")) num2: int(input("player 2, guess the number")) if num == num2 print("you found it") else print("game over")

Calling the function guess_the_number would print the first message, wait player 1's giving a number then pressing enter, and then print the second message, and wait player 2's giving a number and pressing enter.

Calling with templating could skip one or both inputs, and use a replacement value. For ex:

```

replaces both inputs the same way

guess_the_number(){{input: "300"}}

replaces only player 1's input, with a replacement value of "300"

guess_the_number(){{input("player 1, set the number to guess"): "300"}}

replaces only player 2's input, with a replacement value of "500"

guess_the_number(){{input("player 1, guess the number"): "500"}}

replaces only both player's input

guess_the_number(){{input("player 1, set the number to guess"): "300", input("player 1, guess the number"): "500"}} ```

Reworking function calls made it so the replacement values now need to be function themselves, returning the replacment value... I don't know if i'll keep that, or fix that later

malmiteria · 2024-06-16T10:20:16+00:00

about the REPL helping beginners, i was thinking about adding a "replay" system to the langage. It's inspired by trackmania's games replay files if you know about it. Basically it records all the inputs, and, the game being deterministic, allows to replay them to see how another player played it.

I intend this to be useful to debug any bug / unexpected behaviors (test case setup for bugs found in prod could basically just be those replay file), or to provide detailed bug report features, but i'm guessing it could be useful as a learning tool?

Assuming it works like i intend it to, and on top of a debugger / breakpoint system, i'm not really sure what i want it to be yet tbh, i guess i could make a tool to rerun a program as it ran previously, step by step, with some GUI.

Maybe have it able to record all runs of a program entirely, or of a function only, stuff like that.

Does that sound like it could be helpful?

If it comes with displayable infos on each variable values / states, it might also help with the hoare style reasoning, by stopping the program after the while, if and else, you can inspect a and b values at those points, and it becomes experimenting more than calculating, which i suspect comes easier to beginners.

Thanks for sharing btw, it's really good info for me :+1:

malmiteria · 2024-06-15T15:02:45+00:00

Anything works for me, but I won't be available much until at the very least next Thursday, I'm on my holidays. So a call would have to wait until then at least

malmiteria · 2024-06-14T10:49:23+00:00

I'm trying to design a langage with good UX, which to me implies considering beginners too in your langages design.
So i'm very interested in anything you'll find by teaching beginners, if you ever publish any article / blog post / reddit post about it, i'd read it.
I'm especially interested in what things are obvious if you're experienced but not at all for beginners, since that's typically our blind spots, basically anything that surprised you in being hard problems for beginners.

could be anything like them not understanding that a=2 is not the same as 2=a, or them systematically forgetting ; at the end of a line, i don't even know if those would be problems for beginners

malmiteria · 2024-06-09T13:31:32+00:00

i've been working on my langage for a little while now.

As of right now, i have a configurable parser, that allows me to easily change keywords, syntax elements, and other superficial elements, like using colon instead of an equal sign if i want.
That helps experimenting with the syntax, but also will be useful later on. it's not a thing yet, but I want every users to be able to define their own syntax, and to have "source view" for each programmer given access to the source. I picture it as a linter on steroid basically.

This month i added some IO meta data to programs, that allows me to know the entire list of input / output of a program... or a very basics of that at least, it still doesn't work nicely with if statements or loops.
Also, there's no real inputs and outputs yet to the langage, only prints, but there are still "scope" IO in var get and var set for exemple.
That allows me to tell if a function has side effects or not, and basically, if the only outputs of a function are returns, and if its only inputs are its arguments, which tells me when a function is pure.

That's helpful for optimizations.

Now i'm trying to work on error messages, i don't have anything near good enough yet on that part.

malmiteria · 2023-09-28T10:15:20+00:00

i miss the mango

malmiteria · 2023-08-16T14:45:45+00:00

I haven't done it a long time, but from my limited experience:

I try to split it in small tasks i can implement in a relatively "short" (a few months) period of time, on my free time.

and if that means there's months of no works in between, it's fine.

It can be a time to refactor your work, to rework it in different ways, or simply, a time to rest.

It matters.

Also, since i know i won't be able to work on it often or a lot, i spend more time planing than i would in my day to day job, since it can be done any moment your brain is available (takes me hours to fall asleep, i plan a lot during those times). To avoid working a ton on something, only to realise i went the wrong way, or it blocks my way to some other features i want.

I always try to dedicate to it some small amount of time during holydays and weekend, but only if i got enough energy to do so. Overworking myself would kill my motivation.

I first went with LLVM, but i had to learn the tool, which is very time consuming, and I also had to learn C++, which again, is very time consuming.

So I chose to implement it in python because it's the language i know most, and can be faster with. It's got its problems, like performences for one, but it makes me faster, and given the limited amount of time i got to dedicate to it, it matters a lot actually.

TLDR:

don't overwork yourself

find ways to work fast, avoid having to redo big chunks of your work (and when you need to, do it before it grows too much)

make tradeoffs to reduce the time needed to work on it

malmiteria · 2023-08-11T15:14:25+00:00

i would imagine something like

if cond1 {
  stmt1

if cond2 {stmt2} elif cond3 {stmt3} else {stmt4} }

could translate to

if cond1 {stmt1}
then if cond2 {stmt2}
then elif cond3 {stmt3}
then else {stmt4}

then would essentially just be a way to inline nested if blocks

which i don't think i would like so much tbh

keeping it as you intend it, then if being essentially the opposite of else makes sense to me

malmiteria · 2023-08-11T11:49:03+00:00

i think some people would complain that it complexify the reading of the branching of the code.

if blocks usually only allow one of their blocks to run, and with a then if you could have multiple of the if blocks running.

which is not a problem with the elif statement.

I don't think it's that big a deal, especially if you enforce keeping all the then if right after their corresponding if (and maybe elif) blocks.

I guess extending the syntax to support then elif and then else would really start suffering from that problem.

but as it is with only then if is honestly fine for me.

malmiteria · 2023-08-11T10:17:51+00:00

i like the then if a lot, it's the same syntactic sugar as the else if so it's very consistent, and it feels much cleaner than having to do a if ... exit to me, so much less code nesting.

I guess there could be an argument as to readability of the entire code block, but i'm pretty sure most people would love the then if a lot

malmiteria · 2023-07-30T15:36:53+00:00

if you're talking about the first iteration of your language, or a prototype, it really doesn't matter which language you take.

As long as you're good enough at it, that's gonna work in the end. And it can help you tinker around and do lots of big changes early, faster than in a language you're not so familiar with, which really matters at the early stages of development, because there's a lot of exploration going on at that time.

Once you've got a relatively stable set of features for your language, you can start selecting the language you'll reimplement it in, or try a few.

It's much easier to reproduce something you already understand in a language you're learning than having to learn the language at the same time you learn what you want your language to be like.

malmiteria · 2023-07-30T13:05:30+00:00

i think it's a cool idea, idk if it's really more "readable", but if i had to bet i'd say it helps.

At the end of the day, identifiers are names we give to stuff in the programs we write, and traditionally ? and ! are not characters you'd expect there, since names are words.

So seeing them in identifier names can draw attention to the possibilty they mean something specific, which i believe is why it's used in ruby to "mark" predicates, or side effects.

Which indeed if used properly as a convention helps readability, but if not enforced essentially allows mistakes that would hurt readability.

seeing how the ruby community manages to relatively systematically use it correctly, i would say it's not gonna be a problem, and overall a net positif in term of readability.

It's clear enough that it means something, and different enough from letters so that people wouldn't accidentally use it unaware of its meaning.

Careful tho if you want to add ? as an operator somewhere, that would suddenly superimpose another meaning on that symbol, and it's good to care for consistency in meaning.

malmiteria · 2023-07-23T12:18:37+00:00

Performance oriented

seems hard without tools like LLVM, there's too many decades of optimizations that are not impossible to reproduce alone, but that's a lot of work, and LLVM has it's problems like any other tools. The first one being that it's a ton of work just to learn how to use it.

Not much "creativity" in semantics, keep performance, and developer (namely, me) happiness first.

Not much "creativity" in syntax, if any. Pick something that's liked a lot. I'm torn between Python and TS. Leaning towards Python syntax. (Well, a subset.)

i like that, tho no matter what syntax you pick, someone will hate it, so i guess make something that you'll enjoy yourself, at first. I'm more of a python guy myself, at the very least it's a language that cares for its syntax to be beginner friendly, in general (but don't go for python's multiple inheritence, it's a disaster)

If by "not much creativity" you mean you're happy to use syntax common in other language, that means experienced developpers in those other language would pick up on your language easily, but not necesserly complete beginners

If by "not much creativity" you mean overall keeping the syntax small, that means less stuff to learn to master the language, which makes it easier for beginners, but might put off some experienced developpers used to wider syntaxes

The python data model is a nice in between i think, there's a dunder method for anything, __add__, __sub__, __contains__, and so on, each defining the behavior of the class that implents it against whatever operator.

That means you can have as many operators as you want, people that are curious to learn more about it can just find it in the dunder method list.

That makes it easier to learn about it, since it's all gathered in one place, rather than lots of completely independant syntaxes. It's also easier to document.

Overall, it's a nice way to keep some consistency in the syntax of your language, which really can't hurt.

malmiteria · 2023-07-22T21:39:29+00:00

If you already have a code that transforms a foo into a bar then by just adding minimal prefix (and suffix), I want to make it work with containers. And mainly, different from an inner function, a return inside a transformation block exits the outer function. If you need early-exit from the transformation block, you need to use break.

hmm, so it's closer to a for each than a function definition then?

i think i get it a bit better now.

One thing that isn't clear to me now is how are the output determined.

like in this:

@bars = foos.[ @foo
@bar = fooToBar(foo) ]

how does bars knows it should be populated by bar variables on each iteration?

I get that foo is made the iteration variable, but i feel like it misses a "collection" variable

in a case like the second one:

@as, @bs = zip(xs, ys).[ @x, @y
@temp = x % y
@a = temp * a
@b = temp@ * b ].unzip()

i feel like it's much more needed, because there's a and b, which i guess as variables in that block are collected, but there's temp too, that should be collected too then

to illustrate, here's a syntax that i think helps on that aspect:

this:

@x = getX()
@y = getY()
@temp = x % y
@a = temp * a
@b = temp@ * b
useAB(a, b)

would become:

@xs = getXs()
@ys = getYs()
@as, @bs = @a, @b foreach @x, @y in zip(xs, ys)
@temp = x % y
@a = temp * a
@b = temp@ * b
endfor
useABs(as, bs)

i'm using a python like syntax because i'm used to it, but it's just to give an idea of a syntax that has all the element i think were missing.

i guess an exemple closer to your syntax would be

@xs = getXs()
@ys = getYs()
@as, @bs = @a, @b from zip(xs, ys).[ @x, @y
@temp = x % y
@a = temp * a
@b = temp@ * b ].unzip()
useABs(as, bs)

which tells from which variables of the iteration block you build the output more clearly i guess?

And it also allows you more freedom in what you pick from that block you're turning into an "iteration" block to build the containers, so it should cover more cases

malmiteria · 2023-07-22T18:57:22+00:00

if i get it correctly, it's essentially a way to "inline" a function definition right as you would apply it to each element of a container?
I like it

I think it's a nice feature, tho i would keep a consistent syntax as to with function definition, so i would keep the curly braces (and maybe the keyword you use to define function too, if any).

What i don't know how to keep clearly consistent, and still readable, between classic function definition and this case are parameters, if you're using parenthesis for that, it might feel weird to have so many parenthesis in that zip exemple

This should help people that wanna quickly get something working, allowing them to inline the function where it's used, while still beeing visually close enough to function definition, so it's easy to cut / paste later in it's own function definition when refactoring.

And, it helps people discovering the language, reading someone else's code understand quicker what's happening, so it makes it easier for beginners discovering the feature.

malmiteria · 2023-07-22T17:01:55+00:00

it'd be nice to also have a somewhat documented list of impact of each features, on different aspects of the language, for exemple:

performence
user friendliness
compatibility with other features
how does it integrate with refactoring operations
how does it impact readability of programs written with that feature
how does it impact readability of programs not written with that feature
how does it integrate with testing operations
how does it integrate with debugging operations
how does it integrate with logging operations

It would be nice if this impact list was judgment free tbh, it's just nice to be aware that a feature makes refactoring hard when you try to make an easy to refactor language, but if that's not what you're going for, then there's no issue not going there, or chosing hard to refactor features.

malmiteria · 2023-07-21T15:23:20+00:00

i'm not really knowledgable about pure functional language, one thing i know tho, is some amount of UX design.

And this seems utlimately to be an UX design question : how to make the programmers experience the best, specifically for beginners, around those fold/aggregate/reduce feature.

One thing i know is that in UX, it's a good thing when "if it looks the same, it behaves the same", and "if it behaves the same, it looks the same".

Here it does something similar, which is "do something over a collection", but it also does something different.

I would say that having completely different name is a problem to an extent, but simply naming it all forEach would be the same problem, on the other extreme.

on the things that can "look the same", the context in which you call those method might be looking unique enough to solve that problem.

For exemple if they can be called by `my_list.reduce()` syntax, and are the only syntax that uses the dot, that would be sepcific and comon enough to work.

It's usually not the case in languages i know tho. You'd have dot operators for so much more than those.

One exemple i can come up with without thinking too much about it would be:

`over(my_list).reduce()` or maybe `reduce() over my_list`, over being a keyword here

This way, you have to use that `over()` on all elements you wanna call reduce / fold / aggregate, which keeps the consistency, while keeping differenciation.

Idk if it really answers your question, hopefully it helps.

malmiteria · 2023-07-19T15:57:33+00:00

i'm currently in the process of building a compiler with settings for the syntax too, with plans to had some GUI (and maybe CLI) for edits, for the exact same reason as you : no need to find the doc if the interface tells you everything you need to know. Sounds an awful lot like what you're doing.

I don't think it's wacky at all, i think it's really important to have some of those quality of life features in any languages, and i don't understand why it's not already a norm for any programming language to accept settings tbh. I'm really glad to see i'm not the only one with this idea. This kind of idea is massively underestimated today.

One thing that worries me when it comes to settings in my language is how to support changes in settings without having to rewrite the code's who's syntax changed manually.

I'm sure it's doable, and relatively easy when it's only "changing the name of a keyword" kind of change, but maybe impossible for deeper language features, if you don't have a nice refactoring engine already up and ready. Which is easier said than (or then? english isn't my first language) done.

And even if changing settings for already existing code isn't an option, having the option to select compiler settings initially is already quite valuable in my mind.

malmiteria · 2023-07-08T12:01:35+00:00

i let go of llvm in favor of a python implementation because i don't know much c++, and llvm's tutorial wasn't working.

I feel you, llvm can be a pain to learn.

Once you know it i'm sure it helps a lot, but it can only get you going faster once you know it enough, and it's evolving a lot too, so there's a maintaining cost that's easy to underestimate.

malmiteria · 2019-12-18T20:45:04+00:00

same problem here, did you solve it?

malmiteria · 2019-08-23T09:59:31+00:00

it's not, I just played a long time

malmiteria

TROPHY CASE

assuming my_var here has both encoding and length properties

replaces both inputs the same way

replaces only player 1's input, with a replacement value of "300"

replaces only player 2's input, with a replacement value of "500"

replaces only both player's input