I wonder how often problems happen that the redundancy solves. Is radiation actually flipping bits and at what frequency. Can a sun flare cause all the computers to go haywire.
I strongly dislike flexible input like
__Unambiguous___, *Unambiguous*
I’m reminded of the time Microsoft allowed mistakes in html writing. They attempted to parse a wide variety of common user errors. The effect of this was no standard and nobody else able to write a Microsoft compatible parser.
I dislike Nim lang because of this. At least Nim defined the specification. Still though I think it creates more cognitive load learning every legal variation and it makes searching more difficult.
I think to authors point if Markdown actually had a strict simple definition with one way to do it and no embedded html we would be better off.
I’m developing on an Nvidia Orin which requires Ubuntu 22.04. Snaps are broken on this platform. I used an alternative ppa that provided a chromium.deb.
It’s kind of interesting relating this to LLMs. A chef in a kitchen you can just say you want PB&J. With a robot, does it know where things are, once it knows that, does it know how to retrieve them, open and close them. It’s always a mystery what you get back from an LLM.
I find dark mode much easier to read and far less eye strain. I guess it just shows that users should be the ones to set the preference. There are studies on monkeys showing light mode leading to myopia. Although lately I have come to learn there are lots of poorly done studies.
I tried this recently with what I thought was a simple layout, but probably uncommon for CSS. It took an extremely long back and forth to nail it down. It seemingly had no understanding how to achieve what I wanted. A couple sentences would have been clear to a person. Sometimes LLMs are fantastic and sometimes they are brain dead.
When I wrote my very first Rust code, I was trying to write to a socket. I got stuck on this task with misleading error messages for the longest time. I finally realized I had not made the socket object mutable. I’m used to Posix where you have an integer file descriptor and I don’t tend to think of socket write as a mutable operation. At least it doesn’t mutate state that my app manages. Perhaps something in the kernel gets mutated. I believe the socket interface may have been intended to support queuing which is perhaps why it needed to be mutable. I might have needed a lower level api. I just mention this because I think it’s interesting as to how it should be typed when mutation is external to the app. I didn’t follow through on using Rust and this was long ago so I’m sure some details are wrong.
I think this is different. It’s a statement that this product is not qualified to perform that function(autonomous killing decisions). I think it is pure madness to think AI is currently up to this task. I also think it should be a war crime. I think congress should pass a law forbidding it.
It’s not clear to me that the AI itself will refuse. You could build a system where AI is asked if an image matches a pattern. The true/false is fed to a different system to fire a missile. Building such a system would violate the contract, but doesn’t prevent such a thing from being built if you don’t mind breaking a contract.
The Reddit example is about two different design choices. The DOM is a tree of state that needs to stay in sync with your app state. So how to make that happen without turning your code into a mess. The old Reddit had to first construct the DOM and then for every state change, determine what DOM nodes need to change, find them and update them. Knowing what needs to change gets ugly in a lot of apps. The other alternative is to realize that constructing a DOM from any arbitrary state is pretty much the same as constructing it from initial state. But now you don’t have to track what DOM nodes must change on every state change. This is a massive reduction in code complexity. I will grant that there is something similar to the “expression” problem. Every time there is a new state element introduced it may affect the creation of every node in the DOM. As opposed to every time a UI element is added it may affect every state transition. The first Reddit can be fast, but you have to manage all the updates. The second is slow, but easier to develop. I’m not sure going any lower solves any of that. The React version can be made more efficient through intelligent compilers that are at better at detecting change and doing updates. The React model allows for tooling optimizations. These might well beat hand written changes. The web has complexity also of client/server with long delays and syncing client/server and DOM state, and http protocol. Desktop apps and game engines don’t have these problems.
I had a conversation with Claude about what language to work in. It was a web app and it led me to Typescript mainly because of the training data for the model, plus typing and being able to write pure functions. Haskell might have been preferred except for the lower amounts of training data.
I have often thought layouts should be done by a constraint solver. Then there could be libraries that help simplify specifying a layout, which feed constraints to the solver.
I was thinking about C++ and if you change your mind about whether some member function or parameter should be const, it can be quite the pain to manually refactor. And good refactoring tools can make this go away. Maybe they already have, I haven’t programmed C++ for several years.
Gotham Chess has done chat bot chess championships. The chat bots make a few good moves, and then begin making illegal moves, randomly removing or adding pieces, and completing ignoring obvious threats and attacks. It is so obvious that the pattern matching is not resulting in reasoning. Another example is Towers of Hanoi. An LLM can write code to solve it, because that’s an easy pattern match. But it can’t write out the steps beyond a 3 disk puzzle. It has no understanding of the recursive nature of the problem.
I have been spent many hours with them on coding tasks. As things currently stand once context or complexity reaches a certain point they become completely incapable of solving problems and that point occurs on very simple things. They appear completely brain dead at times although they are magnificent liars at making you think they understand the problem. Although, I recently got chatGPT 5 to solve a problem in a couple hours that Claude Sonnet 4 was simply never going to solve. So they are improving. I don’t know the limits. I’m more hopeful that a feedback loop with specialized agents will take things much further. I’m extremely skeptical that getting bigger context windows and larger models is going to get us reasoning. The skepticism comes from observations. Clearly no one knows how thinking actually works.
I don’t know how to address the evolve part. LLMs don’t directly mutate and have selective pressure like living organisms. Maybe a simulation could be made to do that.
Some have realized that LLMs don’t really reason and that LLMs may not be as amazing as the claims. However, I think LLMs plus agents, plus advances that are likely to come may very well prove to be more valuable than anyone can foresee. It’s very difficult to predict the future profitability of tech.
ICE is targeting groups of people based upon a probability that some are illegal. This violates the 4th amendment. The 4th amendment requires reasonable suspicion of a specific individual. This is also why they don’t have warrants, because no judge would grant it. The LA courts have ruled their activity illegal. The federal government is appealing. The SCOTUS ruling allows ICE to continue doing what they are doing until the appeal is heard.
If Tesla has a “no charge” list, they should at a minimum notify Carfax. However, everybody buying a used Tesla needs to be knowledgeable about this caveat. Tesla has a duty to inform the public. How they do this I have no idea. Perhaps the vehicle should never have been released back to the owner if it’s so unsafe. I don’t how that would work legally and financially.
Something that might be useful would be a sub language that didn’t support all the dynamic features that make JIT difficult or slow. Perhaps a module could have a pragma or something to indicate the language set in use. Maybe like Racket. Simply not being able to add new methods or new member variables after initialization would help.
I recently saw an article about LLMs and Towers of Hanoi. An LLM can write code to solve it. It can also output steps to solve it when the disk count is low like 3. It can’t give the steps when the disk count is higher. This indicates LLMs inability to reason and understand. Also see Gotham Chess and the Chatbot Championship. The Chatbots start off making good moves, but then quickly transition to making illegal moves and generally playing unbelievably poorly. They don’t understand the rules or strategy or anything.
I sometimes wonder if the issue is really the parentheses or the ease of nesting. In LISP it’s natural to write
(f (g (h x))).
Whereas most people are used to.
a = h(x);
b = g(a);
c = f(b);
In C/C++ most functions return error codes, forcing the latter form.
And then there are functional languages allowing:
x -> h -> g -> f
but I think the implicit parameter passing doesn’t sit well with a lot of programmers either.
The article didn’t discuss ACK. I have often wondered if it makes sense for the protocol to not have ACKs, and to leave that up to the application layer. I feel like the application layer has to ensure this anyway, so I don’t know how much benefit it is to additionally support this at a lower layer.