Update

programming_language.md

@@ -81,7 +81,7 @@ Now that we have a specification, i.e. the idea, someone has to realize it, i.e.
 
 A new language comes to existence just as other things do -- when there is a reason for it. I.e. if someone feels there is no good language for whatever he's doing or if someone has a brilliant idea and want to write a PhD thesis or if someone smokes too much weed or if a corporation wants to control some software platform etc., a new language may be made. This often happen gradually (again, like with many things), i.e. someone just starts modifying an already existing language -- at first he just makes a few macros, then he starts making a more complex preprocessor, then he sees it's starting to become a new language so he gives it a name and makes it a new language -- such language may at first just be transpiled to another language (often [C](c.md)) and over time it gets its own full compiler. At first a new language is written in some other language, however most languages aim for **[self hosted](self_hosting.md) implementation**, i.e. being written in itself. This is natural and has many advantages -- a language written in itself proves its maturity, it becomes independent and as it itself improves, so does its own compiler. Self hosting a language is one of the greatest milestones in its life -- after this the original implementation in the other language often gets deletes as it would just be a burden to keep [maintaining](maintenance.md) it.
 
-**So can a language be inherently fast, [bloated](bloat.md) etc.?** When we say a language is fast, bloated, memory efficient and so on, we often refer to its implementations because, as mentioned, a language is just an idea which can be implemented in many ways with different priorities and tradeoffs, so just keep in mind that talking about languages like this usually refers to the implementations. But on the other hand yes, a language CAN itself be seen as inherently having a similar property because it's simply such that its implementations more or less have to have this property. A very complicated language just cannot be implemented in a simple, non-bloated way, an extremely high level and flexible language cannot be implemented to be among the fastest -- so referring to language implementations we also a little bit refer to the language itself as an implementation reflects the abstract language's properties. **How to tell if language is bloated?** One can get an idea from several things, e.g. list of features, [paradigm](paradigm.md), size of its implementations, number of implementations, size of the specification, year of creation (newer mostly means more bloat) and so on. However be careful, many of these are just clues, for example small specification may just mean it's vague. Even a small self hosted implementation doesn't have to mean the language is small -- imagine e.g. a language that just does what you write in plain English; such language will have just one line self hosted implementation: "Implement yourself." But to actually [bootstrap](boot.md) the language will be immensely difficult and will require a lot of bloat.
+**So can a language be inherently fast, [bloated](bloat.md), memory efficient etc.?** When we say a language is so and so, we generally refer to its implementations and our experience from practice because, as explained previously, a language in itself is only an idea that can be implemented in many ways with different priorities and tradeoffs, and not only that; even if we choose specific implementations of languages, the matter of [benchmarking](benchmark.md) and comparing them is very complicated because the results will be highly dependent for example on hardware architecture we use (some [ISA](isa.md) have slow branching, lack the divide instruction, some MCUs lack floating point unit etcetc., all of which may bias results heavily to either side) AND on test programs we use (some types of problems may better fit the specialization of one language that will do very well at it while it would do much worse at other types of problems), the way they are written (the problem of choosing idiomatic code vs transliteration, i.e. performance will depend on whether we try to solve the benchmark problem in the way that's natural for the language or the way that's more faithful to the described solution) and what weight we give to each one (i.e. even when using multiple benchmarks, we ultimately have to assign a specific importance to each one). It's a bit like trying to say who the fastest human is -- generally we can pick the top sportsmen in the world but then we're stuck because one will win at sprint while the other one at long distance running and another one at swimming, and if we consider even letting them compete in different clothes, weather conditions and so on, we'll just have to give up. So speaking about languages and their quantitative properties in practice generally means talking about their implementations and practical experience we have. HOWEVER, on the other hand, it does make sense to talk about properties of languages as such as well -- a language CAN itself be seen as inherently having some property if it's defined so that its every implementation has to have this property, at least practically speaking. Dynamic typing for example means the language will be generally slower because operations on variables will inevitably require some extra runtime checks of what's stored in the variable. A very complicated language just cannot be implemented in a simple, non-bloated way, an extremely high level and flexible language cannot be implemented to be among the fastest -- so in the end we also partially speak about languages as such because eventually implementations just reflect the abstract language's properties. **How to tell if a language is bloated?** One can get an idea from several things, e.g. list of features, [paradigm](paradigm.md), size of its implementations, number of implementations, size of the specification, year of creation ([newer](modern.md) mostly means more bloat) and so on. However be careful, many of these are just heuristics, for example small specification may just mean it's vague. Even a small self hosted implementation doesn't have to mean the language is small -- imagine e.g. a language that just does what you write in plain English; such language will have just one line self hosted implementation: "Implement yourself." But to actually [bootstrap](boot.md) the language will be immensely difficult and will require a lot of bloat.
 
 Judging languages may further be complicated by the question of what the language encompasses because some languages are e.g. built on relatively small "pure language" core while relying on a huge library, preprocessor, other embedded languages and/or other tools of the development environment coming with the language -- for example [POSIX shell](posix_shell.md) makes heavy use of separate programs, utilities that should come with the POSIX system. Similarly [Python](python.md) relies on its huge library. So sometimes we have to make it explicitly clear about this.
 
@@ -124,6 +124,8 @@ Here is a table of notable programming languages in chronological order (keep in
 | [uxntal](uxn.md)        | **yes** but SJW  | 2021  | 400 (official)          | 2? (est.), proprietary | assembly lang. for a minimalist virtual machine, PROPRIETARY SPEC.      |
 | **[comun](comun.md)**   | **yes**          | 2022  | < 3K                    | 2, CC0                 | "official" [LRS](lrs.md) language, WIP, similar to Forth                |
 
+TODO: add "relative speed" column, make some kinda benchmark program and say how many times each languages is slower than C
+
 TODO: Tcl, Rebol
 
 ## Interesting Languages