12 ms·

I went to pick up my son at University studying CS recently. He had replaced Win 10 on his tower with Ubuntu and was writing a pretty complex program in C++.

I went to pick up my son at University studying CS recently. He had replaced Win 10 on his tower with Ubuntu and was writing a pretty complex program in C++. Doing some AI/ML primitives. Thought to myself I am old yet went to the same University and would have been coding in C++ on Unix (Ultrix or OSF or Solaris) at that point in my life. How in the world have we not moved on? BTW, his code was so, so pretty. Mine would have been ugly. Kids are far better coders than we were 30 years ago. I was crazy proud.

jumpman500 8y ago
Sometimes tools are good enough that they don't need to change. People still use hammers and nails, even though we have awesome power tools and many different types of skrews. Coherency and ease of use are very important factors when building anything.
mercer 8y ago
Perhaps that BTW is what makes all the difference. I suspect that 'us' coders might overvalue the language or tools we use, and undervalue the progress that might take place in the context of them. Not just when it comes to the next generation(s), but also in our own work. For example, over the past decade or two I've 'improved' my toolage by learning vim and emacs, figuring out how to get Sourcemaps and live reloading working, and improving my command-line-fu. And yet, as a programmer, I feel all of these improvements pale in comparison to the stuff I learned that would be equally useful in Notepad as it would be in a decked out Sublime Text/VSCode/Emacs. This becomes evident when I work on one-off scripts in the Chrome developer tools, or editing stuff using vim on a server. I'm reduced to the most basic tooling, and yet I can get stuff done in a fraction of the time that I'd have needed a few years ago.
- jacksmith21006 8y ago
  Woops! Forget the best part. He was using Vim to write the code. That one really cracked me up as I am a Vi wiz and would never change as I am just so fast using. Never used Emacs.
- philangist 8y ago
  > And yet, as a programmer, I feel all of these improvements pale in comparison to the stuff I learned that would be equally useful in Notepad as it would be in a decked out Sublime Text/VSCode/Emacs. As someone who's 5 years into my career and interested in moving past the not quite a senior engineer plateau, what would you say are the important things you've learned?
zwieback 8y ago
I think it's because C++ maps reasonably well to our model of a CPU (basically moving stuff in and out of registers and doing simple operations on those). The guts of a modern CPU is quite different from our mental model and that causes a lot of distress for compiler writers but the programming model has basically not changed in the 35 years I've been coding.
jimbokun 8y ago
The actual productivity improvements are things like * distributed version control, * open source culture and infrastructure (GitHub, GPL and Apache licenses...), * dependency management and build tools (pull in many man years of effort into your project with a single declaration), * HTTP and REST APIs (accidentally taught developers the importance of idempotency, statelessness, uniform interfaces, etc.), * cloud infrastructure (no more need to purchase, install, configure, and secure expensive workstations before starting your project and business). As for programming languages, there have been very few actual productivity gains since the standardization of Common Lisp.
- flavio81 8y ago
  >As for programming languages, there have been very few actual productivity gains since the standardization of Common Lisp. Although this is mostly true, I think you forgot to mention that the latest trend of repositories with tens of thousands of libraries are a boost in productivity as well. Even the Common Lisp world received a big boost in productivity when the Quicklisp library/system repository was created and consolidated.
- hinkley 8y ago
  * Decades of coherent thought on code robustness and maintainability.
- bsder 8y ago
  > As for programming languages, there have been very few actual productivity gains since the standardization of Common Lisp. This isn't true. Common Lisp had more than a few problems which later languages fixed: 1) Module system/encapsulation Common Lisp has a notoriously fickle and opaque system for importing other code into your space. 2) Sequences as sequences rather than linked lists terminated by null. Dealing with the fact that a list is a null-terminated linked list instead of an actual sequence/vector/tree is a big deal. Try implementing a printer for dotted pairs at some point. Talk about annoying and it costs you enormous performance. I could keep going, but there are far better qualified people to talk about the many shortcoming of Common Lisp.
chubot 8y ago
It's an interesting observation, but I would say slightly misleading because different levels of the stack change at different rates. The low level C/Unix layer is the foundation for everything else, so it has not changed very much. That's actually a good thing! It's stable and incrementally improving. The higher levels of the stack have wildly changed -- JS, Python/Ruby/Perl, web frameworks, R and pandas, TypeScript, etc. not to mention all this cloud stuff. JS and Python are on microcontrollers! I think that is working as intended. But if anyone had the misconception: we don't have the bandwidth to replace the lower levels of the stack! Microsoft doesn't either, and they have billions of dollars. Nobody rewrites stuff "just because". That's why C++ is still relevant. (It's also why I think Rust is not really a C++ "replacement". It might be used for NEW stuff, but there will still be tons of C/C++ code around for decades. Again, the rate of rewriting/replacing is slower than you think.) Now, to argue the opposite side: writing applications (as opposed to low-level libraries) in C++ does feel like a smell. Sometimes C++ is still a justified application language. But it does feel like its territory has been encoached about by Obj C / Swift on iOS, Java/Kotlin on Android, and JS on the web. So there are not as many new C++ applications as there used to be, but there are still some.
- jacksmith21006 8y ago
  Thanks for your thoughts! When I saw my son coding in C++ I said to him why not Go or Rust? But on the ride home thought doing it C++ makes total sense as no matter what he uses when gets a job knowing C++ is required today. So much older code still in C++. BTW, he was working on lower level primitives as for higher level I would have suggested Python and a backup of R.
- pjmlp 8y ago
  C++ has been replacing the low level kernel code since Windows 8, little by little. And UWP, written in a mix of C++ and .NET Native is the future of the Windows desktop applications, even if it takes the next couple of years to eventually get there. All new APIs are UWP based. This week's BUILD 2018 has proven that they are still on that direction, one day Win32 will join Win16. And in Azure, well the underlying OS doesn't really matter for most languages with rich runtimes. As for your remark regarding apps, there I fully agree. C++ has been pushed down the stack, left for GPGPU shaders and low level OS features, with Microsoft being the only exception of having tooling parity with the other languages on their OS SDK. Here Apple and Google have C++ on a little box bounded by Objective-C++ and JNI. And on UWP, even if many high performance components are written in C++, most teams just use .NET Native.
rayiner 8y ago
Why would we move on? C is a local maximum, like a Brayton-cycle gas turbine engine. A 787 engine is no more than 50% more efficient than a 707 engine, despite tens of billions of dollars in investment and decades of R&D between the two. And we won't get even another 50% improvement any time soon. It'll take a fundamental change in technology to move past that plateau. C is likewise on a plateau. There is nothing categorically better than C for what C does; just different points in the design space that make different trade offs. E.g. Rust gives you memory safety through ownership, but you can't even make a doubly-linked list while staying within the ownership system. In a different point in the design space, Go has garbage collection, but that comes with its own trade offs. All of these might become obsolete when we have e.g. quantum computers. But in the meantime we are just playing with different trade offs, because we've captured all the low-hanging fruit decades ago.
- nickpsecurity 8y ago
  "E.g. Rust gives you memory safety through ownership, but you can't even make a doubly-linked list while staying within the ownership system." Your otherwise good comment presents this like all-or-nothing when comparing it to C. To start with, C and Rust are equivalent for anything it cant borrow-check. Then, it's better than C in safety or expressiveness from there. Second, C developers use plenty external libraries to supplement the language's capabilities, including with ASM breaking abstraction gap. Likewise, whatever Rust cant handle can be proven safe with external tool, wrapped in safe interface, and used from there. This has been done in languages from C to Haskell. So, there's different design points for sure but doubly-linked-list isnt an example of unfit for purpose vs C. If anything, that it's equal or better in safety making it a better instance in that design space. Likewise for Clay which was more C-like and used in device drivers.
  - rayiner 8y ago
    But at the end of the day, I wouldn’t call it a categorical improvement over C because you still have to drop down to what is basically C to handle essential tasks like declaring circular data structures. Instead, it makes a special (but common) case of tree-like data structures safer to handle. This is no fault of Rust—it is a theoretical limitation. There is no single model that let’s you express arbitrary data structures, gives you memory safety, and doesn’t require runtime heap walking.
MisterTea 8y ago
> How in the world have we not moved on? We tried but have yet to give up. "It looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough." — Eric S. Raymond
justin66 8y ago
> BTW, his code was so, so pretty. Mine would have been ugly. Kids are far better coders than we were 30 years ago. I was crazy proud. I don't know what compiler you were using on Ultrix but C++ in that era was insanely bad.
- Taniwha 8y ago
  Ultrix was roughly about the same time as the first C++ (a preprocessor that made C) - people were still figuring out what good and bad C++ was
  - jacksmith21006 8y ago
    Yes similar time frame but C++ first. I tended to be into the new thing so was into C++. It was mid 80s and C++ dates back to 1979 if memory serves.

jumpman500 8y ago

Sometimes tools are good enough that they don't need to change. People still use hammers and nails, even though we have awesome power tools and many different types of skrews. Coherency and ease of use are very important factors when building anything.

mercer 8y ago

Perhaps that BTW is what makes all the difference. I suspect that 'us' coders might overvalue the language or tools we use, and undervalue the progress that might take place in the context of them. Not just when it comes to the next generation(s), but also in our own work. For example, over the past decade or two I've 'improved' my toolage by learning vim and emacs, figuring out how to get Sourcemaps and live reloading working, and improving my command-line-fu. And yet, as a programmer, I feel all of these improvements pale in comparison to the stuff I learned that would be equally useful in Notepad as it would be in a decked out Sublime Text/VSCode/Emacs. This becomes evident when I work on one-off scripts in the Chrome developer tools, or editing stuff using vim on a server. I'm reduced to the most basic tooling, and yet I can get stuff done in a fraction of the time that I'd have needed a few years ago.

jacksmith21006 8y ago
Woops! Forget the best part. He was using Vim to write the code. That one really cracked me up as I am a Vi wiz and would never change as I am just so fast using. Never used Emacs.
philangist 8y ago
> And yet, as a programmer, I feel all of these improvements pale in comparison to the stuff I learned that would be equally useful in Notepad as it would be in a decked out Sublime Text/VSCode/Emacs. As someone who's 5 years into my career and interested in moving past the not quite a senior engineer plateau, what would you say are the important things you've learned?

zwieback 8y ago

I think it's because C++ maps reasonably well to our model of a CPU (basically moving stuff in and out of registers and doing simple operations on those). The guts of a modern CPU is quite different from our mental model and that causes a lot of distress for compiler writers but the programming model has basically not changed in the 35 years I've been coding.

jimbokun 8y ago

The actual productivity improvements are things like * distributed version control, * open source culture and infrastructure (GitHub, GPL and Apache licenses...), * dependency management and build tools (pull in many man years of effort into your project with a single declaration), * HTTP and REST APIs (accidentally taught developers the importance of idempotency, statelessness, uniform interfaces, etc.), * cloud infrastructure (no more need to purchase, install, configure, and secure expensive workstations before starting your project and business). As for programming languages, there have been very few actual productivity gains since the standardization of Common Lisp.

flavio81 8y ago
>As for programming languages, there have been very few actual productivity gains since the standardization of Common Lisp. Although this is mostly true, I think you forgot to mention that the latest trend of repositories with tens of thousands of libraries are a boost in productivity as well. Even the Common Lisp world received a big boost in productivity when the Quicklisp library/system repository was created and consolidated.
hinkley 8y ago
* Decades of coherent thought on code robustness and maintainability.
bsder 8y ago
> As for programming languages, there have been very few actual productivity gains since the standardization of Common Lisp. This isn't true. Common Lisp had more than a few problems which later languages fixed: 1) Module system/encapsulation Common Lisp has a notoriously fickle and opaque system for importing other code into your space. 2) Sequences as sequences rather than linked lists terminated by null. Dealing with the fact that a list is a null-terminated linked list instead of an actual sequence/vector/tree is a big deal. Try implementing a printer for dotted pairs at some point. Talk about annoying and it costs you enormous performance. I could keep going, but there are far better qualified people to talk about the many shortcoming of Common Lisp.

chubot 8y ago

It's an interesting observation, but I would say slightly misleading because different levels of the stack change at different rates. The low level C/Unix layer is the foundation for everything else, so it has not changed very much. That's actually a good thing! It's stable and incrementally improving. The higher levels of the stack have wildly changed -- JS, Python/Ruby/Perl, web frameworks, R and pandas, TypeScript, etc. not to mention all this cloud stuff. JS and Python are on microcontrollers! I think that is working as intended. But if anyone had the misconception: we don't have the bandwidth to replace the lower levels of the stack! Microsoft doesn't either, and they have billions of dollars. Nobody rewrites stuff "just because". That's why C++ is still relevant. (It's also why I think Rust is not really a C++ "replacement". It might be used for NEW stuff, but there will still be tons of C/C++ code around for decades. Again, the rate of rewriting/replacing is slower than you think.) Now, to argue the opposite side: writing applications (as opposed to low-level libraries) in C++ does feel like a smell. Sometimes C++ is still a justified application language. But it does feel like its territory has been encoached about by Obj C / Swift on iOS, Java/Kotlin on Android, and JS on the web. So there are not as many new C++ applications as there used to be, but there are still some.

jacksmith21006 8y ago
Thanks for your thoughts! When I saw my son coding in C++ I said to him why not Go or Rust? But on the ride home thought doing it C++ makes total sense as no matter what he uses when gets a job knowing C++ is required today. So much older code still in C++. BTW, he was working on lower level primitives as for higher level I would have suggested Python and a backup of R.
pjmlp 8y ago
C++ has been replacing the low level kernel code since Windows 8, little by little. And UWP, written in a mix of C++ and .NET Native is the future of the Windows desktop applications, even if it takes the next couple of years to eventually get there. All new APIs are UWP based. This week's BUILD 2018 has proven that they are still on that direction, one day Win32 will join Win16. And in Azure, well the underlying OS doesn't really matter for most languages with rich runtimes. As for your remark regarding apps, there I fully agree. C++ has been pushed down the stack, left for GPGPU shaders and low level OS features, with Microsoft being the only exception of having tooling parity with the other languages on their OS SDK. Here Apple and Google have C++ on a little box bounded by Objective-C++ and JNI. And on UWP, even if many high performance components are written in C++, most teams just use .NET Native.

rayiner 8y ago

Why would we move on? C is a local maximum, like a Brayton-cycle gas turbine engine. A 787 engine is no more than 50% more efficient than a 707 engine, despite tens of billions of dollars in investment and decades of R&D between the two. And we won't get even another 50% improvement any time soon. It'll take a fundamental change in technology to move past that plateau. C is likewise on a plateau. There is nothing categorically better than C for what C does; just different points in the design space that make different trade offs. E.g. Rust gives you memory safety through ownership, but you can't even make a doubly-linked list while staying within the ownership system. In a different point in the design space, Go has garbage collection, but that comes with its own trade offs. All of these might become obsolete when we have e.g. quantum computers. But in the meantime we are just playing with different trade offs, because we've captured all the low-hanging fruit decades ago.

nickpsecurity 8y ago
"E.g. Rust gives you memory safety through ownership, but you can't even make a doubly-linked list while staying within the ownership system." Your otherwise good comment presents this like all-or-nothing when comparing it to C. To start with, C and Rust are equivalent for anything it cant borrow-check. Then, it's better than C in safety or expressiveness from there. Second, C developers use plenty external libraries to supplement the language's capabilities, including with ASM breaking abstraction gap. Likewise, whatever Rust cant handle can be proven safe with external tool, wrapped in safe interface, and used from there. This has been done in languages from C to Haskell. So, there's different design points for sure but doubly-linked-list isnt an example of unfit for purpose vs C. If anything, that it's equal or better in safety making it a better instance in that design space. Likewise for Clay which was more C-like and used in device drivers.
- rayiner 8y ago
  But at the end of the day, I wouldn’t call it a categorical improvement over C because you still have to drop down to what is basically C to handle essential tasks like declaring circular data structures. Instead, it makes a special (but common) case of tree-like data structures safer to handle. This is no fault of Rust—it is a theoretical limitation. There is no single model that let’s you express arbitrary data structures, gives you memory safety, and doesn’t require runtime heap walking.

MisterTea 8y ago

> How in the world have we not moved on? We tried but have yet to give up. "It looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough." — Eric S. Raymond

justin66 8y ago

> BTW, his code was so, so pretty. Mine would have been ugly. Kids are far better coders than we were 30 years ago. I was crazy proud. I don't know what compiler you were using on Ultrix but C++ in that era was insanely bad.

Taniwha 8y ago
Ultrix was roughly about the same time as the first C++ (a preprocessor that made C) - people were still figuring out what good and bad C++ was
- jacksmith21006 8y ago
  Yes similar time frame but C++ first. I tended to be into the new thing so was into C++. It was mid 80s and C++ dates back to 1979 if memory serves.