drummyfish/less_retarded_wiki
5
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update

Browse source
This commit is contained in:
Miloslav Ciz 2023-03-30 21:47:53 +02:00
parent cc46586935
commit 0707639560
7 changed files with 94 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

4
c.md
View file

@ -58,12 +58,12 @@ 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**. 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**, indicating some kind of [bloat](bloat.md). 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.
- **The preprocessor isn't exactly elegant**, it has completely different syntax and rules from the main language, not very suckless -- ideally preprocessor uses the same language as the base language.
- **The syntax isn't perfect**, e.g. it's pretty weird that the condition after `if` has to be in brackets, it could be designed better. Keywords also might be better being single chars, like `?` instead of `if` or the weird long ass names with spaces like `unsigned long long` could be made nicer. A shorter, natural-language-neutral source code would be probably better. Both line and block comments could be implemented with a single character (e.g. `#` for line comment, ending with a newline or another `#`, `##` for block comment ending with another `##`?).
- **The syntax is sucky**, e.g. data type names may consist of multiple tokens (`long long int` etc.), also it's pretty weird that the condition after `if` has to be in brackets, it could be designed better. Keywords also might be better being single chars, like `?` instead of `if` etc. A shorter, natural-language-neutral source code would be probably better. Both line and block comments could be implemented with a single character (e.g. `#` for line comment, ending with a newline or another `#`, `##` for block comment ending with another `##`?).
- **Some basic things that are part of libraries or extensions**, like fixed with types and binary literals and possibly very basic I/O (putchar/readchar) could be part of the language itself.
- **Some undefined behavior might be better defined** -- undefined behavior isn't bad in general, it is what allows C to be so fast and efficient in the first place, but some of it has shown to be rather cumbersome; for example the unspecified representation of integers, their binary size and behavior of floats leads to a lot of trouble (unknown upper bounds, sizes, undefined behavior of many operators etc.) while practically all computers have settled on using 8 bit bytes and [two's complement](twos_complement.md) -- this could easily be made a mandatory assumption which would simplify great many things without doing basically any harm. New versions of C actually already settle on two's complement. This doesn't mean C should be shaped to reflect the degenerate "[modern](modern.md)" trends in programming though!
- All that stuff with *.c* and *.h* files is unnecessary, there should just be one file type -- this isn't part of the language per se, but it's part of its culture.