7 ms·

"...we wondered what we could do without the baggage of C." Is that tongue in cheek? It's not even a particularly large, encumbered language, C.

by clebio 12y ago

stormbrew 12y ago
It is when you have to maintain compatibility with it in your new shiny language that's based on it. C alone may not be particularly large or encumbered (though it does have that vexing parse), but as the foundation of other languages it can cause problems.
mkremins 12y ago
I suspect they were referring more to the syntactic baggage in Objective-C – which is at least partially a result of the fact that ObjC was originally implemented as a simple C preprocessor. To avoid syntactic conflicts with C, ObjC uses lots of weird syntactic constructs that contribute to the language's characterization as ugly. A good example is the liberal use of the @ character to denote ObjC literals – even in front of strings and numbers, because raw C strings/numbers have different semantics and won't play well with the standard ObjC APIs.
- clebio 12y ago
  That's good context, thanks. When I dabbled in Objective-C, I found the excessive bracketing strange. Thanks for the background.
stcredzero 12y ago
Is that tongue in cheek? It's not even a particularly large, encumbered language, C. This would make a lot more sense if you knew about the history behind Objective-C. http://en.wikipedia.org/wiki/Smalltalk http://en.wikipedia.org/wiki/Smalltalk
- clebio 12y ago
  That's a good point, thank you!
xenadu02 12y ago
Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. That's billions of human beings wasting hours either changing all their passwords or having their money, identities, medical records, and more stolen because they didn't. Having their accounts hijacked. For all we know totalitarian governments have already exploited this to monitor citizens and torture or kill them. If that isn't enough, how about goto fail? All the IIS exploits in v4/5? Various Windows RPC overflows, WMF overflows, SQL Slammer, et al? How many billions in damages have been caused by stack smashing and buffer overflows? How many millions of hours of manpower wasted cleaning up after these errors? Toyota killed some people because their dumb code overwrote memory, blasting the OS task tables causing the watchdog task to stop getting CPU time, meaning nothing provided a stopgap against unintended acceleration. People are literally dying because we can't fucking let go of C. C is like saying "forget seat belts, child seats, anti-lock breaks, and adaptive steering! How can I power-slide? I want full control; I need to pump the breaks. People should just drive better, then we'd have fewer accidents". We've been trying to "drive better" for decades (Valgrind, lint, code reviews, static analysis tools, education, ASLR, NX protection, et al). We still regularly see massive security-smashing epic failures. It hasn't worked. Furthermore the C standard library has been proven turing-complete for ROP gadgets in the presence of a buffer overflow. So no matter what you do, the presence of a single stack smash is enough to allow code execution, subject to payload size limits and execution time. At some point we have to admit C is no longer acceptable. Not for libraries, not for drivers, not for operating systems. It has to go. All the performance benefits ever derived from writing everything in C has been more than erased, by orders of magnitude, by the damage caused from even simple innocent mistakes. Software allows us as programmers to greatly magnify our impact on the world; we like to think of that in positive ways. But the inverse is also true: thanks to the continued use of non-memory-safe languages we have the power to negatively affect the world on a massive scale. It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period.
- pjmlp 12y ago
  The sad part, is that already in the 70's there were better alternatives, but UNIX creators just decided to ignore them and create their own language.

"...we wondered what we could do without the baggage of C." Is that tongue in cheek? It's not even a particularly large, encumbered language, C.

by clebio 12y ago

"...we wondered what we could do without the baggage of C." Is that tongue in cheek? It's not even a particularly large, encumbered language, C.

stormbrew 12y ago

It is when you have to maintain compatibility with it in your new shiny language that's based on it. C alone may not be particularly large or encumbered (though it does have that vexing parse), but as the foundation of other languages it can cause problems.

mkremins 12y ago

I suspect they were referring more to the syntactic baggage in Objective-C – which is at least partially a result of the fact that ObjC was originally implemented as a simple C preprocessor. To avoid syntactic conflicts with C, ObjC uses lots of weird syntactic constructs that contribute to the language's characterization as ugly. A good example is the liberal use of the @ character to denote ObjC literals – even in front of strings and numbers, because raw C strings/numbers have different semantics and won't play well with the standard ObjC APIs.

clebio 12y ago
That's good context, thanks. When I dabbled in Objective-C, I found the excessive bracketing strange. Thanks for the background.

stcredzero 12y ago

Is that tongue in cheek? It's not even a particularly large, encumbered language, C. This would make a lot more sense if you knew about the history behind Objective-C. http://en.wikipedia.org/wiki/Smalltalk http://en.wikipedia.org/wiki/Smalltalk

clebio 12y ago
That's a good point, thank you!

xenadu02 12y ago

Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. That's billions of human beings wasting hours either changing all their passwords or having their money, identities, medical records, and more stolen because they didn't. Having their accounts hijacked. For all we know totalitarian governments have already exploited this to monitor citizens and torture or kill them. If that isn't enough, how about goto fail? All the IIS exploits in v4/5? Various Windows RPC overflows, WMF overflows, SQL Slammer, et al? How many billions in damages have been caused by stack smashing and buffer overflows? How many millions of hours of manpower wasted cleaning up after these errors? Toyota killed some people because their dumb code overwrote memory, blasting the OS task tables causing the watchdog task to stop getting CPU time, meaning nothing provided a stopgap against unintended acceleration. People are literally dying because we can't fucking let go of C. C is like saying "forget seat belts, child seats, anti-lock breaks, and adaptive steering! How can I power-slide? I want full control; I need to pump the breaks. People should just drive better, then we'd have fewer accidents". We've been trying to "drive better" for decades (Valgrind, lint, code reviews, static analysis tools, education, ASLR, NX protection, et al). We still regularly see massive security-smashing epic failures. It hasn't worked. Furthermore the C standard library has been proven turing-complete for ROP gadgets in the presence of a buffer overflow. So no matter what you do, the presence of a single stack smash is enough to allow code execution, subject to payload size limits and execution time. At some point we have to admit C is no longer acceptable. Not for libraries, not for drivers, not for operating systems. It has to go. All the performance benefits ever derived from writing everything in C has been more than erased, by orders of magnitude, by the damage caused from even simple innocent mistakes. Software allows us as programmers to greatly magnify our impact on the world; we like to think of that in positive ways. But the inverse is also true: thanks to the continued use of non-memory-safe languages we have the power to negatively affect the world on a massive scale. It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period.

pjmlp 12y ago
The sad part, is that already in the 70's there were better alternatives, but UNIX creators just decided to ignore them and create their own language.