For some reason, Java has the same feeling. Professionally I do both embedded and statistical computing, and Java's been nearly anathema to this. But every 5 years I patch a hobby project I did once in college, and it comes right back (and with JVM hot reloading too.) It gives me the engineering warm and fuzzies.
> But I think we will swing back to using GUIs when we find a performant way of making them, I don't know what it is yet but surely someone is working on this.
I might be missing something here, but wouldn't any UI toolkit that doesn't live within a WebView work?
Yes, and of those, my impression is that there are niche ones that look OK, game engines that look great but take a lot of work, and then there's just TUIs, which look retrocool and run blazing fast, and are really easy to write.
> and then there's just TUIs, which look retrocool and run blazing fast, and are really easy to write
I mean, I don't even think that's true. Many TUIs are bloated, dogshit slow, and it's not trivial to write complex TUIs without glitches or flickering. The more people start making TUIs because it's the current fad, the worse they will get.
You're probably right. TUIs (being old) have selection bias towards quality. However, my experience writing TUIs is that it's not even the same class of difficulty as writing GUIs. GUIs by any means have way more overhead and learning curve. Not to mention that a TUI is more likely to be immediately CLi compatible via adding a --no-tui flag, or CLI patchable via --tui.
I suppose. I think it depends on your tooling somewhat. I mean, looking at the feature article, Bonsai lets you define TUI elements with an HTML-inspired syntax -- so if you're using that, it's a similar difficulty as writing a web interface, minus starting a server, Electron, or styling stuff yourself. You can just stay in the terminal. That's nice! But if you don't have such facilities and you want something more elaborate than just sequentially printing information, TUIs can be a bit rough.
> So I guess my question is: what do you see as the reasons why you'd pick a particular school of micro control flow as a microcode engine implementer?
For a comprehensive answer, a good vintage introductory digital design textbook is Ward and Halstead's 1989 Computation Structures, from the "peak CISC" era! [1]
There, the second (vertical) type is often used for highly complex instructions/fancy addressing modes, that you might want to implement with some sort of procedure abstraction, loops, working memory, etc. A "luxury" vertical microcode engine would have facilities like "microprocedure calls", a micro-stack and workspace RAM, a micro-ALU, dispatch table micro-instructions. The authors use the suggestive term "interpretive microcode".
String instructions come to mind as a complex example; non-register machine architectures (stack machines); tagged data architectures that have instruction-level polymorphism (e.g. Lisp machines).
The culminating project of Ward and Halstead is an elaborate two-level microcode system (vertical on horizontal/second on first). I think the first Motorola 68k had this architecture -- here is the patent. [2]
It's genuinely a fun read. The "write an micro-interpreter for your CISC ISA" approach is hopelessly out of date now that we need pervasive microarchitectural parallelism, and have HDLs.
So, I've read Computation Structures. And agreed, an absolutely fantastic text. [0]
However, my question is kind of orthogonal to vertical versus horizontal microcode.
As a counter example I'd point to the microcode format of the system 370/145, which while pretty clearly being something that would be described as vertical microcode also doesn't have implicit control flow [1]. It's a little on the wide side for vertical microcode at 32 bits, I'll grant you, but it has an op field(s) with about a dozen variants that then is used to further decode the other fields, at an overall decode complexity comparable to a RISC arch. Horizontal microcode looks more like 'these specific bits just always plug into this mux, and are simply set to some default if unused in this specific operation, reducing decode to essentially wires'. That being said, it also doesn't have an incrementer on the program counter, with the last byte of instructions encoding a (conditional) branch to the next instruction[2].
For another example, I'd point to modern microcode formats in Intel and AMD cores. They pretty universally have a vertical microcode instruction format (though grouped into triads or quads of instructions typically) then paired with explicit, dedicated microprogram control flow field for the group. The uops there are pretty wide at 48-64 bits typical, but they sort of need to be to fit immediates that are common for 64 bit archs, and also fit into that RISC like level of decode complexity you see in vertical microcode. [3]
[0] - As an aside, if you like Computation Structures, I'd recommend The Anatomy of a High-Performance Microprocessor: A Systems Perspective by Shriver and Smith as well. The mad lads stuck a surprising amount of the RTL for the AMD K6 in that book, albeit translated into some custom academic langauge. That mid 90s era design of a multi instruction per clock CISC decoder dumping a speculative instruction stream into an OoO RISC like backend is arguably just as much peak CISC as the early 80s given that it won against the UNIX RISCs by the early 2000s and survives to this day with remarkably few tweaks relatively speaking. CISC seems to be kind of like the Roman empire; any time it starts losing the war, it just unashamedly starts integrating the concepts of its competitor it's losing to. Which is great in this case. That's called good engineering.
[2] - Though it does have an explicit far jump/call instruction for control flow outside that window addressable by that byte, and a couple other bits sometimes depending on the instruction format.
Love that part. It really illustrates how incompetent these people are. That’s why the need for robots, they are projecting their incompetence on other people!
Also, if this is the best they can do and left such a mess, don’t let them operate robots or any machines! Teach them to use a mop and then maybe upgrade them to a vacuum, and if they pass, let them use a sink garbage disposal under adult supervision.
The were incompetent enough to go to real world testing when these issues would have been obvious from a basic model kitchen test. Obviously their bot is in the very early development stages where it can't do any of the basic things right, they're nowhere near the phase where they needed real world testing. You don't need a real house to tell that your bot keeps damaging furniture, floors, and other items. You iron that out in the lab, then go in a real setup.
And yet they weren't able to build a model house or even just some model rooms for a controlled environment and practice there full time first. They could have done round the clock testing, with full flexibility of the arrangement, no need to waste time moving hardware around and risk damage, no liability, and more. A fake house costs next to nothing. A (fake) model kitchen is cheaper than an Airbnb stay.
Have you seen how many public demos from manufacturers of advanced robots like Boston Dynamics are using "artificial" obstacles and layouts? It's obvious they did a lot of development in those conditions. You don't need someone's home to find out if your robot can grab a plate without destroying it, or climb a flight of stairs.
The company could also test the bots in their employees’ homes for no cost. If employees aren’t comfortable with the bots in their own homes, then they shouldn’t let them loose in others’.
I personally would not want my employer putting anything with an AI or camera inside my home. That would be a non-starter. And I work for a company that uses cameras and compvis.
I don't want any of my personal life observed by my professional life and vice versa. It is bad enough that /I/ have to observe both and try not to pass judgement on myself.
I think you're right and hope this stunt damages their valuation. As an investor I would have serious doubts about a company which at this stage doesn't have the brain or the money to have a proper development plan and resorts to desperately throwing anything out there, hijacking an Airbnb rental as their lab. That reeks of incompetence, maliciousness, and desperation rolled into one.
So many characters worthy of an epic story. The last one would be the Good Samaritan, or some sort of elderly sage...
> Before leaving, I asked him whether he even knew what was inside the package.
> He answered very casually that he had no idea and that he did not need to know.
> I then asked whether he at least knew which company had entrusted him with the delivery. He replied that it was simply "a friend" who had asked him to temporarily keep the box until someone came to collect it.
> I switched it on briefly, and that was actually the moment when the hardware shop owner himself suddenly became excited[...] Seeing the Apple logo appear on the screen, he immediately smiled and said something along the lines of, "Ah… a MacBook is a MacBook. Apple is still Apple."
The goodness of the people in the chain make me think that the rider would have had a much greater than 50% chance of following through properly. But it's good that Django decided to further increase the odds by taking matters into his own hands.
Hi there – someone who's worked on NIH (NIMH) funded projects.
Our primary interest is in being transparent and reproducible. NIH has supported this for a long time – e.g. pushing people to post deidentified datasets online in central repositories. Since it's also good practice to provide your code in a reproducibility package, there is, literally, nothing to hide.
Recent MAHA-era large-scale funding opportunities have embraced this as "gold-standard science", and explicitly require separate reproducibility teams.
https://www.instagram.com/corpsofengineers_portland/
reply