I disagree. I think the commit description should be "stop the engine wear", not "change the oil". I much prefer commit messages describing why you did the changes, because the explanation of what you did is already there - the code diff itself.
I've been thinking of making something like this for myself for quite a while now, glad I'm not the only one who had the idea and someone actually did it before I got to it
Why is DigiD even a product that needs constant maintenance? From my experience using it it's just a pretty simple authentication/data sharing system. Every oauth provider has something similar. Why is it a whole separate product that is owned by some company?
Any network service with 24x7 availability and millions of users requires constant maintenance. Hardware has some lifetime and needs to be maintained and replaced. OS needs patching. Dependencies need security updates and, time to time, migrations to next major LTS update. Sometimes new requirements come from regulatory, that need development of new features. The skill set needs to be maintained. Support requests need to be served. Law enforcement may ask for some data.
Add to this hard digital sovereignty requirements: continuity of service must be guaranteed for decades. All this requires quite a special setup in which commercial entities are rather tolerated than welcomed, but they may still make more sense than a government agency so constrained by budget process that they cannot hire any decent engineer.
Of course, I understand why some maintenance is required. I just don't get why there is apparently a big maintenance burden over something that is usually a single small feature of a service
Traces and memory are text. A gigabyte of text is an insane amount. That is an equivalent of tens of millions of lines of code, or hundreds of millions of AI tokens.
They're different languages with different syntax and different features. Them using tge same VM doesn't really make them competing products, just like Java, Scala, and Clojure all use JVM and yet are all different languages
If I understand correctly that you think Elixir is not yet "convenient to use", I suggest you still give it a shot if you haven't. I'm generally a huge hater of dynamically typed languages, and I still love using Elixir.
Resolve was a much better experience for me than kdenlive. But you can easily try it out for yourself because most of it is completely free (in fact you probably won't ever need the paid features for what you do)
I mean, there is nothing wrong with state, per se, and yes, this Excel-ish paradigm is awesome.
Although: Most Excel power users have automatic calculations disabled. Why? They want to control when full calculations. If you know that you want to change three things, you can change three things (in the correct order, which you - fair enough - must know), then calculate the rest (F9 in Excel, recalc below in Jupyter if - fair enough - your notebook is in topological order).
In Pluto, you sort of rely on your calculations being quick.
For me, the worst part about Jupyter is not that the cells don't automatically recalculate (I can handle pressing recalc below), but that the output is affected by the order you run the cells in. With Jupyter, there are many situations where to re-run the cell you also have to first re-run all the cells above that one, and it doesn't tell you which ones. Automatic recalculation can be disabled even in reactive notebooks.
It's interesting, I'm not a big notebook user myself, but others (and myself rarely) often take advantage of that feature, because it allows you to e.g. get data from an instrument, but then continue exploring the data using different cells in different orders, e.g. trying different ways of analysing things, e.g. I can cell that gets the data a cell that runs a moving average and a cell that does analyses. When debugging the analysis I can choose if I want to run the moving average data or the normal data, just by choosing I run this or that preceding cell.
Once you take away this way of working, I might as well not work in a notebook at all (which admittedly is my default way of working anyway).
Yeah it is useful. However the problem arises when you share a notebook with someone and they just can’t get it to work either because you forgot to reorder cells or your output depended on some state from a cell you deleted thinking nothing depends on it. You need to restart the kernel and run the notebook all the way through to be sure. Pluto’s reactivity eliminates this issue altogether. It’s a readily reproducible artifact. The functionality you mention would be the default in Pluto btw. Something that reads a sensor will read it only when you run the cell and update all depenents.
It is interesting that they are paying attention to that, as the section on interactivity [1] brings "how to disable a cell" that would prevent its reactivity and anything that depends upon. With some careful placement, you can disable the automatic calculations. Another thing would be tuning the parameter for confirming before a long runtime. Set it to 50 ms, and only run "almost instant things".
reply