Update
This commit is contained in:
parent
16fc4bbb12
commit
76147e3778
11 changed files with 92 additions and 51 deletions
2
c.md
2
c.md
|
@ -66,7 +66,7 @@ The standard library (libc) is a subject of live debate because while its interf
|
|||
Nothing is [perfect](perfect.md), not even C; it was one of the first relatively higher level languages and even though it has showed to have been designed extremely well, some things didn't age great, or were simply bad from the start. We still prefer this language as usually the best choice, but it's good to be aware of its downsides or smaller issues, if only for the sake of one day designing a better language. Keep in mind all here are just suggestions, they made of course be a subject to counter arguments and further discussion. So, let's go:
|
||||
|
||||
- **C specification (the ISO standard) is [proprietary](proprietary.md)** :( The language itself probably can't be copyrighted, nevertheless this may change in the future, and a proprietary specs lowers C's accessibility and moddability (you can't make derivative versions of the spec).
|
||||
- **The specification is also long as fuck**, indicating [bloat](bloat.md)/complexity/obscurity. A good, free language should have a simple definition. It could be simplified a lot by simplifying the language itself as well as dropping some truly legacy considerations (like [BCD](bcd.md) systems?) and removing a lot of undefined behavior.
|
||||
- **The specification is also long as fuck** (approx. 500 pages), indicating [bloat](bloat.md)/complexity/obscurity. A good, free language should have a simple definition. It could be simplified a lot by simplifying the language itself as well as dropping some truly legacy considerations (like [BCD](bcd.md) systems?) and removing a lot of undefined behavior.
|
||||
- **Some behavior is weird and has exceptions**, for example a function can return anything, including a `struct`, except for an array. This makes it awkward to e.g. implement vectors which would best be made as arrays but you want functions to return them, so you may do hacks like wrapping them instide a struct just for this.
|
||||
- **Some things could be made simpler**, e.g. using [reverse polish](reverse_polish.md) notation for expressions, rather than expressions with brackets and operator precedence, would make implementations much simpler, increasing sucklessness (of course readability is an argument).
|
||||
- **Some things could be dropped entirely** ([enums](enum.md), [bitfields](bitfield.md), possibly also unions etc.), they can be done and imitated in other ways without much hassle.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue