If we had super-smart AI with low latency and fast enough speed, would the perceived need for / usefulness of running multiple agents evaporate? Sure you might want to start working on the prompt or user story for something else while the agent is working on the first thing, but - in my thought experiment here there wouldn't be a "while" because it'd already be done while you're moving your hand off the enter key.
Mindstorms and the original RCX were a huge part of my college memories; I had a professor who used them for one of our classes. I built a substantially large "dragon" robot where the head + neck were actually a robot arm that could grip things, and it moved on treads. It took three RCX's "networked" together to get enough inputs and outputs for all the motors and functions. I accomplished the 3-way communication by making a parabolic reflector for the IR out of white cardstock; the three RCX's sat side by side and all aimed at the same reflector. The one in the middle controlled the outer two; each knew to only reply based on the first part of the message, so there was no contention.
I left that model with university which they kept as a display; I felt a little guilty having used up most of three Mindstorms sets for my project. Later I bought my own Mindstorms set, and then one of my then-wife's coworkers - whom we didn't know, and I don't know how she knew of me - randomly gave her a 2nd Mindstorms set to give to me. I keep meaning to re-create this dragon robot someday, leaner so it only takes two RCX. I have a lighter design now for the gripper + wrist section which, like the rocket equation, would allow the whole rest to be smaller if the last stage is smaller.
I once attended a talk by someone who is or was big in the node.js world. He opened with the premise, "a static type check is just a stand-in for a unit test."
I wanted to throw a shoe at him. A static type check doesn't stand in for "a" unit test; static typing stands in for an unbounded number of unit tests.
Put another way, this common misconception by users of languages like Javascript and Python that unit testing is just as good as type checking (plus more flexible) is a confusion between the "exists" and "for all" logical operators.
When I was trying to improve compile time for my game engine, I ended up using compiled size as a proxy measure. Although it is an imperfect correlation, the fact that compiled size is deterministic across build runs and even across builds on different machines makes it easier to work with than wall clock time.
As a serious DIYer with engineering knowledge and a bit of HVAC understanding, I find the sleek/modern design in the pictures of this product to be the opposite of reassuring. (Maybe I'm not the target customer.) It's for the same reason that after initially being interested integrated solar generators, in the end I went with a solar system that, while sold as a kit, consisted of independent components. With a solar generator if the electronics go bad the whole thing (including expensive batteries) is potentially a write-off and not easily fixable. I fear the same thing with this.
I'm also looking askance at the picture or rendering (next to "Installation Process") showing the PVC drain pipe going _up_ before it goes horizontally. How does that drain? I realize a graphic designer was probably just trying to make it aesthetic without understanding how it really works, but you yourself do understand as you detail in your post.
I resonate with the idea of your mission and your description of current market deficiencies. I just wish the product were more like the solar kit I bought as separate components or the PC water cooling loop I pieced together from a web store that specializes in that. Maybe that's an unrealistic hope. But I don't have to like the over-integrated alternative.
(I realize heat pumps and air conditioners have a requirement that the components have to be appropriately sized to each other to work as a system. But that could be overcome with software that advises the consumer what parts work together. We currently spend equivalent effort on using software to lock the consumer out instead of helping them make informed choices.)
I learned to drive from GTA III (before I had my license). I'm convinced the reflexes developed playing that game saved me from what could have been a bad accident in real life.
I was driving on an interstate and traffic went from wide open (70 mph) to stopped. The end of the line of stopped cars was just over the crest of an overpass (so I couldn't see), and I was in a compact car (lower to the ground, and I'm short, so doubly couldn't see the stopped vehicles over the crest of the overpass).
With no time to stop, and almost no time to react, I instinctively avoided the stopped car and S-turned onto the shoulder, which gave me stopping distance. I don't think I could have reacted this quickly without video game-reflexes. The pickup truck that had been behind me locked up his brakes and screeched to a halt occupying the space my car would have been, if I had even been able to stop.
Side note, this is also why it REALLY annoys me to see impatient drivers in traffic jams dipping out onto the shoulder to "have a look." In fact in the event I described I only barely stopped behind someone else who had gone onto the shoulder. In that case I don't know whether that person went onto the shoulder after traffic slowed, or if like me they'd barely avoided hitting the line of stopped cars.
The author of the article also sounds like the sort of individual or clique who derail Stack Overflow posts because they feel the premise of the question is wrong (leaving both the original asker and any later reader with their actual problem still unsolved).
I was in USMC boot camp on 9/11/2001. You don't get much chance to consume media during training, and they put us on lock down and gave us only limited information. We knew kind of serious attack had happened, but not exactly what.
By the time I got out of training, the news cycle had moved on so it wasn't until the first anniversary of 9/11 that I saw the news footage of the event for the first time.
Coincidentally I ended up stationed in Washington, D.C. and from my barracks I could see the construction cranes working on the damage to the Pentagon.
So it's this weird combination of feeling connected since I was in the military when it happened and then lived near one of the sites, but I also missed a lot. This site could help me see some of the experience I missed.
The flip side of this is demonstrating humility and being a ticket monkey for a year, only to slowly realize you've been taken advantage of, and as you approach year #2 realizing that neither you nor anyone on the "ticket monkey" team ever has or ever will move to the new development group. I once had the experience of being duped by a company that (accidentally, or maliciously) advertised two Developer positions when in actuality they wanted one Junior Developer and one mid-level Developer. Our resumes ranked similarly so they arbitrarily put one of us on the ticket-monkey team and the other on the new development team. I should have either raised hell or gone elsewhere when I found out the level I received was not the one in my offer letter (the pay, while the same, was already below-market anyway), but like a chump I took it as a character building opportunity and thought I would work my way up. What I learned was that that strategy works in a dysfunctional company about as well as it works in a dysfunctional relationship.
The trick is you've got to reduce your "saturation level" of #includes in header files, by preferring forward declarations over #includes, and using the PIMPL pattern to move your classes' implementations into isolated files, so that transitive dependencies of dependencies don't all get recursively #included in.
When it comes to templates, one has to be very aggressive in asking "Does this (sub-part) really have to be in template code, or can we factor this code out?" Any time I write my own template classes, I separate things between a base class that is not a template, and make the template class derived from it. Any computation which does not explicitly depend on the type parameter, or which can be implemented by the non-template code if the template just overrides a few protected virtual functions to carry out the details, gets moved to the non-template base class.
If your problem is not with template classes which you have written, but with templates from a library, consider that in most (all?) cases there is still some "root" location (in your code) which is binding these templates to these user-types. This root location will either itself be a (user-written) template class, or it is an ordinary class which "knows" both the template and the bound-type(s). Both of these cases can be dealt with either by separating it into non-template base and derived template, or using the PIMPL idiom, or both.
The general principle is that what you allow in your headers should be the lower bound of the information needed to specify the system. Unfortunately this takes active work and vigilance to maintain, and a C++ programmer is not going to understand the need for it until they reach the point of 30 minute builds and 1.4GB's of .o files.
This is a very interesting paper. Its invocation of state space over time as a model of program side effects reminds me of an idea I had a couple years ago: if you think of a program as an entity in state-space where one dimension is time, then "private" object members in OO-programming and immutable values in functional programming are actually manifestations of the same underlying concept. Both are ways to create fences in the state-space-time of a program. Private members create fences along a "space" axis and functional programming creates fences along the "time" axis.
Aside from metaprogramming, from reading the "four reports" document that is the first Google link, it seems PIE also addresses another hard problem. In any hierarchically organized program, there are always related pieces of code that we would like to maintain together, but which get ripped apart and spread out because the hierarchy was split according to a different set of aspects. You can't get around this problem because if you change what criteria the hierarchy is split on in order to put these pieces near each other, now you've ripped apart code that was related on the original aspect. I've come to the conclusion that hierarchical code organization itself is the problem, and we would be better served by a way to assemble programs relationally (in the sense of an RDBMS). It seems like PIE was in that same conceptual space. Could you comment on that or elaborate more on the PIE system? Thanks.