Posts by shodanbo 16 publicly visible posts • joined 21 Apr 2017
And there will always be this imbalance, regardless of what political/economic system is involved.
Yes, it sucks but this is the way humanity works, at least for now and the foreseeable future.
Best we can hope for is free speech a free press and communications networks that are willing to go after those in power and spread a little sunshine around.
Interesting take.
And yes, Grace Hopper was one of the greats upon whose shoulders we all rest.
Ada (named after Ada Lovelace) is another language that has lost favor. It was popular in military and aerospace applications because it had a rigid syntax checking for interfaces between code that allowed many things that would get past a C compiler to be caught before runtime.
Complaint against Ada was that it was too rigid and slowed programmers down, and so things moved over to C/C++.
Could be written in assembly, but would take longer for likely no performance benefit, may even be slower. Any opcodes a compiler throws down could be done in assembly or direct binary coding.
It was fun and frustrating coding in assembly. Not worth it these days except for rare circumstances where you need to do something weird on bootstrap.
I did this too. Definitely a smart thing to do back in the day, and not really that hard given that you could hide malloc/free behind an evil macro.
If you look at the standard libraries for modern operating systems, they may have "moats" before and after allocated memory to (1) validate freeing a pointer is legit and (2) detect when something has written past the memory boundary and scold you on deallocate.
For the last embedded project I work on (mid 00's) I had moats on both side of calloc/malloc (also malloc always calloc'ed for extra safety in #debug code) that would tell me if anything got double freed or something wrote past the memory boundary (again for #debug code). It would assert on free if anything bad happened and tell you what line the memory had been allocated on and what line was doing the free when the problem was detected. I eventually used this same code with Windows and Linux projects I worked on even though those OSes will not kernel panic like an embedded OS would when you are too naughty, Having the extra information of where the memory came from and what line was freeing where the problem was discovered was nice.
You can multithread in C/C++ fairly easily, but not portably unless you use POSIX APIs for everything you want to do. Absolutely not hacky at all. There are libraries you can use that bring portability to the mix, but your binaries themselves will never be portable like pure JVM (Java) or CLR (C#) binaries can be.
You can also write SIMD code for general-purpose processors (x86, x64, ARM or MIPs) with SIMD extensions in C/C++. You can #pragma into ASM to use the SIMD opcodes directly or you can call libraries that do that for you. Is did the #pragma thing with x86 SSE2 back in the late 90s. Nowadays you are more likely to use libraries than roll your own like I did. Rolling your own was fun though!
C was initially developed for Unix, which eventually became a multiprocessor (capable) operating system. The C language however does not have direct support for threads. This is what operating system runtime libraries were for, with POSIX as an attempt at a portable one (that the likes of IBM and Microsoft only supported halfheartedly unfortunately). This way the C language could remain pure. Not all operating systems supported threads (or even multiple processes) back in the 70s/80s. You can even write C code right down to the metal with no OS available. This is what makes C great for embedded applications and bootstrapping code. A C compiler can allow you to be small and tight with the ability to layer more complex stuff on later after you have the hardware functioning properly.
It's important to note that multi-threading != SIMD. Single instruction multiple data means a single "thread" of instructions that can process vectors in parallel with each instruction. For example, 8 additions in parallel rather than 8 adds back-to-back in serial. You can have multiple threads of serial instructions or multiple threads of SIMD instructions depending on what your hardware supports. Back when I was working with SSE2 you had to be careful to keep threads from messing with each other because there were not enough SSE registers to go around for all the (hyperthreaded) cores you could throw instruction streams at.
Operating systems generally support the serial or native SIMD instruction threads directly. Since CPUs and NPUs can operate in separate memory spaces from the OS itself those instruction streams are handled by coordination between the OS and external devices through device driver communication mechanisms to send data back and forth across memory busses. This type of work currently falls outside the capabilities of language compilers, which do not have enough context on how the communication happens. Instead, you compile code in special languages such as CUDA and then use a library/device driver to throw that code from CPU code through a vendor supplied library that copies the code over a memory bus to where the GPU/NPU executes it. Then the results get copied back into memory space that the serial code (and operating system) can see and manage,
Perhaps someday there will be enough standardization so that a language such as Rust, or even a modern C/C++ or Java or C# could handle both sides of the CPU/G(N)PU problem with a single language. And maybe someday operating systems will also deal with the low-level memory management in a way where a compiler could reason about things at compile time to protect against mistakes in interop between the CPU/GPU/NPU code that can lead to CPU/G(N)PU panics.
Not sure about COBOL. but C is a decent language for embedded development to get things bootstrapped so you can then move to higher level and safer languages.
Rust is an attempt to provide a safer alternative, but it will take time for that to happen.
And a C compiler is easier (and cheaper) to get up and running when new chips/boards are involved.
That being said I have not personally used C in years.
Nowadays for the things I would have used C/C++ for (other than board bring up) I would instead use Kotlin, Java, C#, JavaScript, Python, PHP or Rust.
And, of course, there is a lot of C code out there that will either need to fade away or get rewritten. Rewriting costs time and money and just throwing money at the problem is no guarantee that it will work and lead to better code than what we have now.
How about how Yelp "helpfully" creates listings for businesses without being asked and then pumps up their SEO to get those listings to come up before the business' own web site for organic searches. Bonus points for then putting competitor ads into those un-requested business listings that can be removed if you only agree to give Yelp some of your hard earned cash?
"Nice business website you have there ... would be a shame if somebody with SEO experts out the wazzo came and prevented your customers from seeing it!"
A web app is code (js/html/css) loaded from an internet endpoint.
A native app is code loaded from disk.
After that, both can make the same mistake and assume that a network is available when its not.
The advantage to a native app is the app can load even without a network. A web app *could* load without a network if it had loaded at least once with a network, but that's really up to the browser and the developers of the code.
Seriously. Who is surprised by this,
1) Through hard work, perseverance and luck, I will succeed
or
2) Fuck em all, I need an edge, steal, lie, cheat .... odds favor this path.
Said another way ...
"You cannot guarantee success, but you can deserve it when it happens" ....
Or
"Screw that, I want to guarantee success, who cares if I deserve it?"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
