44 ms·

One of the things I tend to think about these days is return on investment. I spent several years at the beginning of my career being a bad and then mediocre C

One of the things I tend to think about these days is return on investment. I spent several years at the beginning of my career being a bad and then mediocre C programmer, and once I found a few other languages, I got the sense that being a mediocre-to-good programmer in these languages would be much easier, and that seems to have been borne out. Late into a career investing in other areas, what's the advantage of becoming a good C programmer? Especially in a time where Rust and Go are viable options?

jason0597 7y ago
Rust isn't viable for embedded platforms, at least not yet. It's not as easy to compile it to the most obscure ISAs as C, and the little support it has for stuff like STM32 is restricted to just that group of microcontrollers and doesn't support the entire ARM range. Maybe in the future? I'm looking forward to that day! Go is probably never going to run on microcontrollers due to its very big overhead. C perfectly matches on top of the hardware of a processor. Every single design decision about C was made with the computer in mind. Memory, pointers, stack, call stack, returns, arguments, just everything is so excellently designed. Even Linus Torvalds says so! https://www.youtube.com/watch?v=CYvJPra7Ebk https://www.youtube.com/watch?v=CYvJPra7Ebk If I were to make one change to C, it would be to completely rip out the #include system and bring a proper modules system. Apart from that, it's pretty much perfect.
- manfredo 7y ago
  > Go is probably never going to run on microcontrollers due to its very big overhead. My employer runs go on micro controllers. Definitely suboptimal, but as long as the cost of increasing hardware capacity to accommodate Go is feasible then it's a viable option.
  - jason0597 7y ago
    Isn't it counter productive to go out of your way to find better hardware to fit your language choice? Why not choose a lighter language?
    - manfredo 7y ago
      Libraries might be easier to use, and you can use the same language on the server and hardware.
- totalperspectiv 7y ago
  TinyGo recently became an official project and seems extremely successful.
- zenhack 7y ago
  > Every single design decision about C was made with the computer in mind. The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: First, C was designed for single-pass compilers, because the PDP-7 it was designed for was too small to actually run much fancier of a compiler. So C is seriously sub-optimal for optimization in a lot of ways (because the assumption was you weren't going to do compiler optimizations anyway), and there are some user-visible warts like forward declarations that are completely unnecessary today. Second, the relevant questions with regard to CPU performance have changed a lot. Most notably: - CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything - Parallelism everywhere. Multiple cores, but also deeper instruction pipelines and other such things. The way those things map to C is completely implicit; they don't show up in the language at all, and getting the machine to do what you want requires knowing things that the code wouldn't suggest at all. I think if the same people had designed a language for a similar niche today's hardware, a lot of things would be different.
  - ori_b 7y ago
    > The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: The problem with this line of argument: assembly has also not changed. If the things you talk about mattered, we would be using a different assembly.
    - fctorial 7y ago
      > we would be using a different assembly. We are. It's called microcode.
      - ori_b 7y ago
        And, you write microcode?
  - nomel 7y ago
    > CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything > they don't show up in the language at all... requires knowing things that the code wouldn't suggest at all I'm utterly confused at this. It's trivial to layout memory as you please, where you please, very directly, in C. Set a pointer to and address and write to it. Better yet, I can define a packed struct that maps to a peripheral, point it to its memory address from a data sheet, and have a nice human readable way of controlling it: MyPIECDevice.sample_rate = 2000. Keeping things physically close in memory has always been a strong requirement, as long as cache, pages, and larger than one-byte-memory buses have existed.
- anonsivalley652 7y ago
  > Rust isn't viable for embedded platforms, at least not yet. no_std allows the important hooks of panicking, output and allocation to be implemented by the user. It's also very easy to put in hard-coded pointers that represent memory-mapped hardware. And there's no GC. Furthermore, it's entirely possible to convert only a portion of a project to using Rust while working to gradually to replace/reimplement. > If I were to make one change to C, it would be to completely rip out the #include system [preprocessor] and bring a proper modules system. Congratulations, you've just reinvented Java, D, Rust and Go. > Apart from that, it's pretty much perfect. This seems like a religious opinion rather than having understanding of different paradigms. Have you been paying attention to why Java, Erlang, Go, Rust and exist? Rust has numerous advantages over C that eliminate entire categories of problems without sacrificing speed. If you can't see that, then maybe you don't want to see it.
- billfruit 7y ago
  While it is true that C perfectly matches the hardware, it imperfectly matches the rich software abstractions which are needed for moderate and large software. The lack of namespaces, sane object creation, destruction features etc, makes programming tedious. A large proportion of code in many large C programs go into recreating imperfectly the features that are by default provided by richer programming systems, and that repeats for every large program you do. It quickly becomes boring and unenlightening, to recreate an exception handling mechanism or data structure implementation for the nth time. Why would anyone not prefer not having to focus on the mere infrastructure, and rather direct directions on the interesting problems to be solved. Another thing is that large C code bases tend to become ensconced in layers of preprocessor macros, which I think is a hack-y way of doing things.
- sedachv 7y ago
  > Every single design decision about C was made with the computer in mind. A computer. The PDP-11. C was a terrible fit for a lot of the popular contemporary architectures when it was designed (PDP-10, Burroughs large systems, UNIVAC 1100, CDC mainframes, HP 3000), and continued to be a very poor fit for many computers in the 1980s (segmented 8086 and 286, 6502, AS/400, Lisp Machines except for Xerox, Connection Machine, Tandem, Novix/RTX, Transputer, etc.).
derekp7 7y ago
For me it is a smaller dependancy stack. For example I needed some tooling that worked on RHEL/CentOS, back to version 4.x and 3.x (yes, I know). Also, someone at work wanted me to get into Swift... They had Ubuntu packages but nothing for RHEL or Fedora (that may have changed now though).
- saghm 7y ago
  No idea when they were added, but there are Fedora packages for Swift now under the name "swift-lang". I don't use Fedora personally, but from what I can tell, they should be available in the default package repositories with dnf.
- kbenson 7y ago
  If you can spare the overhead, Perl is a good option for some of these. Much of the CPAN ecosystem will still work, and anything written that doesn't require much/any external modules it will almost definitely work with no changes. There are plenty of Perl scripts kicking around from that time, and earlier. The biggest problem would likely bad code quality standards of earlier periods (lots of budding programmers in the dot com boom wrote a lot of poorly done code that survives today, which is responsible at least in part for Perls reputation as write only), but if you're just deploying your own code, that's less of an issue. Perl can be written to be readable and obvious, it just takes control. In that respect, I imagine it's a lot like C.
GuB-42 7y ago
C is still king in embedded systems. It is also great at making you aware of the machine. In C, very little is happening behind the scene. If you want something to happen, you need write some code. Objects will not initialize themselves, allocated memory will not free itself, no smart reference mechanisms, just explicit pointers. This understanding of the machine will help understanding why higher level langages behave the way they do. But anyways, programming skills is not so much about the language. A good programmer in one language will be a good programmer in any other language very quickly. But still, if I have to hire a programmer for a project in a language he doesn't know, I will tend to prefer C programmers over those who only use higher level languages. The reason is that C programmers may do things that are not pretty, but they usually understand what they are doing, people who are only accustomed to some higher level language may come up with better designs, but write code that make no sense.
- Mike345845 7y ago
  > It is also great at making you aware of the machine. In C, very little is happening behind the scene. This is not true. It hasn't been true for decades. C is an abstract high level language on modern processors. https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479
  - porknubbins 7y ago
    True, but if it is still possible to be a C programmer who can more or less imagine what assembly will be generated (at lower levels of optimization at least) by their C code, then isn't the real issue that x86 assembly abstracts away a lot of hardware info about caches, pipelines, microcodes etc? In that case how can a low level exist on x86?
    - UncleMeat 7y ago
      I'm not sure that's true. There was a highly upvoted post recently on both HN and /r/programming that claimed to have a better sorting algo than libc's sort. After hundreds of comments across both forums, looking into compiler explorer showed that the key difference was inlining. As a C++ person, basically all micro-optimizations start at "look at the damn assembly" since people really suck at predicting what code will actually be generated.
cozzyd 7y ago
The C ABI is still king.
kragen 7y ago
If you are troubleshooting software problems in any language (except, usually, Java), sooner or later you dig down and hit C or C++. In those cases knowing C means you can solve the problem. There are a lot of libraries written in C, like, thousands in Debian alone. You can use them from any language, but sometimes you need to write a little bit of glue C to get that to work. Sometimes it's less painful to just write your program in C++ or Objective-C so you don't have to debug your glue C. If you want to write a library that can be used from any language, basically your options are C, C++ (but realistically its C subset), and Rust. Getting things to work all the time is easier in Rust than in C or C++. Getting things to work some of the time is easier in C. But for most of these things it's probably adequate to be a mediocre C programmer. Unless your mediocrity is manifested in spending a week on tracking down a bug that should have taken an hour, maybe.
- firethief 7y ago
  > Getting things to work all the time is easier in Rust than in C or C++. Getting things to work some of the time is easier in C. I think this is a good generalization of the learning curves of the languages, but not necessarily productivity for an experienced developer. Rust has modern amenities like pattern matching, generics and a package manager.
  - kragen 7y ago
    You may be right; I'm still a novice at Rust. I've heard people with substantially more experience in Rust telling me they still find it slow going compared to C, but they may not be experts, and they may not be representative. And surely in domains like compilers, which benefit more from pattern matching and automated storage reclamation, Rust would have a significant edge.
Waterluvian 7y ago
My take is this: C is necessary in some paradigms/domains. But that list has been shrinking as other languages are born and mature. Learning C, like learning most things, will still certainly lend itself to lots of things you do, even if you're not using C. Why learn C? Because you want to do stuff on that list or because you feel like it. Why not learn something else instead? It may very well be that there's more worthwhile things to learn depending on your goals.
fortran77 7y ago
Oh come on now. I will develop in "safe" languages where possible (my favorites are F# and Erlang), but when I need to do something on the hardware, I still use C (and C++). Rust and Go are not viable options for everything, especially when you need complete control. Why does the Rust community have to make every discussion about Rust?
- UK-Al05 7y ago
  What can c do that rust can't?
zelly 7y ago
> Late into a career investing in other areas, what's the advantage of becoming a good C programmer? Especially in a time where Rust and Go are viable options? It is the most popular programming language. There is a lot of code written in it. Most jobs involve maintaining extant code. So it's good for that. It's safe to say there will be a need for C programmers for the next 100 years.

jason0597 7y ago

Rust isn't viable for embedded platforms, at least not yet. It's not as easy to compile it to the most obscure ISAs as C, and the little support it has for stuff like STM32 is restricted to just that group of microcontrollers and doesn't support the entire ARM range. Maybe in the future? I'm looking forward to that day! Go is probably never going to run on microcontrollers due to its very big overhead. C perfectly matches on top of the hardware of a processor. Every single design decision about C was made with the computer in mind. Memory, pointers, stack, call stack, returns, arguments, just everything is so excellently designed. Even Linus Torvalds says so! https://www.youtube.com/watch?v=CYvJPra7Ebk https://www.youtube.com/watch?v=CYvJPra7Ebk If I were to make one change to C, it would be to completely rip out the #include system and bring a proper modules system. Apart from that, it's pretty much perfect.

manfredo 7y ago
> Go is probably never going to run on microcontrollers due to its very big overhead. My employer runs go on micro controllers. Definitely suboptimal, but as long as the cost of increasing hardware capacity to accommodate Go is feasible then it's a viable option.
- jason0597 7y ago
  Isn't it counter productive to go out of your way to find better hardware to fit your language choice? Why not choose a lighter language?
  - manfredo 7y ago
    Libraries might be easier to use, and you can use the same language on the server and hardware.
totalperspectiv 7y ago
TinyGo recently became an official project and seems extremely successful.
zenhack 7y ago
> Every single design decision about C was made with the computer in mind. The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: First, C was designed for single-pass compilers, because the PDP-7 it was designed for was too small to actually run much fancier of a compiler. So C is seriously sub-optimal for optimization in a lot of ways (because the assumption was you weren't going to do compiler optimizations anyway), and there are some user-visible warts like forward declarations that are completely unnecessary today. Second, the relevant questions with regard to CPU performance have changed a lot. Most notably: - CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything - Parallelism everywhere. Multiple cores, but also deeper instruction pipelines and other such things. The way those things map to C is completely implicit; they don't show up in the language at all, and getting the machine to do what you want requires knowing things that the code wouldn't suggest at all. I think if the same people had designed a language for a similar niche today's hardware, a lot of things would be different.
- ori_b 7y ago
  > The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: The problem with this line of argument: assembly has also not changed. If the things you talk about mattered, we would be using a different assembly.
  - fctorial 7y ago
    > we would be using a different assembly. We are. It's called microcode.
    - ori_b 7y ago
      And, you write microcode?
- nomel 7y ago
  > CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything > they don't show up in the language at all... requires knowing things that the code wouldn't suggest at all I'm utterly confused at this. It's trivial to layout memory as you please, where you please, very directly, in C. Set a pointer to and address and write to it. Better yet, I can define a packed struct that maps to a peripheral, point it to its memory address from a data sheet, and have a nice human readable way of controlling it: MyPIECDevice.sample_rate = 2000. Keeping things physically close in memory has always been a strong requirement, as long as cache, pages, and larger than one-byte-memory buses have existed.
anonsivalley652 7y ago
> Rust isn't viable for embedded platforms, at least not yet. no_std allows the important hooks of panicking, output and allocation to be implemented by the user. It's also very easy to put in hard-coded pointers that represent memory-mapped hardware. And there's no GC. Furthermore, it's entirely possible to convert only a portion of a project to using Rust while working to gradually to replace/reimplement. > If I were to make one change to C, it would be to completely rip out the #include system [preprocessor] and bring a proper modules system. Congratulations, you've just reinvented Java, D, Rust and Go. > Apart from that, it's pretty much perfect. This seems like a religious opinion rather than having understanding of different paradigms. Have you been paying attention to why Java, Erlang, Go, Rust and exist? Rust has numerous advantages over C that eliminate entire categories of problems without sacrificing speed. If you can't see that, then maybe you don't want to see it.
billfruit 7y ago
While it is true that C perfectly matches the hardware, it imperfectly matches the rich software abstractions which are needed for moderate and large software. The lack of namespaces, sane object creation, destruction features etc, makes programming tedious. A large proportion of code in many large C programs go into recreating imperfectly the features that are by default provided by richer programming systems, and that repeats for every large program you do. It quickly becomes boring and unenlightening, to recreate an exception handling mechanism or data structure implementation for the nth time. Why would anyone not prefer not having to focus on the mere infrastructure, and rather direct directions on the interesting problems to be solved. Another thing is that large C code bases tend to become ensconced in layers of preprocessor macros, which I think is a hack-y way of doing things.
sedachv 7y ago
> Every single design decision about C was made with the computer in mind. A computer. The PDP-11. C was a terrible fit for a lot of the popular contemporary architectures when it was designed (PDP-10, Burroughs large systems, UNIVAC 1100, CDC mainframes, HP 3000), and continued to be a very poor fit for many computers in the 1980s (segmented 8086 and 286, 6502, AS/400, Lisp Machines except for Xerox, Connection Machine, Tandem, Novix/RTX, Transputer, etc.).

derekp7 7y ago

For me it is a smaller dependancy stack. For example I needed some tooling that worked on RHEL/CentOS, back to version 4.x and 3.x (yes, I know). Also, someone at work wanted me to get into Swift... They had Ubuntu packages but nothing for RHEL or Fedora (that may have changed now though).

saghm 7y ago
No idea when they were added, but there are Fedora packages for Swift now under the name "swift-lang". I don't use Fedora personally, but from what I can tell, they should be available in the default package repositories with dnf.
kbenson 7y ago
If you can spare the overhead, Perl is a good option for some of these. Much of the CPAN ecosystem will still work, and anything written that doesn't require much/any external modules it will almost definitely work with no changes. There are plenty of Perl scripts kicking around from that time, and earlier. The biggest problem would likely bad code quality standards of earlier periods (lots of budding programmers in the dot com boom wrote a lot of poorly done code that survives today, which is responsible at least in part for Perls reputation as write only), but if you're just deploying your own code, that's less of an issue. Perl can be written to be readable and obvious, it just takes control. In that respect, I imagine it's a lot like C.

GuB-42 7y ago

C is still king in embedded systems. It is also great at making you aware of the machine. In C, very little is happening behind the scene. If you want something to happen, you need write some code. Objects will not initialize themselves, allocated memory will not free itself, no smart reference mechanisms, just explicit pointers. This understanding of the machine will help understanding why higher level langages behave the way they do. But anyways, programming skills is not so much about the language. A good programmer in one language will be a good programmer in any other language very quickly. But still, if I have to hire a programmer for a project in a language he doesn't know, I will tend to prefer C programmers over those who only use higher level languages. The reason is that C programmers may do things that are not pretty, but they usually understand what they are doing, people who are only accustomed to some higher level language may come up with better designs, but write code that make no sense.

Mike345845 7y ago
> It is also great at making you aware of the machine. In C, very little is happening behind the scene. This is not true. It hasn't been true for decades. C is an abstract high level language on modern processors. https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479
- porknubbins 7y ago
  True, but if it is still possible to be a C programmer who can more or less imagine what assembly will be generated (at lower levels of optimization at least) by their C code, then isn't the real issue that x86 assembly abstracts away a lot of hardware info about caches, pipelines, microcodes etc? In that case how can a low level exist on x86?
  - UncleMeat 7y ago
    I'm not sure that's true. There was a highly upvoted post recently on both HN and /r/programming that claimed to have a better sorting algo than libc's sort. After hundreds of comments across both forums, looking into compiler explorer showed that the key difference was inlining. As a C++ person, basically all micro-optimizations start at "look at the damn assembly" since people really suck at predicting what code will actually be generated.

cozzyd 7y ago

The C ABI is still king.

kragen 7y ago

If you are troubleshooting software problems in any language (except, usually, Java), sooner or later you dig down and hit C or C++. In those cases knowing C means you can solve the problem. There are a lot of libraries written in C, like, thousands in Debian alone. You can use them from any language, but sometimes you need to write a little bit of glue C to get that to work. Sometimes it's less painful to just write your program in C++ or Objective-C so you don't have to debug your glue C. If you want to write a library that can be used from any language, basically your options are C, C++ (but realistically its C subset), and Rust. Getting things to work all the time is easier in Rust than in C or C++. Getting things to work some of the time is easier in C. But for most of these things it's probably adequate to be a mediocre C programmer. Unless your mediocrity is manifested in spending a week on tracking down a bug that should have taken an hour, maybe.

firethief 7y ago
> Getting things to work all the time is easier in Rust than in C or C++. Getting things to work some of the time is easier in C. I think this is a good generalization of the learning curves of the languages, but not necessarily productivity for an experienced developer. Rust has modern amenities like pattern matching, generics and a package manager.
- kragen 7y ago
  You may be right; I'm still a novice at Rust. I've heard people with substantially more experience in Rust telling me they still find it slow going compared to C, but they may not be experts, and they may not be representative. And surely in domains like compilers, which benefit more from pattern matching and automated storage reclamation, Rust would have a significant edge.

Waterluvian 7y ago

My take is this: C is necessary in some paradigms/domains. But that list has been shrinking as other languages are born and mature. Learning C, like learning most things, will still certainly lend itself to lots of things you do, even if you're not using C. Why learn C? Because you want to do stuff on that list or because you feel like it. Why not learn something else instead? It may very well be that there's more worthwhile things to learn depending on your goals.

fortran77 7y ago

Oh come on now. I will develop in "safe" languages where possible (my favorites are F# and Erlang), but when I need to do something on the hardware, I still use C (and C++). Rust and Go are not viable options for everything, especially when you need complete control. Why does the Rust community have to make every discussion about Rust?

UK-Al05 7y ago
What can c do that rust can't?

zelly 7y ago

> Late into a career investing in other areas, what's the advantage of becoming a good C programmer? Especially in a time where Rust and Go are viable options? It is the most popular programming language. There is a lot of code written in it. Most jobs involve maintaining extant code. So it's good for that. It's safe to say there will be a need for C programmers for the next 100 years.