3 ms·

Why I love C? In a word, simplicity. A language designed by a single person. I also did program a lot in CLisp, a language designed by committee, with more tha

Why I love C? In a word, simplicity. A language designed by a single person. I also did program a lot in CLisp, a language designed by committee, with more than 100 different flow control directives(and people often create their own). I loved and love Lisp as a concept and tool, but hated CLisp complex design so badly. I programmed in Arc for a while because of that. I have created my own C compiler and interpreter. Something impossible to do for a single person in C++(C++ is way more complicated). I also love manual memory handling in C because it lets me create my own automatic local systems much more efficient than someone else's "one size fits all" aproach. I have also programmed mac apps in Objective C and Swift, C++, java, javascript, Perl. I program today mainly in four languages: C/C++, Python, Rust and Clojure. With C it is so easy to create python modules. It is trivial to interoperate from C++ with C. Clojure is a Lisp that is simple, clean design, and you could interoperate with java objects. Rust has some advantages over C, but also disadvantages(it is too bloated).

WalterBright 3y ago
> impossible to do for a single person in C++(C++ is way more complicated) I wrote a fully compliant C++98 compiler (Digital Mars C++).
shrimp_emoji 3y ago
>I have created my own C compiler and interpreter. It's relatively simple because everything is UB/UsB/IDB. ;)
WalterBright 3y ago
> In a word, simplicity. For fun, go to /usr/include and try to understand the system .h files.
- gavinhoward 3y ago
  This is why I've kinda built my own libc on the bare minimum that the system gives me. The POSIX and Windows API's are garbage; C the language is great.
  - zabzonk 3y ago
    i have written a fair bit of code using the windows and posix APIs, and they are OK - what features of these, often written by talented programmers, do you despise so much?
    - gavinhoward 3y ago
      To pick the same example from both, I hate both fork() and CreateProcess(). Microsoft wrote "A fork() in the Road" [1] describing the problems with fork(), and they are right: fork() is too simple, it doesn't scale, it is inefficient, and error handling becomes next to impossible. (In my code, I have the child process return exit codes from 255 on down for error handling. It assumes, probably wrongly but right enough, that most programs won't use those exit codes.) But CreateProcess() has the exact opposite problem: it's too complex and limited because it takes a large, fixed set of arguments. It takes many lines of code to set up for it, and once you actually start the process, you have no control over it, which sucks if you need to do something with the new process that CreateProcess() cannot do on creation. Windows does have ways of modifying running processes, which is great and sort of makes up for the limits, but heaven help you if you need to use one of those functions on the new process because you have no control. The only thing you can do is to suspend the start thread of the new process right away, do your thing to it, and resume the thread, praying that the new process hadn't created a new runaway thread before it was suspended. (And all of that is not even mentioning that the Windows way of passing a command-line is to pass a string to be parsed, not a list of strings. My code has a function literally to take a list of strings and turn it into a Windows-compatible command-line string with all of the juicy backslashing that implies.) The right API is in the middle: a zero-argument function to create a new, blank process (not a copy of the current process), but to create it in a suspended state, so you know it's not going to run away from you. Then, you use Windows-style functions to change the process, before it even starts, to set it up. Once you're done, unsuspend it. That end result gives you as much power as fork(), with the better scalability of CreateProcess(), and better ease-of-use than both. You could even have functions to map in a copy of the current process if you so wish, to implement fork() for process checkpointing! In other words, talented programmers can implement things and make them work, yes, but it doesn't imply that they are good at design. [1]: https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0...

WalterBright 3y ago

> impossible to do for a single person in C++(C++ is way more complicated) I wrote a fully compliant C++98 compiler (Digital Mars C++).

shrimp_emoji 3y ago

>I have created my own C compiler and interpreter. It's relatively simple because everything is UB/UsB/IDB. ;)

WalterBright 3y ago

> In a word, simplicity. For fun, go to /usr/include and try to understand the system .h files.

gavinhoward 3y ago
This is why I've kinda built my own libc on the bare minimum that the system gives me. The POSIX and Windows API's are garbage; C the language is great.
- zabzonk 3y ago
  i have written a fair bit of code using the windows and posix APIs, and they are OK - what features of these, often written by talented programmers, do you despise so much?
  - gavinhoward 3y ago
    To pick the same example from both, I hate both fork() and CreateProcess(). Microsoft wrote "A fork() in the Road" [1] describing the problems with fork(), and they are right: fork() is too simple, it doesn't scale, it is inefficient, and error handling becomes next to impossible. (In my code, I have the child process return exit codes from 255 on down for error handling. It assumes, probably wrongly but right enough, that most programs won't use those exit codes.) But CreateProcess() has the exact opposite problem: it's too complex and limited because it takes a large, fixed set of arguments. It takes many lines of code to set up for it, and once you actually start the process, you have no control over it, which sucks if you need to do something with the new process that CreateProcess() cannot do on creation. Windows does have ways of modifying running processes, which is great and sort of makes up for the limits, but heaven help you if you need to use one of those functions on the new process because you have no control. The only thing you can do is to suspend the start thread of the new process right away, do your thing to it, and resume the thread, praying that the new process hadn't created a new runaway thread before it was suspended. (And all of that is not even mentioning that the Windows way of passing a command-line is to pass a string to be parsed, not a list of strings. My code has a function literally to take a list of strings and turn it into a Windows-compatible command-line string with all of the juicy backslashing that implies.) The right API is in the middle: a zero-argument function to create a new, blank process (not a copy of the current process), but to create it in a suspended state, so you know it's not going to run away from you. Then, you use Windows-style functions to change the process, before it even starts, to set it up. Once you're done, unsuspend it. That end result gives you as much power as fork(), with the better scalability of CreateProcess(), and better ease-of-use than both. You could even have functions to map in a copy of the current process if you so wish, to implement fork() for process checkpointing! In other words, talented programmers can implement things and make them work, yes, but it doesn't imply that they are good at design. [1]: https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0...