bluetomcat

True, but with Gen AI, we are turning most digital products into unpredictable slush machines that appear to mostly work on the surface, while hiding an incomprehensible amount of behavioural and performance anomalies.

It's what happens when you substitute human causal understanding for probabilistic pattern matching that "solves" problems with layering more problems in a pile of cognitive debt beyond human comprehension. We are compromising our entire digital infrastructure with mindless slop that erodes decades of collective know-how and conceptual awareness about complex systems.

In practice, most software engineering is overengineering. It is adherence to dogma on a wide corporate scale. It leads to an explosion of complexity and bad software. It is the "best practices" that you should agree with, in order to stay employable.

"Software engineering" is the corporate aspect concerned with the "right" way to do stuff, often picking inadequate analogies from physical manufacturing and traditional engineering. It builds the ungainly, monolith dinosaurs and the technical debt. It is OOP, enterprise Java with the abstract factories, MFC, "agile methodologies" and "agentic workflows". It creates the dogma and the ideologies.

"Programming" is the creative tinkering aspect where you start from scratch and approach a problem from a new light. This is how Unix was born. It is the 1000-line program that is composable, fun to read and write and will last a long time.

They are ignorant about the elephant in the room. The input language of a compiler is a formally-specified grammar with well-defined semantics for each operation. It generally abstracts the computation process over a von-Neumann machine, adding convenience features and bells and whistles. What "a=1" means in an HLL is, store that value in a particular storage location, so that it can be accessed later by the same name.

The slop machine reads lousy natural human language that can mean different things in different contexts. That lousy language is then statistically probed for the most likely output correspondence, producing shit that needs to be externally verified.

It has no semantic depth. The sentences and the paragraphs are a statistically viable derivation of existing human text, but once you try to grasp the whole thing with its temporal and spatial dimensions, you are left with a blurry mess that rots your brain. It's a polished, inoffensive and shallow interpretation as written by an opinionated reputation-seeking user of Quora, circa 2019. Assertive, bold, without typos, clean-cut and bulleted, but without an interesting semantic core.

> Why are we using C anyhow?

Because "cc prog.c; ./a.out" offers you the most direct way to interact with your system. Because "man 2 mmap" documents a C API. Because "nm" lists your functions and global variables with the exact same names as the C program.

The relative "lack of features" in comparison to its "better" alternatives is what makes it preferable. It lets you concentrate on the inherent complexity of the problem you are solving, and not on the opinions of vocal people online.

Abstractions are ultimately a tool for humans to manage complexity in a particular class of problem, and to reduce cognitive load. Good abstractions come from imaginative human brains with taste and lived experience. Abstractions are also mind constructs that often have analogies in the real world. Even at the level of the CPU circuitry, abstractions serve that role. An LLM can only spit out what was already invented by humans and stitch it together in a tasteless, erroneous manner.

No. Plausible code is syntactically-correct BS disguised as a solution, hiding a countless amount of weird semantic behaviours, invariants and edge cases. It doesn't reflect a natural and common-sense thought process that a human may follow. It's a jumble of badly-joined patterns with no integral sense of how they fit together in the larger conceptual picture.

We went from expressing computation via formal, mostly non-ambiguous languages with strict grammar and semantics, to a fuzzy and flaky probabilistic system that tries to mimic code that was already written. What could go wrong?

You are correct. The final output was polished by ChatGPT, but I originally presented the basic ideas in a few paragraphs. The LLM added a sense of flow and persuasiveness which are somehow lacking in my rather dry and non-native English writing style.

It starts from the identifier. At every stage, it outputs a sub-expression which is the “mirrored use” and corresponds to the boxed representation below it. When it reaches the top of the expression, it prints the final type of the expression which is the lone specifier-qualifier list.

As per the screenshot, “arr” is an array of 4 elements. Consequently, “arr[0]” is an array of 8 elements. Then, “arr[0][0]” is a pointer. And so on, until we arrive at the specifier-qualifier list.

And consequently, "you need 32GB of RAM just to be future-proof for the next 3 years".

Because in C, every allocation incurs a responsibility to track its lifetime and to know who will eventually free it. Copying and moving buffers is also prone to overflows, off-by-one errors, etc. The generic memory allocator is a smart but unpredictable complex beast that lives in your address space and can mess your CPU cache, can introduce undesired memory fragmentation, etc.

In Java, you don't care because the GC cleans after you and you don't usually care about millisecond-grade performance.

Yes, you can do it with minimal allocations - provided that the source buffer is read-only or is mutable but is unused later directly by the caller. If the buffer is mutable, any un-escaping can be done in-place because the un-escaped string will always be shorter. All the substrings you want are already in the source buffer. You just need a growable array of pointer/length pairs to know where tokens start.

Good C code will try to avoid allocations as much as possible in the first place. You absolutely don’t need to copy strings around when handling a request. You can read data from the socket in a fixed-size buffer, do all the processing in-place, and then process the next chunk in-place too. You get predictable performance and the thing will work like precise clockwork. Reading the entire thing just to copy the body of the request in another location makes no sense. Most of the “nice” javaesque XXXParser, XXXBuilder, XXXManager abstractions seen in “easier” languages make little sense in C. They obfuscate what really needs to happen in memory to solve a problem efficiently.

> These lies don’t just affect them but also the people reading it as they might never see what actually happens

This is what sustains this whole economic bubble built on debt and future promises. At all levels of society, you have these inflated unrealistic expectations and BS circulating in the media. Technically-incompetent but eloquent and charismatic CEOs predict that in 6 months, some major technological shift will happen. Managers preach about adjusting their organisations to these new realities. Workers have no choice but to play the game with all its dirty tricks, if they want to stay employed. Anyone who dares to say that the emperor has no clothes is isolated in a dark corner because they may suddenly deflate the value of the whole economy. This is corporate feudalism disguised as a competitive economy.

They were popular because there was no Unix culture in Eastern Europe at the time. Pretty much any computer geek was a DOS user. To me personally, it always seemed kind of lame because many of these people would not bother to properly learn the shell language.

Their English is sufficiently good. It's a cultural aspect regarding writing style. When Russians and most Eastern Europeans write about technical subjects, they tend to be concise, dense and straightforward. Americans, on the other hand, are over-expressive and tend to saturate their writing with pointless metaphors and rhetorical devices.

> Pattern matching should make the language less verbose, not more.

In the most basic cases, yes. It can be used as a more polished switch statement.

It's the whole paradigm of "define an ad-hoc Enum here and there", encoding rigid semantic assumptions about a function's behaviour with ADTs, and pattern matching for control-flow. This feels like a very academic approach and modifying such code to alter its opinionated assumptions isn't funny.

Rust encourages a rather different "high-level" programming style that doesn't suit the domains where C excels. Pattern matching, traits, annotations, generics and functional idioms make the language verbose and semantically-complex. When you follow their best practices, the code ends up more complex than it really needs to be.

C is a different kind of animal that encourages terseness and economy of expression. When you know what you are doing with C pointers, the compiler just doesn't get in the way.