Live data from Hacker News

"No way to prevent this" say users of only language where this regularly happens

xeiaso.net

71–80 of 342 posts

Re: "No way to prevent this" say users of only language where this regularly happens

#71
post #22

More broadly: > "No way to prevent $THIS" say users of only language where $THIS regularly happens A weird psychological quirk I've noticed (of myself, and others) is we'll often exhibit a sort of 'programming language xenophobia', where we apathetically accept (or don't even notice) unpleasantries of our language of choice, yet be quite averse to the unpleasantries of other languages. Maybe it's due to sunk cost; ti…

I would rather have unpleasantries that make the language safer vs unpleasantries that make it more vulnerable. Especially when the unpleasantries in question don’t even make the language easier to use.

Re: "No way to prevent this" say users of only language where this regularly happens

#72
post #25

Earlier quoted context omitted.

I have a longer nuanced post to write out at some point about my feelings here, but here's the cliff's notes: We should not be developing new projects in C, and we should make it politically hard to make new projects written in C in distribution repositories. C is going to stay around for a long time and that's okay, but there are so many inherent problems of its design and implementation that make it unsuited for un…

[flagged]

Thank you for demonstrating why I haven't written that longer post yet. I'd just be torn apart and berated for bothering to express nuance.

Re: "No way to prevent this" say users of only language where this regularly happens

#73
post #25

Earlier quoted context omitted.

I have a longer nuanced post to write out at some point about my feelings here, but here's the cliff's notes: We should not be developing new projects in C, and we should make it politically hard to make new projects written in C in distribution repositories. C is going to stay around for a long time and that's okay, but there are so many inherent problems of its design and implementation that make it unsuited for un…

[flagged]

That's not how society progress.

At some point you just disallow horses to go onto the high-speed road, and aren't waiting for literally every last farmer to sell their horse over a car.

Re: "No way to prevent this" say users of only language where this regularly happens

#74

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

I program MCUs as a hobby. I wish I could use something better than C. Even C++ with RAII would be better. But somehow, even C++ support is spotty, with unsupported features, broken debugging, etc. for seemingly no reason. And all device-specific libraries are written in C, so I'd have to write C++ wrappers for every little thing. Send help...

Re: "No way to prevent this" say users of only language where this regularly happens

#75

I thought it was going to be about JS and npm, given some of their fiascos [1][2][3] [1] https://qz.com/646467/how-one-programmer-broke-the-internet-... [2] https://www.bleepingcomputer.com/news/security/dev-corrupts-... [3] https://www.sonatype.com/blog/everything-matters-why-the-npm...

`this` was mostly prevented in JS with the introduction of arrow function expressions

Re: "No way to prevent this" say users of only language where this regularly happens

#76
post #64

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

Eh, Rust would be fine if not for the fact that it's too opinionated. Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times

Unfortunately you have to pick 2 out of:

- Lack of restrictions

- Safety

- Performance

If you choose safety and no restriction, you pay the price in performance (for GC etc.)

Re: "No way to prevent this" say users of only language where this regularly happens

#77

Alternative headline should be "But I have been taught that using C++ makes me the better programmer" because the stereotypes of echo chambers on the internet raised a lot of unreflected programmers to be this way. There is a place for C, where there's no alternative. But that place is where 99% of programmers never work, because they are not doing kernel nor firmware development (which, in the meantime, also has a l…

>But that place is where 99% of programmers never work, because they are not doing kernel development

Certain embedded targets are also legitimate use cases for C. For example, I am currently working on a project using an 8051 microcontroller. Aside from using assembly – which obviously isn't safe either – there is no practical alternative to using C. Rust may be making inroads for 32-bit targets, but will likely never be able to target an 8051.

Re: "No way to prevent this" say users of only language where this regularly happens

#78
post #30
post #25

Earlier quoted context omitted.

I have a longer nuanced post to write out at some point about my feelings here, but here's the cliff's notes: We should not be developing new projects in C, and we should make it politically hard to make new projects written in C in distribution repositories. C is going to stay around for a long time and that's okay, but there are so many inherent problems of its design and implementation that make it unsuited for un…

> We should not be developing new projects in C I would give at least embedded development a pass, since you rarely do have a choice there

It's difficult, because "embedded not networked" is an environment where security risks are low, but "embedded networked" is a really nasty environment of haunted routers and abandoned IoT devices.

Is it acceptable to risk buffer overruns on the HTTP server running on an insulin pump?

Re: "No way to prevent this" say users of only language where this regularly happens

#79

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

I program MCUs as a hobby. I wish I could use something better than C. Even C++ with RAII would be better. But somehow, even C++ support is spotty, with unsupported features, broken debugging, etc. for seemingly no reason. And all device-specific libraries are written in C, so I'd have to write C++ wrappers for every little thing. Send help...

That's why I said "almost anything". I am aware that f.ex. kernel development and embedded work is still firmly in the C domain.

I am not evangelizing for Rust, Golang or anything in particular. I am evangelizing for periodically asking yourself "Am I still using the best tool for the job?" which most people never do.

Re: "No way to prevent this" say users of only language where this regularly happens

#80
Oh no ... a bug in a C program. This easy bashing on existing C programs is getting boring and annoying.

Write a new userspace program? Use anything else, all language shave flaws so pick one which supports the features you need. Want to quickly write something because you are not allowed to rewrite the entire ecosystem you need into a new language since the project will go massively over budged: Use what you can and what's available and accept the risks, which is the 99th percentile of software.

Post reply on HN