I did a similar thing with a rack of test equipment. I had a PC power supply on each shelf, and used an NPN transistor to turn on the power supply whenever the USB port connected from the main computer to that shelf rack was turned on. Crude, but effective, out of band communication.
The local USB hub on the shelf was powered from the PC power supply on that shelf, so a single long USB cable from the shelf with the control computer could command the shelf (including the USB hub on the shelf) to fully power up or down, and then control several test devices through the USB hub, and none of the USB devices on the shelf (some of which were bus-powered) needed to worry about not getting sufficient voltage through a long cable and a hub.
> I think especially the cheap hubs will changes the parts used overtime and not update the revision.
Yeah, the last time I purchased them was December 2022, so I definitely don't know for sure that they still work. But they aren't the cheapest hub, so maybe?
But at that time, I purchased hubs from several manufacturers, and most of them didn't work. The first thing I had working was actually an eval kit from an IC vendor.
Also, many hubs that can theoretically be used powered or unpowered are terrible about backfeeding power, either to the host, or (more commonly) to the wall wart.
It's best to either always use the hub unpowered, or to buy a hub that always requires power, unless you've checked and made sure that it's not going to screw you over.
But then, I'm pretty sure you haven't said anything different than what I said in the great-great-grandparent of your comment, other than slightly fleshing it out for a couple of particular scenarios.
But you haven't covered the packing, which is the primary thing I was suggesting you might need multiple tables for if you really wanted to use tables and really didn't want to do shifting or multiplication.
You need to be careful with this one, or reductio ad absurdum might lead you to not build microservices, or even a monolithic app, before you have acquired your first customer.
In any case, if there were 3 trits, I'm not sure what the practical difference between a single table you describe and 3 different 256 byte tables, again depending on the architecture.
Yes a single table would have better cache effects for a single read, but presumably? you're doing a lot of reads in an unpacking phase.
Obviously, it partly depends on the implementation machine, how big a hole the tables blow in your cache, how fast the multiplies are, etc.
But it probably also hugely depends on the format that you want your trits in. If you use them unpacked, e.g. one trit per byte, then even if you're using tables, you still have to do a lot of manipulation (e.g. either shifting and oring, or having different tables, and a table lookup per trit and adding together to get the binary).
> I can guarantee you that most of these simply didn't go far enough;
And I can guarantee that I knew, when I wrote my comment, that I was summoning this very "No true Scotsman" argument.
> they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.
It always superciliously starts with how true lisp people are the most brilliant ever.
> Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.
And is eventually undermined by an admission of cognitive inflexibility, although not usually so quickly or in the same comment. Good job!
> For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp
Certainly. But why would that be? It couldn't possibly be that the programmers already there built a system using the tools of their choice, and that system is now running well and deemed maintainable enough they require additional developers for the same language, could it?
Sometimes, of course, companies change their implementation language. The most famous cases I know of this are Viaweb and reddit, where the companies moved away from lisp. The company's main motive in this, of course, is making money. If they have a good product that is deemed maintainable, why would they piss off the original team, who probably chose the language, by switching languages?
Many programmers have worked in lisp. Studies have shown that programmers routinely learn new languages and somewhat forget old ones; older programmers are typically only currently proficient in as many languages as younger ones.
A company with a successful product is going to attempt to leverage that success. Whether leveraging it looks like incrementally improving it, or like treating it as a prototype and throw it out, will typically be a long conversation between developers and management. Typically incremental improvements are greatly preferred; it is only when all stakeholders become convinced that a fresh start is required that massive changes like implementation language will take place.
The calculus, of course is changing with LLMs. See, for example, the recent migration of bun away from zig. That rewrite was spearheaded by a massively effective lone developer, the exact persona that is claimed to always prefer lisp. Sadly, he chose rust.
> compared to languages which demand much more effort to get anything substantial done.
It is not clear at all to me that other languages "demand much more effort" for the same end result.
It is clear that many non-lisp programmers value syntax, and many lisp programmers don't. Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp. I'm still awaiting psychological studies on this, but the rift is so large, I think there may be some significantly different brain processing going on between the two groups.
To your point, yes, it is also clear that, to the extent that lisp can match the productivity of other languages, whether it exceeds them or not, one of the tools that is needed to achieve this productivity boost in lisp is heavy usage of homoiconicity, and this results in every serious lisp program being a collection of DSLs, each of which is only understood by one person or very few people.
I cannot disagree, but many who should know better do.
I have seen people argue with a straight face that there are no copyright concerns simply because of the sheer volume of the data that LLMs are trained on.
This makes less than zero sense. If someone has seen code, or heard music, and creates something too similar, it is a copyright violation, even though that person has seen much code or heard much music before. This is why the concept of "clean room" implementation exists, and why the concept of the abstraction-filtration-comparison legal text exists.
LLM proponents will point to the fact that courts have ruled that using copyrighted material for training has been ruled fair use.
This actually makes sense. Just as you can read a book, so can an LLM.
The thing that, AFAIK, hasn't been ruled on yet, is when the LLM regurgitates something that is too close to the book. If a human were to do that it is a clear copyright violation.
To pretend that "dilution is the solution to pollution" in terms of LLM training data, and that anything the LLM produces is original material, is to give LLMs more rights than humans have.
It's kind of a useful distinction, but the categories are really blurry.
For example, the layout software vendors provide a solution that both uses non-determinism in their final product, and also checks the results against whatever criteria you give it.
If it tells you it will work, it's probably not lying, and if it tells you it won't work, it's almost certainly not lying.
So in your own creative process of building a board, you can rely on that.
Many LLMs don't have this property at all, and honestly, it really doesn't matter whether you are using the LLM to craft a legal document or to craft code; if you don't check the output yourself, you're possibly in for a world of hurt.
> Now if you are "running" your "generated code" that's where people will have strong opinions because it conflates the two completely different processes in the worst way possible.
I think a primary driver of the attractive nuisance here is that, because the execution of the resultant code is itself a deterministic process (even if the process that produced that code it isn't) people think that they can tame the process, by some combination of automated testing and looped automated reprompting.
At some level, they may not be wrong -- computer chips themselves are built on top of stochastic atomic processes, and google famously proved in its early days that it could have reliable processes on top of shitty commodity hardware.
But one key difference is that the nondeterminism in the atomic processes or in the non-ECC memory of the white box computers is uncorrelated.
And another key difference is that, unlike the layout software vendors, so far the LLM vendors seem unable or unwilling to properly self-check their own outputs.
To me, this is kind of the canary in the coal mine. You would think that the LLM vendors have every incentive to weed out bad results, that they, more than anybody else, have the understanding of root causes and probabilities that a particular output might be bad, and have more than sufficient resources to fix this, if it's not an intractable problem.
So Occam's Razor says that (currently) this is still an intractable problem.
> I would say [whether nondeterminism is bad] is unambiguously defined by the problem you're solving.
Sure. You gave an example where it can work. Another example is something like a PCB or chip layout engine.
That particular domain (layout) is NP-complete. You'll never have an exhaustive brute force search for the optimal layout, but...
You can subsequently easily check whether the produced layout meets all your acceptance criteria or not.
Another example that successfully utilizes non-determinism for good outcomes is the application of genetic algorithms to things like antenna design.
This works because (a) you have a relatively cheap fitness test; and (b) as with real evolution, the mix of combining working designs and randomly introducing mutations often eventually produces outstanding results.
Presumably, if you applied genetic algorithm techniques to, e.g., creating your LLM prompts, you could also get good results, but that would probably quickly get expensive in terms of tokens.
So we're left with people just semi-randomly modifying prompts in order to try to tweak results.
When it works, it can be amazing. When it doesn't work, it's like a brick wall.
I like your "embarrassingly nondeterministic" term, but I somewhat disagree with:
> A "bug" then would be considered "weak accuracy" not "crash" or "incorrect behavior",
When a lawyer asks an LLM for citations of cases that support his position, he is arguably doing something stupid, because embedding an assertion such as "Show me cases which support X" is just asking for hallucinatory trouble with many current LLMs.
Nonetheless, I submit that hallucinations are, by definition, "incorrect behavior" and not merely "weak accuracy."
Now, nondeterminism could certainly be useful to the lawyer, in that it could help an LLM make connections that LexisNexis might not have in their database. So asking an LLM for help with legal issues is theoretically not an insane thing to do, but the results need to be checked very carefully.
As others have discussed, people argue for many reasons, ego being one of them.
I didn't really understand this. I grew up before the internet, and I have ADHD, which essentially means I have limited working memory.
One of my compensatory strategies for this is to have a fairly comprehensive world model at the ready in long-term memory.
If you told me something that contradicts my mental model, I might argue, in order to figure out whether I need to update my model or not.
The argument between someone ego-driven operating on a motte-and-bailey basis, and someone who just truly wants to understand, but won't let it go because they feel they need to understand, gets ugly quickly.
Fortunately, I'm older, my model doesn't need to change as often, I'm better at discriminating about things I care about or that are irrelevant, and, of course, I can always disengage with "that's interesting; I'll have to research it" and go down a rabbit hole on the internet if what they are saying doesn't seem to make a lick of sense.
I will say that the need to be right -- not the need to lord it over others, or the need to prove I'm right -- has probably helped my programming career immensely.
The burning desire to be right can be completely orthogonal to giving a shit about whether others think you're right or not, or giving a shit about others when they're wrong and it doesn't adversely affect you.
The local USB hub on the shelf was powered from the PC power supply on that shelf, so a single long USB cable from the shelf with the control computer could command the shelf (including the USB hub on the shelf) to fully power up or down, and then control several test devices through the USB hub, and none of the USB devices on the shelf (some of which were bus-powered) needed to worry about not getting sufficient voltage through a long cable and a hub.