Programming thread

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Marvin said:
If I can't intuitively suss out their intentions from how they model their ideas using language features, it's either a shitty language or they're a shitty designer OR (rarely), there are actually novel concepts that I actually need to read about and educate myself on. I have no problem with the latter when I'm actually learning new concepts but that's pretty uncommon in my experience.
Click to expand...
This is literally every javascript library on npm
 
King Of The Kiwis said:
How do you guys read documentation. I just started learning apis and the docs are so fucking dense that I reread them over and over but still dont comprehend them.
Click to expand...
There are a few examples of good documentation, such as that of Perl, Raylib, Weechat, Cmdtest; which are well-crafted, intelligently structured and helpful even at a glimpse.
Then there is everything else which is utter fucking trash and a complete humiliation ritual, rendered from half-assed doxygen comments.
So, with AI, most of the time.

canalCrab said:
Do NOT trust the LLM to actually explain the doc to you, but rather read the docs yourself, then, maybe, ask the LLM whether your understanding seems correct.
Click to expand...
I encounter useless official descriptions more often than hallucination.

Dr. Charles Forbin said:
the AI won't be able to "understand" it well enough to turn it into good documentation
Click to expand...
Don't forget that the AI wasn't thought only on the docs, it has seen numerous applications with accompanying comments.
Dr. Charles Forbin said:
Maybe it's better for nusoi languages (jeet languages), dunno.
Click to expand...
It is. Its counter productive for writing C, but is useful for Python and is a lifesaver for webshit.

prollyanotherlurker said:
how do people defend javascript?
Click to expand...
In my experience, the people that defend Javascript, do not know anything else.
 
prollyanotherlurker said:
how do people defend javascript?
Click to expand...
1. It's better then ActiveX
2. Modern web browsers only support HTML, CSS, and JavaScript. There literally is no alternative unless you install a plugin and those went out of fashion with T9 phones.

edit: there's also WebAssembly but it doesn't sound like it's utilized a lot.

Would it be viable to write all your applications for WebAssembly then use a wrapper like Wasmer to deploy it to different systems? It would let you abstract a lot of the code and not have to worry about supporting every OS as they can just maintain the wrapper.
 
Last edited:
Betonhaus said:
1. It's better then ActiveX
2. Modern web browsers only support HTML, CSS, and JavaScript. There literally is no alternative unless you install a plugin and those went out of fashion with T9 phones.
Click to expand...
3. From a technical standpoint, its retard-friendliness is quite a marvel. Under the hood, there's a lot of beautiful functional programming concepts chaining together to allow these horrible monstrosities (e.g. literally everything that uses Node in some way) to be made so easily.

Edit: I think webassembly looks cool and is fun to work with, even if it's just for the S-expression style mnemonic/text representation. It's like we're finally getting a version of the originally envisioned scheme for browsers.
 
Betonhaus said:
1. It's better then ActiveX
2. Modern web browsers only support HTML, CSS, and JavaScript. There literally is no alternative unless you install a plugin and those went out of fashion with T9 phones.

edit: there's also WebAssembly but it doesn't sound like it's utilized a lot.

Would it be viable to write all your applications for WebAssembly then use a wrapper like Wasmer to deploy it to different systems? It would let you abstract a lot of the code and not have to worry about supporting every OS as they can just maintain the wrapper.
Click to expand...
WebAssembly is absolutely used when high performance is necessary (if the devs can be bothered to care about it) but it is kinda limited. Wasm programs are only allowed limited access to the rest of the webpage for security reasons, so all of your cool animations or reactive web elements will need to be written in JavaScript, still.

I believe there has been some talk of “Wasm on the server,” I don’t know how far along it is but it probably wouldn’t be too hard to rip the wasm engine out of a major browser and give it some OS and networking primitives to work with. However, this all puts it in a similar category to .NET and the JVM, two much more established platforms for cross platform applications. Wasm does have the advantage of being supported by more languages, I believe. I’ve never heard of anyone running C on the JVM.

Moderately off topic, but my absolute favorite Wasm demo, one that changed my perspective on local AI completely, is IBM’s demo running their Granite AI model in the browser. My several year old 8gb ram thinkpad runs it poorly, but it runs it. Absolutely insane stuff. Imagine going back to when people were blown away by Netscape Navigator and telling them that within their lifetimes they’d see the kind of neural networks that ran on supercomputers running, not just on their crappy laptops, but through the browser in their crappy laptops.
 
1769463174843.png
C2Y Proposal regarding Namespaces

I don't know how to feel about this. On one hand, namespacing in C is a pretty constant annoyance, a lot of function names carry the burden of namespacing by being verbose.
At points, I've used GCC's nonstandard support of the $ character in identifiers to help combat this, but it always felt like a smell even on good days.

I guess at least this syntax allows for existing prefix driven naming schemes to function, but it just feels weird.
I'd almost prefer they do a 'demo' run just focused on enums specifically first, and get feedback, because at least personally, the biggest bloat in code is large enum definitions as well as non-function macro definitions.

TL;DR, this is kind of a pain in C, especially with larger dependency projects, but this approach feels off to me. I also have zero clue how you're supposed to support this feature or consume it with portability in mind without flooding your code with even more macros

Edit: It occurs to me that this is basically sideloading syntax manipulation that macros have largely avoided deliberately, e.g. splitting or removing macro tokens.
 
Last edited:
Anti Snigger said:
View attachment 8478619
C2Y Proposal regarding Namespaces

I don't know how to feel about this. On one hand, namespacing in C is a pretty constant annoyance, a lot of function names carry the burden of namespacing by being verbose.
At points, I've used GCC's nonstandard support of the $ character in identifiers to help combat this, but it always felt like a smell even on good days.

I guess at least this syntax allows for existing prefix driven naming schemes to function, but it just feels weird.
I'd almost prefer they do a 'demo' run just focused on enums specifically first, and get feedback, because at least personally, the biggest bloat in code is large enum definitions as well as non-function macro definitions.

TL;DR, this is kind of a pain in C, especially with larger dependency projects, but this approach feels off to me.

Edit: It occurs to me that this is basically sideloading syntax manipulation that macros have largely avoided deliberately, e.g. splitting or removing macro tokens.
Click to expand...
one of the bigger issues is that macros dont get namespaced, so you'd have to know/remember what is a macro and what is not, also you wouldn't know at a glance from which library (if any) a macro comes from

or in general everything from the limitations section
1769464122821.png
 
Rango Dango said:
one of the bigger issues is that macros dont get namespaced, so you'd have to know/remember what is a macro and what is not, also you wouldn't know at a glance from which library (if any) a macro comes from

or in general everything from the limitations section
View attachment 8478707
Click to expand...
They'd probably have to do any similar macro support via pragmas, which are already a real oddity
 
Anti Snigger said:
View attachment 8478619
C2Y Proposal regarding Namespaces

I don't know how to feel about this. On one hand, namespacing in C is a pretty constant annoyance, a lot of function names carry the burden of namespacing by being verbose.
At points, I've used GCC's nonstandard support of the $ character in identifiers to help combat this, but it always felt like a smell even on good days.

I guess at least this syntax allows for existing prefix driven naming schemes to function, but it just feels weird.
I'd almost prefer they do a 'demo' run just focused on enums specifically first, and get feedback, because at least personally, the biggest bloat in code is large enum definitions as well as non-function macro definitions.

TL;DR, this is kind of a pain in C, especially with larger dependency projects, but this approach feels off to me.
Click to expand...
C++ style namespacing is uglier and more annoying than “<lib>_” prefixes. Although enums having their own namespace would be very nice, actually. The more I learn about nu-C proposals, the less optimistic I feel about the future of the C language.
I remember in the Guile manual, at some point it straight up says that they feel the Scheme standardization process has run its course and they don’t plan to follow it in the future (while continuing to support what they already support). I wonder when we’ll see a message like that in the GCC manual. Probably never, but it’s food for thought.
 
August Levasseur said:
C++ style namespacing is uglier and more annoying than “<lib>_” prefixes. Although enums having their own namespace would be very nice, actually. The more I learn about nu-C proposals, the less optimistic I feel about the future of the C language.
I remember in the Guile manual, at some point it straight up says that they feel the Scheme standardization process has run its course and they don’t plan to follow it in the future (while continuing to support what they already support). I wonder when we’ll see a message like that in the GCC manual. Probably never, but it’s food for thought.
Click to expand...
the best C23 feature by far is #embed
feature so good it will be implemented in C++26
i fucking love #embed
TOTAL. #EMBED. LOVE.
 
Last edited:
August Levasseur said:
e more I learn about nu-C proposals, the less optimistic I feel about the future of the C language.
Click to expand...
They added break/continue with labels for nested loops, and scoped declaration in if, all of which I do actually like. The former is semantically stronger than existing uses of goto, and the latter while niche does have advantages over existing scoping in some cases.

Edit: Forgot to mention the case syntax, I also love that, it's a lot cleaner to do case 'A'...'Z' than stacking 26 labels, and it helps the compiler generate better jump tables
 
chat what do we think about closures in c?
what about contracts?
personally i dont mind closures, theyre already a feature in GCC for example, however i think its also too much voodoo for C
i like contracts though, additional code-as-documentation + allows for some optimizations for the compiler

EDIT:
Rango Dango said:
also speaking about the proposals
the fucking tranny is trying to remove I REEEEEEEE

nvm its actually a good proposal since in c23 you can postfix a number literal with an i to get an imaginary value
Click to expand...
this one has already been voted for in february 2025
the results were 17 for, 1 against, 9 abstained
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom