Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing C

embedded.com

Post reply on HN
Print view View original

51–60 of 123 posts

Re: Fixing C

#51

Post by userbinator »

tronje wrote: post #8

C, to me, requires a lot of discipline about good coding style and conventions. I personally like that a lot, even though, of course, it sometimes causes one to shoot oneself in the foot. But, and I can't point to exactly why, I don't think I want to change anything. Maybe Rust or something new will come along sometime soon to fix all the issues that exist with C. Oh, and for those who haven't seen it, there was a co…

I personally like that a lot, even though, of course, it sometimes causes one to shoot oneself in the foot. But, and I can't point to exactly why, I don't think I want to change anything.

I feel much the same way, and I think it's the general principle of freedom over security that makes it fun. You can do lots of things that other languages wouldn't allow, and despite not needing to most of the time, the fact that such power is there if you want to use it is what I like. It's a bit of a refreshing environment compared to all the other "safe" languages.

Re: Fixing C

#52

Post by enriquto »

eatonphil wrote: post #35
enriquto wrote: post #23

Closures. This is the only thing that I miss in C. I always want to declare local functions, and return pointers to them.

GNU C supports nested functions. Does that solve it (if you accept GCC lock-in)? https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

From GCC documentation: "If you try to call the nested function through its address after the containing function exits, all hell breaks loose."

I would definitely accept GCC lock-in, but so far GCC does not have this feature. Clang does, hoever, via _Blocks, but the syntax is not very C-like.

Re: Fixing C

#53

Post by RyanMcGreal »

Wouldn't a linter for C and a half-decent text editor address the author's issues about block formatting way less intrusively than trying to change the language syntax?

Re: Fixing C

#54

Post by adwn »

Of all the things in C that cause problems and that could be fixed by waving a magic wand, the author chose "curly braces"?! That betrays an immense lack of imagination! Worse, it shows that the author isn't even aware of the actual causes of lost productivity and bugs in C programs.

What about buffer overflows (it happens to the best of us)? Mounds of undefined behavior exploited by optimizing compilers (even in seemingly correct code)? A type system that is strict enough to get in one's way, but not strict/powerful enough for strong guarantees?

Some years ago I read a post on a forum for electronics/embedded programming, which basically said "The system of C header files is actually very good, because without it you would have to manually declare all functions you use." This article reminded me of that.

Re: Fixing C

#55

Post by progman »

This syntax comes close to Nim.

I am using Nim for years now, and it is much more convenient than C while retaining the same performance. C functions can be imported and used seemlessly. Nim offers several optional garbage collectors which can be turned off for embedded systems. Nim has a package manager (Babel), and Nim's macros which are powerful like Lisp macros (way ahead of C++ macros) make it possible to create special DSLs for test cases and webservers, or to use Perl's awesome regular expressions with native Perl syntax.

Homepage: http://nim-lang.org

Nim on Arduino: http://disconnected.systems/nim-on-arduino/

Embedded Stack Trace Profiler: http://nim-lang.org/docs/estp.html

Nim for scientific computing: http://rnduja.github.io/2015/10/21/scientific-nim/

A sinatra-like web framework for Nim: https://github.com/dom96/jester

"We just switched from Rust to Nim for a very large proprietary project": https://news.ycombinator.com/item?id=9050114

I know many programming languages and styles. Nim is one of the most amazing, powerful, practical and effective programming languages ever - a real gem. I am still wondering why so few people know about it. Probably just because of lack of promotion.

Re: Fixing C

#56

Post by optforfon »

There are a million problem with C that come before curly braces. So many of the people that venerate C either live in a reality distortion bubble or don't actually writing C. I've always found C a disaster for generating good assembly.

to start:

https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/C-Extensions.ht...

we see that bare C has:

- no vectorization/SIMD support

- no hinting at likely branches

- no way to prefetch memory

- no way to block inlining

- no actual inlining!

whoever decided that the compiler should be allowed to ignore the 'inline' keyword ....

additional issues off the top of my head:

- const != immutable so 'const' is relegated to being a keyword for generating compiler warning

- RVO is implicit.. so just pray it happens!

The language is frankly just too old. Half of those features probably just simply didn't exist in hardware when the language was designed

I'm desperate for a better language

Re: Fixing C

#57

Post by dom96 »

progman wrote: post #55

This syntax comes close to Nim. I am using Nim for years now, and it is much more convenient than C while retaining the same performance. C functions can be imported and used seemlessly. Nim offers several optional garbage collectors which can be turned off for embedded systems. Nim has a package manager (Babel), and Nim's macros which are powerful like Lisp macros (way ahead of C++ macros) make it possible to create…

> Nim has a package manager (Babel)

It's called Nimble now: https://github.com/nim-lang/nimble

Re: Fixing C

#58

Post by d3k »

The top change I would love to see in C is to have a way to have conditional macros, that could produce efficient statically compiled chunk of texts of defines. I think you can get some of that in C++ with templates, but without the whole C++.

Re: Fixing C

#59

Post by veli_joza »

mfukar wrote: post #38
veli_joza wrote: post #30

Earlier quoted context omitted.

You can sizeof them if the declaration is in scope. If you pass them as function argument, this information is not obtainable inside function. You have to pass length as well. This is not very elegant and sometimes you elect to process them without using functions just because you can iterate them easier.

Now, at one point, you stopped talking about arrays and started talking about pointers.

Exactly. When array is passed into function, you lose length information and array construct is reduced to pointer. Array syntax is just synthetic sugar for dereferencing pointer with offset.

Re: Fixing C

#60

Post by rkangel »

adwn wrote: post #54

Of all the things in C that cause problems and that could be fixed by waving a magic wand, the author chose "curly braces"?! That betrays an immense lack of imagination! Worse, it shows that the author isn't even aware of the actual causes of lost productivity and bugs in C programs. What about buffer overflows (it happens to the best of us)? Mounds of undefined behavior exploited by optimizing compilers (even in see…

Yes - the smallest change to C that I'd make is to make it strongly typed. The implicit coercions seem so at odds with the rest of the design of C (where everything is explicit).
Post reply on HN