carlmr
In some cases you want "default" handling, in other cases it's a runtime detection of a code issue. E.g. you could add a "fallback" case which is the same as "default" yet if your code doesn't exhaustively handle all sealed class cases won't compile. This would still create a fallback, if your sealed class is widened later on, but still allow you to error out if it's already the case right now.
If the LLMs were thinking in the sense that some people say they are, they will easily recognize the adversarial nature (e.g. letter counting in the language) and build their own tools to write conformant code right away. As a normal human would also build tools to solve the things we know we're not naturally good at.
The effect should be that a few tokens are spent on building the tool, and then the rest of the problem can be solved with a "normal" amount of tokens without brute-forcing the solution.
If the LLMs are glorified pattern matchers they might not find enough patterns in the corpus of human knowledge and remain inefficient at it.
The weakness I see is rather that this kind of problem-solving can be pattern matched on the corpus of existing human knowledge, so it may be that pattern matching on human thinking might still be enough to solve these problems.
https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
But getting back to the point, the C++ compiler doesn't have a borrow checker, so it can't have a bug in it. So it's on you, as the developer, to take care of all unsoundness.
While in Rust an issue is now filed, and with the fix, every future Rust program gets the fix.
The more dogfooding projects the better. And yes, rule of three applies.
Spot on, I've worked in multiple small, medium and large companies. And these internal platforms almost always turn into ivory towers of useless churn.
Even if being forced to use it internally, in a lot of cases the projects ended up buying the same solution (or a working version of it) from an outside vendor when it came to fulfill actual customers needs on the outside.
If that wasn't possible we built what we needed ourselves.
If you have internal customers, I still believe you need internal incentive alignment. Otherwise what the platform builds and what is actually used and needed drift apart.
And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm.
If you don't have a project-0 to test those assumptions against, you don't need to start that platform.
[0] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
I mean this is kind of what happens with any advice that has nuance to it, that's not carried with the advice.
E.g. if you have a point in 3D space with x, y, z coordinates. Array points as SoA of individual dimensions makes sense only if you do a lot of averaging and such on the individual dimensions.
If you mostly use the 3 coordinates together, SoA will have bad caching behavior.
So the better advice would be to try to keep things that are used together in the same cache line, whether it's on dimension or all 3. Usage makes the difference.
Agreed. Good design is when the things do what you expect them to do without reading the manual, don't reuse wording with other meaning in the wrong way. That way if you do encounter nee wording, you know you should read the manual.
I know this is contrary to your advice but mechanical pencil, get a Kuru Toga, it's a really nice improvement and not very expensive. It auto-rotates the pencil tip, so you don't have the sharp end at some point.
For permanent writing get a Uni ball gel writer, it's supremely smooth to write with. Also not hugely expensive.
They're both not the cheapest option, but an amazing writing experience without being the fancy kind of expensive.
Can we use this instead of grout in the bathroom somehow?
Yes, the math department.
In any case linear algebra, stochastics, calculus; plenty of engineering and science applications for all these.
It makes you feel that way because it is that way. They're not self-sufficient.
Especially in a filesystem I know where I placed something, but not always the title, so even if the search function was ok, which it mostly isn't, having to know the wording used for the title is really inconvenient.
I still can't wrap my head around how people find their files in the non-filesystem world. Whenever I need to work with files I take out my laptop.
At least codex listens to me telling it to use rg instead of grep, cause grep is often so slow. But when adding rtk it uses grep through rtk which is kind of annoying.
It's easier to find a needle in the haystack if the haystack is 50% needles.
Besides OO -> Functional this applies everywhere else in Computer Science. If you understood the fundamentals no new framework, language or paradigm can shock you. The similarities are clear once you have a fitting world model.
Even if it's once off, some people handle a lot of once-offs, that's exactly where you need good CLI tooling to support it.
Sure jq isn't exactly super slow, but I also have avoided it in pipelines where I just need faster throughput.
rg was insanely useful in a project I once got where they had about 5GB of source files, a lot of them auto-generated. And you needed to find stuff in there. People were using Notepad++ and waiting minutes for a query to find something in the haystack. rg returned results in seconds.
Still if you go blue collar you have to build your own business.
But that's the thing, in other languages you don't need a workaround to work on primitives directly.
If you ask them in isolation they may write a script to solve it "properly", but I guess this is because they added enough of these to the training set. But this workaround doesn't scale.
As soon as I give the LLM a proper problem and a small part of it requires numeric reasoning, it almost always hallucinates something and doesn't solve it with a script.
If the logic/math is part of a larger problem the miss rate is near 100%.
LLMs have massive amounts of knowledge, encoded in verbal intelligence, but their logic intelligence is well below even average human intelligence.
If you look at how they work (tokenization and embeddings) it's clear that transformers will not solve the issue. The escape hatches only work very unreliably.
Obvious things first, cameras have way worse contrast and low light sensitivity than human eyes.
Humans have much more evolved logical thinking capacity, even the stupid ones can figure stuff out that modern AI struggles with.
Humans have other sensors, too that they use to plausibility check the picture they see. I.e. one of the best sensor fusion systems on the planet.
When in doubt humans can figure out whether it's a lens occlusion or a some other artifact in their vision by virtue of moving their head around.
There's probably other things I'm not thinking of. In any case to make full self driving work we should first start by using all available tech to make it safe. When you have safe tech you can slowly start removing individual sensors while verifying that safety remains high. As the experience and system evolves there will be optimization potential.
And until we have that low light thing and high contrast figured out, camera alone doesn't cut it.