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.
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.
Absolutely. LLMs offer you compressed documentation at your fingertips. Instead of scrolling through man pages and function references to find that specific flag or parameter you are interested in for the problem at hand, you can directly formulate such a question to the LLM, and it will give you a pretty good result.
> I'm not sure if all this advice will become irrelevant or if those programmers trained in the 2020ies will not become those "best"..
It's how they use the AI. If they see it as a glorified StackOverflow where you paste a big chunk of code and ask "why does it not work", they'll be in trouble. If they are able to narrow-down their problems to a specific context, express them well and take the output of the AI with a grain of salt, they'll be 10x programmers compared to what we were in the 2000s, for example.
Good for you, but you are in a privileged position. Over here in grim Eastern Europe and outside a capital, your best chance is to find a remote job that doesn't actually suck and has longer-term prospects. Climbing to a managerial position means controlling people and being in touch with other managers posting bullshit on LinkedIn. Nobody will hire you to just write "wisdom-based" proof of concepts or whatever.
FAANG jobs and organisational structures are not the norm across the world. The ratio between "people fixing stuff" and "old wisemen" is heavily skewed towards the former.
How about the general decline of cognitive ability with age? I'm in my late 30s, starting to feel fatigue in dealing with nasty little problems on a daily basis. I can say whether an approach is good or bad, but actually coding the stuff with all the modern ephemeral frameworks and libraries is becoming increasingly uncomfortable. I would want to afford to do "recreational programming" on greenfield projects, unbound by time and business requirements, but it is a luxury.
Few people at software companies are designing systems from scratch nowadays. If they are, they'll be gluing together third-party middleware applications like database systems, queues, proxies, load balancers, etc.
A general understanding of computer architecture, programming language theory, networking and common protocols and formats is more valuable. At that fundamental level, they won't be using recent fancy buzzwords to sound cool, but could be using their brain to come up with something original.
I see AWK as a general-purpose output filter and aggregator, something like a programmable grep. You read another program's output line by line, and output it filtered and/or summarised. Works nice when the format is known, but in case it isn't, error handling and recovery is not something I would enjoy doing in AWK.
Use the shell only if your script is mostly about calling other programs and filtering and redirecting their output. That's what the syntax of these languages is optimised for. As soon as you need any data manipulation (i.e. arrays, computation, etc.) it becomes a pain and Python is the much better fit.
Markets can be seen as regulatory institutions in themselves, though they exhibit many undesirable side effects. The inherent "decentralisation" in Western societies is enabled by markets. Producers meet consumers in a constant feedback loop, production follows demand. Some producers are weeded out, new classes of products and their corresponding market types appear. Consumers can choose what, when and where to buy. What would be political decisions in a centralised society are market mechanisms in a market society.
It goes awry when you add mass media, mass culture and psychology into the mix. They encourage all kinds of irrational group behaviour which skews the markets in unpredictable ways.