😅😅😅

Also C right?

*C
because good luck writing an OS kernel in JavaScript

@kyntak yupp bro...

Try installing fucking JS framework on a freaking atmega...

The problem is the Law of Conservation of Suck:

Changing programming languages per platform sucks, but languages that are available for every platform suck in themselves just as much.

Node.js !== JS?

Who says that. You'd be hard pressed to find one that doesn't run on all platforms nowadays. We don't write assembly anymore.

c, c++, lua, python, java, c#, javascript. Everything runs everywhere, even though some may requre a little magic (Like c)

This kid knows what he is talking about!

https://destroyallsoftware.com/talk...

@AlgoRythm you know...all that runs in Javascript now. Asm.js no joke. Overhead makes it ridiculous. But we are getting to where compilers can transpile to anything. RISC to x86 and vs versa. C to Javascript. Etc...

@Fast-Nop C and C++ are available everywhere and do not suck at all.

@AlgoRythm What magic?

@Yamakuzure I've done pure C GUI programming under GEM and Xwindow back then, and it did suck. Tons of stupid undefined behaviour suck because most of it should have been implementation defined, array-to-pointer-decay sucks, and strings also suck.

C++ is an abomination that sucks everywhere because it's too complex. Nobody in their right mind thinks that complexity is a good thing so every shop uses a subset, but a different one so that you lose programmer portability. Heaven forbid not using subsetting because then nobody else will be able to read that code, except a handful of language experts that no real shop can afford. The instable ABI sucks especially for commercial closed source stuff, and the compile times are insane. On top of that, there's still the undefined behaviour suck from C. And many C++ programmers suck because of the Java style "no idea how it's implemented, but I vaguely think that this one out of ten ways might be right" stance.

So there's the suck. ^^

@Fast-Nop Oh wow! That was a lot of suck.
Well, nothing of that had to do with the languages, only with bad user decisions, but I totally see why you are fed up with them. 😉

@Yamakuzure well the bad language design aspects aren't from the users, it's from the languages. Still, I like C best out of all despite it's suck. I'd say e.g. Pascal is comparable to C, but don't even get me started on Pascal because that would escalate into a full-blown rant. ;-)

@Fast-Nop Oh, yes, pleeeeease!

I never had Pure Olde Pascal. TurboPascal at school and Delphi 5 later at work was all.

Well, I think this is a purely subjective thing based on personal experience.
In my eyes the two most sucking languages are C# and Java. *shrug*

@AlgoRythm we don't write assembly anymore? Speak for yourself

@Yamakuzure languages are supposed to 'correct' or 'suggest' bad user decisions. That's the point of language design, not to only make things possible, but to make them effective and ergonomic.

@kyntak correction. that is the point of frameworks. Many frameworks can be used. Most run under one language. Some run under multiple. Some leave it up to you and have no framework by default. Learn SOLID and abandon DRY. Or write smaller modules (thus combining both).

Just because you use a bad framework, doesn’t mean it’s a bad language (unless it is tcl/tk - that IS a crap language...but glad it spawned python/tk). Garbage collection vs pointers have pros and cons too... use what works and makes sense.

@tamusjroyce I'm not sure that is true. Languages enable and support poor user decisions and it's within their scope to encourage good style, structure and patterns. Frameworks are also part of the story, but languages are the main interface that programmers rely on, not just framework APIs.

e.g. You cannot blame C++'s confusing and verbose iterator libraries on a framework, but it is something that can (and should) be improved for the sake of user ergonomics.

@kyntak no.

No language can be blamed for bad user decisions.

If you trigger undefined behavior, it is your fault alone.

If you throw huge constructs on tiny problems, because you fell in love with Design Patterns too deeply, it is your own damn fault.

A Java programmer is taken across the street by their mom when the lights are green.

A C programmer goes alone, and on red lights if they wish. But it is their fault alone if they get run over by a truck.

C++ is even more powerful than C. Hence it is easier than with C to shoot yourself in the foot. Only that with C++, it's a shotgun that'll rip your leg of.

If you take that gun and point it on yourself, it is your own damn fucking fault.

@Yamakuzure every C/C++ program of notable complexity has undefined behaviour somewhere because most of it was bad language design and should have been implementation defined.

The result: you update the compiler version, and suddenly tons of existing code break, as seen with the Linux kernel. Even worse, you can't conclude that by reading the release notes.

To top it off, especially the GCC team has taken a user hostile stance that was not foreseen when the standards were made. They break code even if there is NO real performance gain and don't care. Except if it's in the SPEC benchmark, then they suddenly do care.

And come on, undefined signed integer overflow in a world where no relevant architecture has anything else then 2's complement is downright nasty.

Or, why doesn't C have a debug/test mode with automatic check for out of bounds access? It would be fine to be 5 times slower. Not possible because of bad language design. The result is that it takes longer to test and debug, which burns a lot of money.

A lot of functions in the standard library are downright braindead security holes per design, so you have to use the "right" ones. Fine, but the wrong ones should never have existed in the first place.

@Fast-Nop but everything is like that. The c standard itself is a framework. Just because they modify the language to better support the framework, doesn’t change things. You can turn that framework off for backwards compatibility or other reasons. Or go with a different c compiler.

Another example is Java embedded is much different than full java. I mean, it has to be with it running in under 200K. Still the java language.

I just want to make sure the correct thing is bashed. Substitute language for framework. People defend c because it works for them. Keep on bashing their so-called standard [framework]. Even if they deny it’s a framework. That way the c that works for me doesn’t get discarded too.

But back in topic... since code can be compiled to javascript from c, c++, an entire linux os, ... is javascript awesome? It is single threaded...

@tamusjroyce "the C standard itself is a framework".

I do not think that means what you think it means, but sure, if you're going to call languages frameworks then yes, ergonomics and encouraging good design are frame work problems.

I believe it's they're also language design problems, as languages are not just frameworks, but it seems we agree in the main.

@Fast-Nop Sorry, just got to your last comment.

Pure gold, I wish C had features and a design approach that covered the problems you talked about.

@Fast-Nop You are very wrong in each paragraph...

First: The last Software Suite I worked on consisted of ~2900 C/C++ files, header and source.
Compilers where switched from vc90 to vc120_xp to vc140.
No undefined behavior anywhere...

So half of your argument is proven wrong.

Bounds checking in C? Well good luck with that on a type-unsafe language. By design!

And no. Neither the C- nor the C++-Specifications can be held responsible if some gcc devs behave like pricks.

About the "security" thing : For developers who know what they are doing, those are no-brainers.
I do not need snprintf_s.

The idea the "non-secure" versions should not have been there in the first place, lets me think you have no idea on what hardware C was invented?

@Yamakuzure LOL you don't even know whether you have undefined behaviour or not. Code has gone fine literally for decades before breaking, and obvious breaking is still the best case.

Bounds checking is not a type issue unless types are implemented in as braindead a way as in Pascal where arrays of different length are type incompatible. In C, the real issue is array-to-pointer decay in function parameters.

The GCC folks say explicitely that the standards allow them to be assholes, so it is the standards indeed.

Devs who know what they are doing - yeah, but reality is, humans do err. Saying that the devs are at fault for all the security holes - d'oh. Really? It's humans who develop software? Who could have foreseen that?!

And finally, the hardware back then has nothing to do with braindead standard library APIs without length information. If you can run stuff like scanf/fgets at all, don't try to tell me that an additional int parameter would have blown up the hardware.

Sure. Besides most embedded software engineers shaking their heads now...

Which security holes? If you do not take care of the size of your char buffer, you will end up smashing your stack. These days this means that the stack protector will kill your program, and tell you why.
In most cases you don't even have to search long.
Sure, that is on runtime, but still better than "the old days", when no such mechanisms existed.

C and C++ give you a lot of power, and thus a lot of responsibility.
If you don't like that, there is a plethora of managed (and bloated) languages out there, where mommy takes your hand, and the responsibility.

*shrug* just make your choice, it's yours!

@Yamakuzure embedded engineer here.

Taking care of the char buffer? Here is the prototype for gets() that reads a string from stdin, with no buffer length parameter:
char *gets(char *str)
There's fgets() of course, but a standard library should not contain such stupid functions at all.

Even "safe" functions like strncpy are braindead design because in exactly the case where it is useful, it leaves you with an unterminated string. So you still have to manually work around their half-baked "safety".

And stack smashing - no, stack protectors don't work reliably. If you pass in just enough buffer overflow that you overwrite other local variables, the program will continue to run, but with wrong data. Even spotting such an error takes time, and debugging also. Time is money.

On top of that, you completely missed my point. It's not about a managed language, it's about the missing choice whether to go into checked debug mode (performance doesn't matter) and release performance mode.

@Fast-Nop okay. Let's just agree to disagree.

I will stay with my core point: Nothing you dislike on compilers, libraries, frameworks and/or people behavior can be blamed on any language specifications.

You will stay with your core point: The language spec is responsible for what people do with it.

Fine. Think so. I have also seen much bullshit since I wrote my first C program in 1990. But these were always the people doing this shit. Sometimes it was me, most times it were others. So what?

Oh, and you can make, our own "checking debug mode" all by yourself. You just can't demand a compiler, whose first action is to throw away all type information, to count your arrays for you.
A C compiler does not know arrays. They are just a convenient alias for you to not use pointer arithmetics.

@Gregozor2121 JS on ATmega? Nope
But on the other hand Java on ATmega? Hell yeah! That thing can run on smart cards so why wouldn't it run on an AVR? :D

@D3add3d Java on 8051 controllers ? No. C on 8051 controllers heck yeah :)

I came here to say fuck js, so here it goes.
: FUCK JS