Legacy doesn't seem to mean what you are implying. I suggest typing the following prompt into any AI and debating it with the AI: "define legacy in terms of programming languages".
Zensical team here. Yes, there are very good reasons for that change. First and foremost, with MkDocs using YAML, and Material for MkDocs being the main entrypoint for many of our users, we got a lot of issues with users having trouble just getting the indentation of YAML right. Secondly, and this is even more problematic: Python Markdown allows the use of custom YAML tags[1], which translate to function references during parsing. This means that YAML parsing is tied to Python and thus not portable to other languages. It's also the reason why we currently need to go through Python to parse MkDocs configuration and render Markdown. TOML on the other hand doesn't have such magic, making it portable.
Thank you for your prompt response. Your explanation clarifies things much better than the brief description in the documentation. While I still prefer YAML over TOML, I understand your reasoning.
Well, it would necessitate a dedicated conversation. In my opinion, there are better languages and runtimes available today to create such solutions, such as Go and Rust, to name a couple of the most suitable ones.
I believe Java is no longer an appealing choice for these types of tools, but I still like the project and its development process.
So far I'm happy with the choice. The ecosystem is mature, the build tools (maven/gradle) are solid to build this more complicated project, JavaFX works well enough to realize cross-platform applications, and the performance with modern JIT compilation from GraalVM is good. Currently I'm not missing something important from the tech stack.
Next week, when JDK 24 is released for the general availability, I plan to immediately switch to that as there will be additional performance gains with Project Leyden's AOT compilation and Project Liliput's memory improvements. So I'm positive for the future.
Neither Go nor Rust have a GUI toolkit anywhere close to the capabilities of JavaFX, so in practice such an app would largely be written in JavaScript. If you want to use one language for your desktop app, be portable, and avoid the complexities that come with web development, Java is the best possible choice today (arguably the only choice other than maybe Qt).
I agree, today still better to use Docker that is more mature, Podman is half baked, lack of relevant features and moreover still very Red Hat centric, so a sort of lock-in.
Well that is not completely true: if you referred to the conditional aspect there is a way to execute/repeat and branching from specific section in a score conditioned by specific situation.
"Repeat with different endings": https://en.wikipedia.org/wiki/Repeat_sign
Don't forget the Dal Segno, for which you have the Dal Segno al Coda (on repeat, jump to the sign) and Dal Segno al Fine (on repeat, jump to the end) which are if/jump statements. There is also the reverse, Da Capo Al Segno (from the sign) which is a jump, versus Da Capo by itself (from the start again). The coda looks like a circle with a + through it, the segno a fancy S with dots, and the fine looks like a cartoon eye.
These are similar to repeats, except that they branch.
Also, there are other "commands" for technique, such as , for "pause and breathe," ties and slurs, rubato, and glissando for how you connect the notes, crescendo/diminuendo, fortes and pianos, for volume control, etc. There are a lot of these "object oriented" touches. Consider the zigzag "trill".
There is also another branch type "command" that you don't see very often outside of orchestral music, which is marked fp. Visually it looks like the normal forte or piano, except instead of referring to any time the segment is played, the first time through is played louder than the following time(s).
And those STILL aren't all the different branching commands. There are numbered brackets, slashes on note stems, slashes through some of the symbols I've mentioned above. Lots and lots of flow control.
And if that's not enough, there are instrument-specific "commands" for things like pedals (on a piano) or bow techniques (on violin) and slides (on guitar) etc.
So, personally I believe OP is correct in thinking written music (and tabulature) are programming languages.
Mainly because it uses water available on the sea: salt, brackish or polluted water. All the need for energy is fulfilled by sun power. Having in on a land would add complexity with the pipes.
Moreover scarcity of water and cultivable land are the main obstacles to meet the quantitative and qualitative shifts of the world’s demand. Most of the potentially arable land is concentrated in a few geographical areas, and it is extremely scarce in many of the regions with high population growth rates, such as North Africa and the Arabian Peninsula.
The solution it is also modular and flexible and the capability to move it could be really useful in some circumstances.
IIUC this use the solar power to filter the water, and then it is cultivated in pots or hydroponic or something. So it doesn't matter if the structure is on non arable land or over water.
Being over water simplifies the pipes, but you must be sure that the device floats, this is not so easy, small ships sunk very often and need a lot of maintenance, specially in salty water.
Also, the dome/jellyfish shape is nice, but the light each plant gets is smaller, in a flat surface each plan gets more light. The plants essentially convert sunlight into food, so more sunlight is better.
And most commercial plantation relay in very cheap (or free) water. Any filtration to use salty or polluted water will increase the cost of production.
