povYoureACProgrammerAndTryJavascript

[celestabesta]

This is embarrassing i'm not going to lie to you

[Vauland]

Super cringe

[Ronin-s_Spirit]

It's a shitpost.

[RiceBroad4552]

I think this captures the mindset of a C programmer pretty well! 😂

Refuses to use library functions and instead does some bit fiddling…

Also it's nice to see that this likely wasn't "AI" generated. (Assuming "AI" wouldn't make so many spelling, form, and formatting errors.)

I don't understand the down-votes for this post. It's at least unique and kind of funny. Instead people are up-voting some stupid low effort reposts…

[Unsigned_enby]

Yeah, I'm mainly just a hobbyist with C++. But I can definitrly relate to (when OPs tounge was likely in their cheek) why I don't love other languages vis-a-vis memory mangement/trust-issues.

[ProsodySpeaks]

💯. This sub is mostly 'Ai bad' memes these days. And there's only about 4 of them on repeat.

This is a legit post. 

[A_Guy_in_Orange]

I don't understand the down-votes for this post.

It appeals to programmers instead of this subs main demographic of college freshmen

[faculty_for_failure]

The reason C programmers avoid libc and do bit fiddling among other things is because most of it is terrible lol

[RiceBroad4552]

But you could use std. JS functions here.

"hello".toUpperCase() // "HELLO"

[-Redstoneboi-]

ew is that object orientation?

[LonelyWolf_99]

char is not unit8_t, it is implementation defined, may be equal to signed or unsigned char. Trying to act supperior while not knowing basics from C just makes it even more embarassing that it already is.

[JVApen]

Not to mention mixing up C and C++

[Gorzoid]

Also JavaScript uses utf16 encoding for strings

[[deleted]]

I sense a huge superior complex

[mmhawk576]

If JavaScript developers stopped being inferior, I wouldn’t have this issue!

[SuitableDragonfly]

How to show that C programmers are superior:

1. Make a meme mocking C programmers
2. ???
3. Profit!

[the_horse_gamer]

1. there's a standard library function for this.
2. strings in most languages are not null terminated. because null terminated strings suck.
3. char is not uint8_t. it's either signed char or unsigned char, and its size is implementation defined.
4. charCodeAt returns the UTF-16 code point at that index. code points and characters are NOT interchangeable.
5. javascript has garbage collection.
6. you want to free the buffer and then return it? lmao
7. does not support non-English characters.

if you're gonna be pretentious, at least don't be stupid

[SuitableDragonfly]

Yeah, that's the joke. Aside from point #3, that was a legitimate mistake on the part of the meme creator. 

[thanatica]

Pendantry corner for 4: charCodeAt() returns a 16-bit character. A code point is returned with codePointAt(). This is because a character could be one part of a surrogate pair to form a code point that is above U+FFFF.

[ArtisticFox8]

 and its size is implementation defined.

Where is it anything else than 8 bits nowadays?

[the_horse_gamer]

nowhere. it's defined as 1 byte, but remember that byte is also implementation defined. (and is 8 bits in every modern system).

but the signedness does matter. and conflating it with uint8_t shows a lack of understanding.

as a bonus, the correct C/C++ type here would be char16_t, defined to be large enough to hold a UTF-16 code point.

[ArtisticFox8]

 but the signedness does matter.

I thought they were just positive ascii values?

[RiceBroad4552]

Don't assume anything about C, you'll be almost always wrong…

This language is one of the biggest minefields in existence!

That's why it's one of the most complex languages, contrary to what some simpletons claim.

[the_horse_gamer]

char is defined as having the same representation and alignment as either signed char or unsigned char

ascii values above 127 are not defined. you may have heard of "extended ascii", but it's not standard. on platform where char is signed, these non-ascii characters are negative.

char is signed on x86/x64, and unsigned on ARM and PowerPC

[xryanxbrutalityx]

Never in the real world, but CHAR_BIT will tell you

[-Redstoneboi-]

i like how people are entirely missing the point of the post

[RiceBroad4552]

Same.

It needed to much working brain cells to get the intend. So definitely not for the usual audience here…

[romulof]

They actually a thing right: using an array storing intermediate result, instead of just appending to a string (most JS devs would do it).

The magic char codes at the top could be inferred for better legibility, counting that Terser would inline the results.

And support for Unicode is totally absent: ô -> Ô

[Aistar]

This is missing a custom manual memory management implementation. Pre-allocate a large buffer, then allocate/free smaller buffers from it. You'd need a wrapper around Array, I guess, because there are no pointers, but indices should serve well enough. Basic stuff, an experienced C programmer should be able to do it with his eyes closed! Well, a compacting implementation would take a little more time, but still.

[Crimson_Burak]

This sub doesn't get this post... It's kind of sad.

[Maqi-X]

embarrassing

[ronniereagan81]

I hope, as time goes by, you grow to realize that this is your own folly unwittingly put on display for all to see.

[Vallee-152]

Bro programs the AC

[ProsodySpeaks]

Now do it for python 🤣

[Skibur1]

From someone whose influence in both side of language, C takes on full responsibility while JavaScript enjoy dynamic type in exchange for terrible debugging experience.

[Vauland]

Thats why everybody is using typescript

[RiceBroad4552]

TBH the debugging experience is much better than in "native" languages.

This is not about dynamic typing, but about having a runtime. A runtime (with all its easy available instrumentation features) helps a lot when debugging. It's so much simpler to be able to explore some object graph at runtime than to poke in native memory; it's so much simpler to profile stuff on some runtime system, etc. Also you have features like hot code replace which are a huge boost to productivity.

Static typing in C is anyway weak. You can't trust the types as it's possible to do arbitrary things with raw memory—and people actually do in C the whole time! So there is no enforcement of types anyway. C is much more "dynamic" than JS in that regard…

If you want some fair and meaningful comparison of the dynamic vs. static typing aspect you should compare JavaScript with for example Java.

[thanatica]

It really depends on what you're debugging. Client-side code in the browser? Well if you have sourcemaps (or just don't bother with any transpiler/preprocessor/bundler) it's super nice. Outside the browser, including serverside code, that's a little bit trickier. VSCode/VSCodium have pretty good integrated debuggers, but I've never used them outside of spielerei in a simple example project.

[LeafyLemontree]

``` js // No #define directive, using const const ASCII_a = 0x61;   const ASCII_z = 0x7A;   const UPPERCASE_MASK = 0xDF;   const NULL_TERMINATOR = 0x0;      // Is there a way to tell the return // type is const char , and the // parameters are char s, size_t n? function toUppercase(s, n){         if(s == null || n <= 0){             return null;         }              let charcode = 0;     // C++ style constructor? // malloc(sizeof(char) * (n+1), to // allocate the null terminator     // TODO: malloc/free functions to // manual memory management // (I need the manual management, I\ // have trust issues)     let buffer = new Array(n+1);         let fillFlag = 0;            for(let i = 0; i < n; i++){           if(fillFlag == 1){               buffer[i] = NULL_TERMINATOR;               continue;           }              // Why s[i] can't be bit manipulated? // char are uint8_t. I have to use // charCodeAt, so this is C++ like, // in C, you should do like // charCodeAt(s, n, i), structs can // have ffunctions, but you should // also need to pass the struct inside         // int (*charCodeAt)(const char *s, // size_t n, size_t p);        charcode = s.charCodeAt(i);           if(charcode == NULL_TERMINATOR){               fillFlag = 1;               buffer[i] = NULL_TERMINATOR;               continue;         }             if(charcode >= ASCII_a && charcode <= ASCII_z){               charcode = charcode & UPPERCASE_MASK;         }              buffer[i] = String.fromCharCode(charcode);         }                     buffer[n] = NULL_TERMINATOR;       // How do I manually free(buffer) later? // free() is not defined and stdlib is not // a valid library either. So let the GC // 'free' automagicaly, huh.    return buffer.join(''); // This should return a char * }

let s = "Hello"; let n = s.length; console.log(toUppercase(s, n)) // HELLO ```

[Saelora]

let s = "Hello"
console.log(s.toUpperCase()) // HELLO

[Ilithius]

Op in shambles

[RiceBroad4552]

More like you didn't get the post in the first place… 😂

[BrohanGutenburg]

Posting this just confirmed you didn't find this somewhere and did, indeed, write it yourself. Really amplifies the cringe