Update

programming_language.md

@@ -71,7 +71,7 @@ What really IS a programming language -- is it software? Is it a standard? Can a
 
 Strictly speaking programming language is a [formal language](formal_language.md) with [semantics](semantics.md), i.e. just something akin a "mathematical idea" -- as such it cannot be directly "owned", at least not on the grounds of [copyright](copyright.md), as seems to have been quite strongly established by a few court cases now. However things related to a language can sadly be owned, for example their specifications (official standards describing the language), [trademarks](trademark.md) (the name or logo of the language), implementations (specific software such as the language's compiler), [patents](patent.md) on some ideas used in the implementation etc. Also if a language is very complex, it can be owned practically; typically a corporation will make an extremely complicated language which only 1000 paid programmers can maintain, giving the corporation complete control over the language -- see [bloat monopoly](bloat_monopoly.md) and [capitalist software](capitalist_software.md).
 
-At this point we should start to distinguish between the pure language and its **[implementation](implementation.md)**. As has been said, the pure language is just an idea -- this idea is explained in detail in so called **language specification**, a document that's kind of a standard that precisely describes the language. Specification is a technical document, it is NOT a tutorial or promotional material or anything like that, its purpose is just to DEFINE the language for those who will be implementing it. Theoretically specification is the first thing, however in practice we usually have someone e.g. program a small language for internal use in a company, then that language becomes more popular and widespread and only then someone decides to standardize it and make the official specification. Specification describes things like syntax, semantics, conformance criteria etc., often using precise formal tools such as [grammars](grammar.md). It's hugely difficult to make good specification because one has to decide what depth to go to and even what to purposefully leave unspecified! One would thought that it's always better to define as many things as possible, but that's naive -- leaving some things up to the choice of those who will be implementing the language gives them freedom to implement it in a way that's fastest, most elegant or convenient in any other way.
+At this point we should start to distinguish between the pure language and its **[implementation](implementation.md)**. As has been said, the pure language is just an idea -- this idea is explained in detail in so called **language specification**, a document that's kind of a standard that precisely describes the language. Specification is a technical document, it is NOT a tutorial or promotional material or anything like that, its purpose is just to DEFINE the language for those who will be implementing it -- sometimes specification can be a very official standard made by some standardizing organization (as e.g. with C), other times it may be just a collaborative online document that at the same time serves as the language reference (as e.g. with Lua). In any case it's important to [version](version_numbering.md) the specification just as we version programs, because when specification changes, the specified languages usually changes too (unless it's a minor change such as fixing some typos), so we have to have a way to exactly identify WHICH version of the language we are referring to. Theoretically specification is the first thing, however in practice we usually have someone e.g. program a small language for internal use in a company, then that language becomes more popular and widespread and only then someone decides to standardize it and make the official specification. Specification describes things like syntax, semantics, conformance criteria etc., often using precise formal tools such as [grammars](grammar.md). It's hugely difficult to make good specification because one has to decide what depth to go to and even what to purposefully leave unspecified! One would thought that it's always better to define as many things as possible, but that's naive -- leaving some things up to the choice of those who will be implementing the language gives them freedom to implement it in a way that's fastest, most elegant or convenient in any other way.
 
 It is possible for a language to exist without official specification -- the language is then basically specified by some of its implementations, i.e. we say the language is "what this program accepts as valid input". Many languages go through this phase before receiving their specification. Language specified purely by one implementation is not a very good idea because firstly such specification is not very readable and secondly, as said, here EVERYTHING is specified by this one program (the language EQUALS that one specific compiler), we don't know where the freedom of implementation is. Do other implementations have to produce exactly the same compiled binary as this one (without being able to e.g. optimize it better or produce binaries for other platforms)? If not, how much can they differ? Can they e.g. use different representation of numbers (may be important for compatibility)? Do they have to reproduce even the same bugs as the original compiler? Do they have to have the same technical limitations? Do they have to implement the same command line interface (without potentially adding improvements)? Etc.
 
@@ -99,7 +99,7 @@ Here is a table of notable programming languages in chronological order (keep in
 | [Pascal](pascal.md)     | **kind of**      | 1970  |                         |                        | like "educational C", compiled, not so bad actually                     |
 | **[C](c.md)**           | **kind of**      | 1972  | 20K (lcc)               | 160, proprietary       | compiled, fastest, efficient, established, suckless, low-level, #1 lang.|
 | [Prolog](prolog.md)     | maybe?           | 1972  |                         |                        | [logic](logic.md) paradigm, hard to learn/use                           |
-|[Smalltalk](smalltalk.md)| looks like yes?  | 1972  |                         |                        | PURE [OOP](oop.md) language, probably not as corrupt as C++/Java/...    |
+|[Smalltalk](smalltalk.md)| **quite yes**    | 1972  |                         | 40, proprietary (ANSI) | PURE (bearable kind of) [OOP](oop.md) language, pretty minimal          |
 | [C++](cpp.md)           | no, bearable     | 1982  |                         | 500, proprietary       | bastard child of C, only adds [bloat](bloat.md) ([OOP](oop.md)), "games"|
 | [Ada](ada.md)           | ???              | 1983  |                         |                        | { No idea about this, sorry. ~drummyfish }                              |
 | Object Pascal           | no               | 1986  |                         |                        | Pascal with OOP (like what C++ is to C), i.e. only adds bloat           |
@@ -110,7 +110,7 @@ Here is a table of notable programming languages in chronological order (keep in
 | [Python](python.md)     | NO               | 1991  |                         | 200? (p. lang. ref.)   | interpreted, huge bloat, slow, lightweight OOP, artificial obsolescence |
 | POSIX [shell](shell.md) | well, "kind of"  | 1992  |                         | 50, proprietary (paid) | standardized (std 1003.2-1992) Unix shell, commonly e.g. [Bash](bash.md)|
 |[Brainfuck](brainfuck.md)| **yes**          | 1993  | 100 (judg. by dbfi)     | 1                      | extremely minimal (8 commands), hard to use, [esolang](esolang.md)      |
-| [Lua](lua.md)           | **kind of**      | 1993  |                         |                        | interpreted, mainly for scripting (used a lot in games)                 |
+| [Lua](lua.md)           | **quite yes**    | 1993  | 7K (LuaInLua)           | 40, free               | small, interpreted, mainly for scripting (used a lot in games)          |
 | [Java](java.md)         | NO               | 1995  |                         | 800, proprietary       | forced [OOP](oop.md), "platform independent" (bytecode), slow, bloat    |
 | [JavaScript](js.md)     | NO               | 1995  | 50K (est. from QuickJS) | 500, proprietary?      | interpreted, the [web](web.md) lang., bloated, classless [OOP](oop.md)  |
 | [PHP](php.md)           | no               | 1995  |                         | 120 (by Google), CC0   | server-side web lang., OOP                                              |