LLM cannot reason about anything.
It can provide text that can be plausibly interpreted as reasoning by someone reading that text.
When human provides a plausible explanation then it means they either had someone else provide it to them or they actually understand the issue.
LLM cannot understand anything, it can only provide output based on the training data where similar input has likely to have produced similar output in the past.
Human can tell you they don't understand or don't know something but LLM is unlikely to have training that will produce that kind of output, it is more likely you will always get something that looks correct but it might not be.
LLM can automate a part of the process where human might take slightly but, ultimately, any output generated by LLM cannot be trusted and should be checked by human that understands the issue...and that is actually the hard part where humans will struggle so they won't actually do it.
When human is producing the output that human is performing the following actions:
-analysing the issue
-analysing the exiting process
-building the understanding of the existing process
-building the understanding of how issue affects the existing process
-producing the output to address the issue in the existing process
-checking the output as it is being produced
-updating the understanding of the existing process with lessons learned from the above
-checking the final product to ensure that it has solved the original issue and hasn't broken some other part of the system
LLM can help speed up one of those steps (producing the output) at the expense of slowing down the other parts (which were already slow) and reducing the understanding and reliability of the existing system which will make future iterations even slower.
LLM can be used to speed up the generation of examples but just like in the past you could not just copy the example from some random internet search result, you should not just copy the LLM output without understanding it...and that is the slow part where LLM might not help (and might actually make worse) for most people.
And when in the past you encountered comprehensive and well documented output you could assume human that put that amount of effort actually understood what they were doing and wouldn't have expended that much effort to generate garbage, you cannot make that same assumption now with LLMs.
Again this is not true with a real world recent example.
For context: for the project I’m about to describe, I did the 3 week discovery process where I iterated through the design. I designed the architecture from an empty AWS account with IAC and an empty git repo. I know every decision that was made and why.
An issue was reported while the client was testing - a duplicate message was displayed to the user.
I gave codex three pieces of information - the duplicate IDs and told it was duplicate.
Codex:
1. Created and ran a query in the Postgres database after finding the ARN to the credentials - you don’t have to pass credentials to the database in AWS, you pass the entry in Secrets Manager directly to the database as long as you have permission to both (Dev account). I didn’t tell it the database and queried where I was storing the event.
2. It found the lambda that stored the events in the database.
3. It looked at the CloudFormation template to figure out the Lambda was triggered by messages in an SQS queue
4. Looking at the same template it saw that the SQS message was described to an SNS topic
5. It found the code that sent the events - a 3000 line lambda
6. It was able to explain what the lambda did and find there wasn’t a bug in the logic
7. It saw that the flow was data driven and got the information from a DDB table defined by an environment variable.
8. It then looked at that CloudFormation template that deployed the Lambda
9. It ran a query on the DDB table after looking at that CloudFormation template to figure out the schema
It then told me that there was a duplicate entry in the database.
I knew the entire structure of the system - again I designed all of this myself. I wanted to see how codex would do.
Everything you are saying a modern LLM can do.
I won’t even go to how well it debugged a vibe coded internal website just by telling it to use Docker container with headless chromium and Playwright. It debugged it by taking screenshots while navigating and making changes.
I hate losing access to software just because it is "unmaintained".
If module is "endorsed" now, since it is included in current version, and there is no maintenance, so no changes made to it, why is it suddenly not good enough to "endorse" in the future?
No, security issues do not count as they don't magically appear, either they are in there now and debian is fine with distributing "insecure" code or they don't matter.
Debian is fine with shipping broken version of software for years as long as they consider it "stable" so why drop working "stable" software just because no one is making changes to it?
It's not only about security (although that's extremely important) but also making the changes necessary to adapt to the changing ecosystem. Unmaintained means there is nobody responsible, nobody you can even contact to make the changes needed. If there is anyone, even an aging OS developer as in the case of many packages, it's so much better than none.
As a pedestrian I find cyclist are worse than cars for obstructing my path.
Riding on the footpath (illegal here) even with bike lane available right next to it, not respectig the traffic lights (mowing through pedestrians on crossings or blocking pedestrian crossings when stopped on red light), parking by blocking the footpath (must leave 1.5m of footpath unobstructed), riding the wrong way through traffic, flying down bike lanes (40kmh limit) and raging when anyone infringes their "rights" when they respect noone.
In my experience, I estimate that 20% of car drivers are a-holes, 50% or truck drivers and 80% of cyclists.
I would like for Linux to be able to replace Windows.
I run Linux on some of my computers with various levels of success.
But even with Windows 11 being as annoying as it is and Ubuntu/Mint/Cachy/Fedora/etc having some really good points they are not as easy to use as Windows.
Sure, web browsing is almost the same and simple home office tasks are close enough.
But all of the complaints that GP has mentioned are valid.
Windows file chooser is essentially small Windows Explorer and you can do almost everything that you can in the explorer while you are in file chooser mode. None of the Linux desktops have anything close.
HiDPI and multi monitor scaling on Linux has gotten better and it might approach what Windows had for the last 10 years but it is not 100% there yet.
Wayland is just a protocol with many incomplete and incompatible extensions that may or may not be implemented by your DE.
VNC is not even remotely close to RDP in features or performance. It just isn't.
I have used RDP over dial-up that was more responsive that VNC over LAN.
Not to mention sound, printer, disks, USB, etc all being available over one RDP connection.
Accessibility on Linux is a joke. On screen keyboard may work 80% of the time, screen reader might work 20% of the time. Sound might come out of random output or it might not. You may have to play with random settings, good luck with that if you are vision impaired.
One big reason Linux isn't there yet is people who just dismiss all of the above and go with "it works for me so it must be good for everyone."
The GTK file picker, which is frustratingly the default even on most KDE installs, is the one that sucks. The KDE-native one would much more closely match the experience you're looking for.
VNC is highly dependent on implementation. Sunshine/Moonlight runs circles around RDP in terms of performance and includes audio. For situations where you need the extra functionality is RDP... You can just use RDP. It works just fine on Linux, especially if you're on recent KDE.
On-screen keyboards are admittedly a pain point, but I've usually seen people say nicer things about the screen readers than Windows. Probably lots of different experiences depending on implementation.
> Windows file chooser is essentially small Windows Explorer and you can do almost everything that you can in the explorer while you are in file chooser mode. None of the Linux desktops have anything close.
I remember KDE copying that a few years after Microsoft introduced Active Desktop. That was, what, 25 years ago now?
Having seen LLMs so many time produce incoherent, nonsense, invalid answers to even simplest of questions I cannot agree with categorization of "thinking" or "intelligence" that applies to these models.
LLMs do not understand what they "know" or what they output. All they "know" is that based on training data this is most likely what they should output + some intentional randomization to make it seem more "human like".
This also makes it seem like they create new and previously unseen outputs but that could be achieved with simple dictionary and random number generator and no-one would call that thinking or intelligent as it is obvious that it isn't.
LLMs are better at obfuscating this fact by producing more sensible output than just random words.
LLMs can still be useful but they are a dead-end as far as "true" AI goes. They can and will get better but they will never be intelligent or think in the sense that most humans would agree those terms apply.
Some other form of hardware/software combination might get closer to AI or even achieve full AI and even sentience but that will not happen with LLMs and current hardware and software.
If the payload expands to something too large then it is easy to detect and ignore. Serve up thousands of 10kb or 100kb files that expand to 10s of MB with random garbage inside...possibly the same text but slightly modified. That will waste the time and CPU cycles and provide no value to them. Maybe also add a message you want to amplify so AI bots train on it.
The problem is that believable content doesn't compress well. You aren't going to get anywhere close to that 1:1000 compression ratio unless it's just a single word/character repeated thousands of times.
It's a choice between sending them some big files that will be filtered out long before they can do any real damage or sending them nonsense text that might actually make it's way into their training data.
We currently don't really know what intelligence is so we don't have a good definition of what to expect from "AI" but anyone who has used current "AI" for anything other than chat or search should recognize that "AI" is not "I" at all.
The "AI" does not "know" anything. It is really a fuzzy search on an "mp3" database (compressed with loss resulting in poor quality).
Based on that, everyone who is claiming current "AI" technology is any kind of intelligence has either fallen for the hype sold by the "AI" tech companies or is the "AI" tech company (or associated) and is trying to sell you their "AI" model subscription or getting you to invest in it.
My work is basically just guessing all the time. Sure I am incredibly lucky, seeing my coworkers the Oracle and the Necromancer do their work does not instill a feeling that we know much. For some reason the powers just flow the right way when we say the right incantations.
We bullshit a lot, we try not to but the more unfamiliar the territory the more unsupported claims. This is not deceit though.
The problem with LLMs is that they need to feel success. When we can not judge our own success, when it is impossible to feel the energy where everything aligns, this is the time when we have the most failures. We take a lot for granted and just work off that but most of the time I need some kind of confirmation that what I know is correct. That is when our work is the best when we leave the unknown.
UTF8 is a horrible design.
The only reason it was widely adopted was backwards compatibility with ASCII.
There are large number of invalid byte combinations that have to be discarded.
Parsing forward is complex even before taking invalid byte combinations in account and parsing backwards is even worse.
Compare that to UTF16 where parsing forward and backwards are simpler than UTF8 and if there is invalid surrogate combination, one can assume it is valid UCS2 char.
UTF-16 is an abomination. It's only easy to parse because it's artificially limited to 1 or 2 code units. It's an ugly hack that requires reserving 2048 code points ("surrogates") from the Unicode table just for the encoding itself.
It's also the reason why Unicode has a limit of about 1.1 million code points: without UTF-16, we could have over 2 billion (which is the UTF-8 limit).
Runtime flexibility is not restricted to dynamically typed languages, it just happens to be less available in some of the popular statically typed languages.
Error handling, expressiveness, testing culture, meta-programming and gradual typing have nothing to do with static vs dynamic typing.
The main "advantage" of dynamically typed languages is that you can start writing code now and not thing about it too much. Then you discover all the problems at runtime...forever.
Statically typed languages force you to think about what you are doing in advance a lot more which can help you avoid some structural issues. Then when you do refactor computer helps you find all the places where you need to change things.
Dynamically typed languages force you to write more tests that are not required in statically typed languages and that might prompt you to write other tests but if also increases the chance you just give up when you start refactoring.
Finally, after some time has passed and few updates have been applied to the language and libraries, you may not have a working project anymore. With statically typed languages you can usually find and fix all the compile errors and have the fully working project again. With dynamically typed languages, you will never know until you explore every line of code, which will usually happen at runtime and on the client computer.
i see things like that written almost on the daily but i've never seen it come to pass.
this is anecdotal but i've worked professionally in ruby and clojure and it was a pretty good experience. java/kotlin/scala made me wish i could go back to dynamic land...
these days i'm in a rust shop but i keep clojure for all my scripts/small programs needs, one day i intend to go back to some kind of lisp full time though.
Sure you're right on most of this, but allow me a slight pushback here. I am sorry, I am inclined to use Clojure/Lisp in my examples, but only because of its recency in my toolbelt, I could probably come up with similar Elexir examples, but I lack intimate familiarity with it.
- Dynamic languages can harbor bugs that only surface in production, sometimes in rarely-executed code paths, yes. However, some dynamically typed languages do offer various tools to mitigate that. For example, take Clojurescript - dynamically/strongly typed language and let's compare it with Typescript. Type safety of compiled Typescript completely evaporates at runtime - type annotations are gone, leaving you open to potential type mismatches at API boundaries. There's no protection against other JS code that doesn't respect your types. In comparison, Clojurescript retains its strong typing guarantees at runtime.
This is why many TS projects end up adding runtime validation libraries (like Zod or io-ts) to get back some of that runtime safety - essentially manually adding what CLJS provides more naturally.
If you add Malli or Spec to that, then you can express constraints that would make Typescript's type system look primitive - simple things like "The end-date must be after start-date" would make you write some boilerplate - in CLjS it's a simple two-liner.
- Static type systems absolutely shine for refactoring assistance, that's true. However, structural editing in Lisp is a powerful refactoring tool that offers different advantages than static typing. I'm sorry once again for changing the goalposts - I just can't speak specifically for Elixir on this point. Structural editing guarantees syntactic correctness, gives you semantic-preserving transformations, allows fearless large-scale restructuring. You can even easily write refactoring functions that manipulate your codebase programmatically.
- Yes, static typing does encourage (or require) more deliberate API design and data modeling early on, which can prevent architectural mistakes. On the other hand many dynamically typed systems allow you to prototype and build much more rapidly.
- Long-term maintenance, sure, I'll give a point to statically typed systems here, but honestly, some dynamically typed languages are really, really good in that aspect. Not every single dynamic language is doomed to "write once, debug forever" characterization. Emacs is a great example - some code in it is from 1980s and it still runs perfectly today - there's almost legendary backward compatibility.
Pragmatically speaking, from my long-term experience of writing code in various programming languages, the outcome often depends not on technical things but cultural factors. A team working with an incredibly flexible and sophisticated static type system can sometimes create horrifically complex, unmaintainable codebases and the opposite is equally true. There's just not enough irrefutable proof either way for granting any tactical or strategic advantage in a general sense. And I'm afraid there will never be any and we'll all be doomed to succumb to endless debates on this topic.
I don't know what I am doing wrong but nothing written in Python has ever worked for me.
I download the .py repo from from github or wherever and try to run it - errors.
I try to install missing libraries pip this and that - errors.
I battle fixing endless error with dependencies and when the .py finally runs - errors - wrong version of whatever library or wrong patch of this or that or the "production ready" .py does not work correctly on Windows or single file script uses excel library that has changed in incompatible ways 3 times in 2 years.
I Download all the files from the flashy looking web site and follow all the instructions to the letter - errors.
Python is anything but "robust".
It is the most fragile environment in the universe, worse than c, c++ and javascript put togeter, at least this is my experience with it.
That’s wild. The last time I had that experience with Python must have been more than 10 years ago. I’ll admit a decade ago you definitely did need to know way to many details about way too many tools from virtualenvs to setuotools to wheels, etc. to get things working from somebody else’s project, but imho, poetry and uv have really changed all that.
This is exactly my experience too. I avoid python software like the plague, because even when it does work, I can not rely on it continuing to work when python gets updated on my system.
You cant really make a judgement on python from this, as your story just screams user error. I have never encountered anything of what you say, and I have been programming in Python from before I had any clue what I did.
My own experience could hardly be more different. For that matter, I have never had to even look at a "flashy looking web site and follow all the instructions to the letter" in order to install something.
For example, to install yt-dlp, I followed these steps:
sudo apt install pipx
pipx install yt-dlp
Actually, only the second one, because I already had pipx (https://pipx.pypa.io/ — a wrapper for pip that does basic virtual environment management) installed.
Can you name some specific things in Python you have tried to use, and give more concrete descriptions of how you tried to set them up?
LLM can automate a part of the process where human might take slightly but, ultimately, any output generated by LLM cannot be trusted and should be checked by human that understands the issue...and that is actually the hard part where humans will struggle so they won't actually do it.
When human is producing the output that human is performing the following actions: -analysing the issue -analysing the exiting process -building the understanding of the existing process -building the understanding of how issue affects the existing process -producing the output to address the issue in the existing process -checking the output as it is being produced -updating the understanding of the existing process with lessons learned from the above -checking the final product to ensure that it has solved the original issue and hasn't broken some other part of the system
LLM can help speed up one of those steps (producing the output) at the expense of slowing down the other parts (which were already slow) and reducing the understanding and reliability of the existing system which will make future iterations even slower.
LLM can be used to speed up the generation of examples but just like in the past you could not just copy the example from some random internet search result, you should not just copy the LLM output without understanding it...and that is the slow part where LLM might not help (and might actually make worse) for most people.
And when in the past you encountered comprehensive and well documented output you could assume human that put that amount of effort actually understood what they were doing and wouldn't have expended that much effort to generate garbage, you cannot make that same assumption now with LLMs.
reply