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

Problems of C, and how Zig addresses them

avestura.dev

Post reply on HN
Print view View original

271–280 of 290 posts

Re: Problems of C, and how Zig addresses them

#271

Post by Mawr »

avgcorrection wrote: post #215
throwawaymaths wrote: post #184

Earlier quoted context omitted.

The problem with operator overloading is not really numericity, IMO. The problems are: - hidden control flow (function calls should look like function calls, an operation should never mask a function call) - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

> hidden control flow (function calls should look like function calls, an operation should never mask a function call) An operator is either a function call or some simple built-in operation. Thus not hidden. That syntactic elements that consist of symbols rather than alnum and that are used as prefix or infix operators are necessarily “not a function call” is just a rule that can be changed.

> An operator is either a function call or some simple built-in operation.

In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is.

It's like a self-driving car that's safe 99.999% of the time but still requires you to continuously pay attention to take over at a second's notice.

Humans just don't work like that.

Re: Problems of C, and how Zig addresses them

#272

Post by IshKebab »

coliveira wrote: post #264
xigoi wrote: post #263

Earlier quoted context omitted.

It would still be good if it was written in a different language. Probably even better because the developers would have more time to improve the software instead of reinventing wheels, writing boilerplate code and chasing down segfaults.

> It would still be good if it was written in a different language. But it wasn't, C made all these software tools possible.

No it didn't. C happened to be the most popular language for a long time but that doesn't mean people couldn't have written software without it, or that if it hasn't been so popular a better language wouldn't have arisen.

English is very popular but you wouldn't say "English is what made all those books possible" would you?

Re: Problems of C, and how Zig addresses them

#273

Post by eska »

pixelpoet wrote: post #162
Gibbon1 wrote: post #136

Earlier quoted context omitted.

Maybe I'm small brained but built in vector types align with heavily platform optimized libraries. Meaning you don't want this stuff implemented in the compilers front end. You want it handled in the compilers back end.

Performance is equivalent in both representations, but the important thing is being able to write vec4 c = a * 4 + b; instead of vec4 c = vec4_add(vec4_mul(a, 4), b); i.e. infix vs postfix order, with simple * and +/- operators etc. I would very much like to appeal to the Zig authors to see the beauty in the former expression compared to the latter, for a huge class of real-world mathematical applications.

If this wasn’t math code we’d refactor such code into helper functions, but somehow when it’s math we refuse to.

vec4 c = a * 4 + b;

vec4 c = vec4_add(vec4_mul(a, 4), b);

vec4 c = vec4_fma(4, a, b);

Re: Problems of C, and how Zig addresses them

#274

Post by avgcorrection »

Mawr wrote: post #271
avgcorrection wrote: post #215

Earlier quoted context omitted.

> hidden control flow (function calls should look like function calls, an operation should never mask a function call) An operator is either a function call or some simple built-in operation. Thus not hidden. That syntactic elements that consist of symbols rather than alnum and that are used as prefix or infix operators are necessarily “not a function call” is just a rule that can be changed.

> An operator is either a function call or some simple built-in operation. In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is. It's like a self-driving car that's safe 99.999% of the time but still requires you to continuously pay attention to take over at a second's notice. Humans just don't work like that.

> In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is.

Noo it isn’t. Many languages use something like `+` for string concatenation. Maybe list concatenation.

Re: Problems of C, and how Zig addresses them

#275

Post by coliveira »

IshKebab wrote: post #272
coliveira wrote: post #264

Earlier quoted context omitted.

> It would still be good if it was written in a different language. But it wasn't, C made all these software tools possible.

No it didn't. C happened to be the most popular language for a long time but that doesn't mean people couldn't have written software without it, or that if it hasn't been so popular a better language wouldn't have arisen. English is very popular but you wouldn't say "English is what made all those books possible" would you?

Yes it did and continues making it possible. Several of the largest codebases in the world are written in C.

Re: Problems of C, and how Zig addresses them

#276

Post by Dwedit »

anon-3988 wrote: post #232
Dwedit wrote: post #97

One thing Zig is missing is Exception Handling. Now before you complain about exception handling grossly bloating the size of a program, know that there are ways to trigger exceptions that do not involve the "throw" keyword. You get processor exceptions when you access a bad pointer, divide by 0, etc. If you don't want the program to instantly terminate, you need to be able to handle those exceptions. So far, it seem…

I am curious why anyone still thinks that exception is superior/better/desirable than a simple typed functions (like Result or Option ). > You get processor exceptions when you access a bad pointer, divide by 0, etc. If you don't want the program to instantly terminate, you need to be able to handle those exceptions. The processor does a lot of other things too, all of these functions can simply be wrapped with the a…

Everything mentioned in this post relates to API level, for code that you control. You can pick your favorite type for optional values with the possibility of an error.

Exceptions, on the other hand, can come from code you don't control. Some DLL that you call into doesn't care if you like Option better, it's still going to throw an exception. It could be designed to "throw" using the C++ exception syntax, or it could simply be dereferncing a null pointer or dividing by zero, causing an exception.

So then the issue becomes support for catching the exceptions caused by code outside of your control.

One option is to do nothing and just let the program die.

The other option is to catch the exception, automatically save the user's work, then restart the program.

Re: Problems of C, and how Zig addresses them

#277

Post by anon-3988 »

Dwedit wrote: post #276
anon-3988 wrote: post #232

Earlier quoted context omitted.

I am curious why anyone still thinks that exception is superior/better/desirable than a simple typed functions (like Result or Option ). > You get processor exceptions when you access a bad pointer, divide by 0, etc. If you don't want the program to instantly terminate, you need to be able to handle those exceptions. The processor does a lot of other things too, all of these functions can simply be wrapped with the a…

Everything mentioned in this post relates to API level, for code that you control. You can pick your favorite type for optional values with the possibility of an error. Exceptions, on the other hand, can come from code you don't control. Some DLL that you call into doesn't care if you like Option better, it's still going to throw an exception. It could be designed to "throw" using the C++ exception syntax, or it coul…

I see, but isn't exceptions implementation specific? How does language X knows how some random binary/DLL is going to throw an exception? What kind of object does it throw? What does it look like? How big is it? How many nested exceptions are there?

Re: Problems of C, and how Zig addresses them

#278

Post by Dwedit »

anon-3988 wrote: post #277
Dwedit wrote: post #276

Earlier quoted context omitted.

Everything mentioned in this post relates to API level, for code that you control. You can pick your favorite type for optional values with the possibility of an error. Exceptions, on the other hand, can come from code you don't control. Some DLL that you call into doesn't care if you like Option better, it's still going to throw an exception. It could be designed to "throw" using the C++ exception syntax, or it coul…

I see, but isn't exceptions implementation specific? How does language X knows how some random binary/DLL is going to throw an exception? What kind of object does it throw? What does it look like? How big is it? How many nested exceptions are there?

Windows has an ABI for exceptions, I don't know about Linux.

Re: Problems of C, and how Zig addresses them

#279

Post by IshKebab »

coliveira wrote: post #275
IshKebab wrote: post #272

Earlier quoted context omitted.

No it didn't. C happened to be the most popular language for a long time but that doesn't mean people couldn't have written software without it, or that if it hasn't been so popular a better language wouldn't have arisen. English is very popular but you wouldn't say "English is what made all those books possible" would you?

Yes it did and continues making it possible. Several of the largest codebases in the world are written in C.

To reiterate, C didn't make it possible to write those codebases just because they happen to be written in C.

Re: Problems of C, and how Zig addresses them

#280

Post by up2isomorphism »

travisgriggs wrote: post #18

Tangentially... I'm grateful that these new batches of systems languages have chosen to use the u8, i32, etc, style integer types. Rather than the uint8_t and int32_t style. First thing I do in any of my low level embedded C projects is put in the various uNN/iNN types.

It is couple of lines of typedef, what’s the big deal.
Post reply on HN