Live data from Hacker News

Fixing C

embedded.com

41–50 of 123 posts

Re: Fixing C

#41
I wonder how this article has been able to make HN's home page... The main thing the author thinks about improving C is... replacing braces with keywords?

Re: Fixing C

#42

Earlier quoted context omitted.

There you go: struct much_improved_c { ... }; struct much_improved_c an_api_that_doesnt_suck() { ... };

I always found that unnatural in C and preferred the other way around: to pass the struct to populate as a pointer and keep the return code for tracking operation status/handlers

[deleted]

Re: Fixing C

#43
post #22
post #10

Oh god! This brings back memories of the nightmarish legacy code that I had to work on, a long time ago. The previous developer apparently liked Pascal and hated C. His principal header file had something like #define begin { #define end } and many other Pascalisms. As a result, his code did not look like C at all. IIRC, the code had gone unmaintained since the late 80's, which is not surprising in embedded systems.…

Isn't there the anecdote that the Bourne shell is written in this style?

I remember some famous name being very fond of ALGOL and so abused the preprocessor so his code would look like ALGOL. Makes you understand how so often you're one pretty printer away from another language.

Re: Fixing C

#44
If curly braces is his biggest issue, it might be better to take a hint from Go and enforce them to be required in anything other than third-party headers, and enforce a single style on the codebase.

Re: Fixing C

#45
post #22
post #10

Oh god! This brings back memories of the nightmarish legacy code that I had to work on, a long time ago. The previous developer apparently liked Pascal and hated C. His principal header file had something like #define begin { #define end } and many other Pascalisms. As a result, his code did not look like C at all. IIRC, the code had gone unmaintained since the late 80's, which is not surprising in embedded systems.…

Isn't there the anecdote that the Bourne shell is written in this style?

See for yourself: https://github.com/dspinellis/unix-history-repo/blob/Researc...

Re: Fixing C

#46
post #17

When I was reading I was thinking - if you like that kind of grammar just use Ada. And then later down he specifically mentions Ada. So - why not just use that? With Ada, it is straightforward to create the kind of tight, fast code you'd write in C. You can control your own garbage collection and it has a fabulous type system. And - unless you need templates - it can do pretty much everything C++ can do as well. I do…

If you are in the Boston area tomorrow you can ask him in person, he will be speaking at the Embedded Systems Conference: http://www.embeddedconf.com/boston/scheduler/session/mars-at... The full conference pass is $1300 but you can watch his session and many other sponsor sessions with the free pass.

[deleted]

Re: Fixing C

#47
post #18
post #13

C has many, many problems. Curly braces are really not one of them. If I could wave a magic wand and fix C I'd make arrays and strings know their size. Edit for the nitpickers: Yes, arrays decay to pointers and that's the real problem. Sorry.

Good news. Arrays have sizeof(arr)/sizeof(arr[0]) elements and strings have strlen(str) letters.

[deleted]

Re: Fixing C

#49
Of all the things you could fix in C, curly braces? I would have thought that the massive security issues, weird standard library design, non-existent module system, copious undefined behaviour, weak type system or risible package management might have merited some attention first.

Re: Fixing C

#50
post #29
post #17

When I was reading I was thinking - if you like that kind of grammar just use Ada. And then later down he specifically mentions Ada. So - why not just use that? With Ada, it is straightforward to create the kind of tight, fast code you'd write in C. You can control your own garbage collection and it has a fabulous type system. And - unless you need templates - it can do pretty much everything C++ can do as well. I do…

I think the main two reasons are: - Ada is in practice managed by AdaCore; compiler features may or may not migrate back to the free GNAT compiler. I understand that they are kind of stuck: they have their customer base, and any kind of opening up would cause revenue losses that may or may not be recovered by more customers. I think they are making the right choice - superficial as the reason may be, the syntax turns…

[deleted]
Post reply on HN