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.
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.
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.
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.