Then you deeply underestimate how difficult the problem is, and deeply misunderstand where all the effort has been spent in developing autonomous vehicles.
If all the effort has been spent in trying to replicate the human brain then I am comfortable saying that is a mistake.
We have a tool that can tell with great accuracy how far away an object is. The suggestion that we should ignore it and rely on cameras that have to guess it because “that’s how humans work” is absurd, frankly.
Before you can learn how far away an object is, you must decide: which laser return corresponds to which object? In fact, what counts as an object? Where does a tree stop and become a fallen tree branch? Is that object moving towards me? Is the apparent velocity of this point represent the fact that the object is moving, or that it's rotating, or that it's flexing, or dividing, or all 4? Is that object moving towards me but that's ok because it's a car that's going to stay in its lane? What's a lane? What's my laser return for where the lane is? Should I stop at this intersection? What's my laser return for whether the light is red? Am I in the blind spot of the car in front of me? Is he about to shift into my lane because he doesn't see me? What laser return do I get to tell me whether his indicator is on?
The problem of understanding what is happening in front of you while driving is preposterously more complicated than just a point cloud of distances. That is .01% of the problem. To solve the remaining 99.99%, you need interpretation of photons and sound waves into a semantic understanding that gives you predictive power to guess how the physical world will evolve and avoid breaking the rules of the road. Show me a mechanized way of understanding the causes of how the physical structure of the world is about to evolve, and I'll show you something that is imitating a human brain, however poorly. The cameras give you _plenty_ of data to determine 3D structure, at a higher resolution than the laser, without being emissive, for cheaper. It's a completely reasonable approach to focus your limited computational hardware on interpreting the data you have instead of adding more modalities with their own limitations that (according to nature) are demonstrably unnecessary.
The world is more complicated than slogans and pitchforks and Elon Bad.
People get into accidents not because they don't know with great accuracy how far away an object is.
They get into accidents because they make bad decisions and get distracted.
If AI makes better decisions and don't get distracted, the amount of accidents will already be greatly reduced compared to humans.
Having lidar in addition to cameras will be of marginal benefit (but a benefit to be sure) when you realize what is actually important: proper modeling of the environment. And for this, cameras are better at providing than lidar, so you still will want cameras anyways.
The focus on lidar is really a red herring. You merely push the computational budget you have to understanding a point cloud instead of vision. You're back to square 1 of "how can I properly model the environment given this sensory modality". This is the part that essentially needs human level understanding of the world that you're missing.
As the other commenter says, you deeply misunderstand the problem.
It would be interesting if, with all the anxiety about vibe coding becoming the new normal, its only lasting effect is the emergence of smaller B2B companies that quickly razzle dazzle together a bespoke replacement for Concur, SAP, Workday, the crappy company sharepoint - whatever. Reminds me of what people say Palantir is doing, but now supercharged by the AI-driven workflows to stand up the “forward deployed” “solution” even faster.
There's a line in the first season that runs as an undercurrent through the whole show ("Computers aren't the thing. They're the thing that gets you to the thing"). Joe originally says this to make the viewer think about technology, evoking the dawn of the personal computer and subsequently the internet. But later on, you're invited to re-interpret that statement as being about people: computers and technology were the thing that got the main characters to work together. It's the -people- that are the thing.
Part of what makes the show so good is that it's one of the few renditions in TV / movies of the joy of engineering something, and the constant tension that comes from working with great people. Great people inspire you, but they also challenge you. The show does a great job of portraying realistic conflicts that arise between different personality types and roles, as well as cleverly exposing the limitations of those personalities. With just Gordon, you'll get a stable and well engineered product but it won't be revolutionary. Joe has the vision but he can't actually _do_ the substantive part. Cameron has great substance and technical ability, but she's impractical and inflexible. Donna is responsible, effective, and clear-eyed - but unchecked, purely rational decisions erode the soul of a company into nothing. These differences frustrate our characters, and yet there can be no success without them.
I think many of us spend our whole careers chasing those rare moments where the right people are in the room solving problems, butting heads, but ultimately doing things they could never do all by themselves.
But invoking No True Scotsman would imply that the focus is on gatekeeping the profession of programming. I don’t think the above poster is really concerned with the prestige aspect of whether vibe bros should be considered true programmers. They’re more saying that if you’re a regular programmer worried about becoming obsolete, you shouldn’t be fooled by the bluster. Vibe bros’ output is not serious enough to endanger your job, so don’t fret.
I’m currently engineering a system that uses an actor framework to describe graphs of concurrent processing. We’re going to a lot of trouble to set up a system that can inflate a description into a running pipeline, along with nesting subgraphs inside a given node.
It’s all in-process though, so my ears are perking up at your comment. Would you relax your statement for cases where flexibility is important? E.g. we don’t want to write one particular arrangement of concurrent operations, but rather want to create a meta system that lets us string together arbitrary ones. Would you agree that the actor abstraction becomes useful again for such cases?
Data flow graphs could arguably be called structured concurrency (granted, of nodes that resemble actors).
FWIW, this has become a perfectly cromulent pattern over the decades.
It allows highly concurrent computation limited only by the size and shape of the graph while allowing all the payloads to be implemented in simple single-threaded code.
The flow graph pattern can also be extended to become a distributed system by having certain nodes have side-effects to transfer data to other systems running in other contexts. This extension does not need any particularly advanced design changes and most importantly, they are limited to just the "entrance" and "exit" nodes that communicate between contexts.
I am curious to learn more about your system. In particular, what language or mechanism you use for the description of the graph.
We’re using the C++ Actor Framework (CAF) to provide the actor system implementation, and then we ended up using a stupid old protobuf to describe the compute graph. Protobuf doubles as a messaging format and a schema with reflection, so it lets us receive pipeline jobs over gRPC and then inflate them with less boilerplate (by C++ standards, anyway).
Related to what you were saying, the protobuf schema has special dedicated entries for the entrance and exit nodes, so only the top level pipeline has them. Thus the recursive aspect (where nodes can themselves contain sub-graphs) applies only to the processor-y bit in the middle. That allowed us to encourage the side effects to stay at the periphery, although I think it’s still possible in principle. But at least the design gently guides you towards doing it that way.
After having created our system, I discovered the Reactor framework (e.g. Lingua Franca). If I could do it all over, I think I would have built using that formalism, because it is better suited for making composable dataflows. The issue with the actor model for this use case is that actors generally know about each other and refer to each other by name. Composable dataflows want the opposite assumption: you just want to push data into some named output ports, relying on the orchestration layer above you to decide who is hooked up to that port.
To solve the above problem, we elected to write a rather involved subsystem within the inflation layer that stitches the business actors together via “topic” actors. CAF also provides a purpose-built flows system that sits over top of the actors, which allows us to write the internals of a business actors in a functional reactive-x style. When all is said and done, our business actors don’t really look much like actors - they’re more like MIMO dataflow operators.
When you zoom out, it also becomes obvious that we are in many ways re-creating gstreamer. But if you’ve ever used gstreamer before, you may understand why “let’s rest our whole business on writing gstreamer elements” is too painful a notion to be entertained.
Since you still have C++ involved and if you are still looking for composable dataflow ideas, take a look at TBB's "flow_graph" module. It's graph execution is all in-process while what you describe sounds more distributed, but perhaps it is still interesting.
> we don’t want to write one particular arrangement of concurrent operations, but rather want to create a meta system that lets us string together arbitrary ones. Would you agree that the actor abstraction becomes useful again for such cases?
Actors are still just too general and uncontrolled, unless you absolutely can't express the thing you want to any other way. Based on your description, have you looked at iterate-style abstractions and/or something like Haskell's Conduit? In my experience those are powerful enough to express anything you want to (including, critically, being able to write a "middle piece of a pipeline" as a reusable value), but still controlled and safe in a way that actor-based systems aren't.
As Douglas Adams and xkcd #1227 have pointed out, the older generations have complained about this sort of thing since Plato. However, I do not believe this observation settles the matter, because it does not seriously contend with the null hypothesis: that we really have been steadily enshittifying the human experience since Plato.
Who has the right of it? Do the new generations simply not know what they are missing. Or is there something in human nature that makes us unavoidably crotchety as we get older and, thus, not to be taken too seriously? In my opinion, it is simply an open mystery.
On the one hand, many tangible, measurable things have improved over the last 2000 years, or, indeed, since the 90's. Steven Pinker has made this point somewhat convincingly by looking at unambiguously positive things like reduced infant mortality.
On the other hand, every single generation can give detailed accounts of how much more real and alive and authentic the world was a few decades ago. The accounts have similarities across the generations, but they are also rooted in specifics. To argue that we're all mis-remembering or failing to appreciate what the new decade has to offer is to insist on a rather fantastic level of self-doubt. If our entire lived experience is this untrustworthy, it kind of makes it impossible to rule on anything - good OR bad. Why should we default to trusting the younger generation?
I think the surrounding technological context of our age has brought this long-simmering matter to a boil. Now that our electronic communication is so sophisticated that we can essentially build "anything", it starts to re-focus our attention from "CAN we build it" to "SHOULD we build it". This question about digital society is complementary to the broader, long-standing civilizational question. Have the trillions of hours the human race has expended shaping our society resulted in _better_ life, or just life with a deeper tech tree?
One novelty of our time is how certain human enterprises play out at 10x speed in cyberspace. This lets us watch the entire lifecycle as they Rise and Fall, over and over. This lends perspective, and allows patterns to emerge. Indeed, this is exactly how Doctorow came to coin the term enshittification. If there's any truth to the life-really-is-getting-worse theory, you'd want to find some causal mechanism - some constant factor that explains why we've been driving things in the wrong direction so consistently. Digital life lets us see enough trials to start building such an account. You can imagine starting to understand the "physics" of why all human affairs eventually lead to an Eternal September. Wherever brief pockets of goodness pop up, they are like arbitrage opportunities: they tautologically attract more and more people trying to harvest the goodness until it's pulverized - a tragedy of the commons. Perhaps some combination of population growth and the inevitable depletion of Earth's natural resources lead to such a framework.
Whatever you think about it, I mostly just wish people would acknowledge that it is an unresolved debate and treat it as such. It is critical to understanding what it is worth spending our time on, and it is the kernel of many comparatively superficial disagreements (e.g. the red-blue culture war in US politics).
> On the other hand, every single generation can give detailed accounts of how much more real and alive and authentic the world was a few decades ago.
I don’t know that this is true, and I doubt it meant the same thing to Plato as it did to us; I read somewhere that in ancient times, nostalgia would have been for the world of the gods, not a specific time and place.
The thirties and fourties’ were probably not more alive and authentic than the
50’s and 60’s. The 1920’s were a cultural peak that retreated until the 1960’s, and prior to the Industrial Revolution, things didn’t change fast enough for like decades to be significant. The original documented example of nostalgia was about soldiers nostalgic for home, not explicitly their youth or another time.
All these feelings, “nostalgia” are going to hit different without shared cultural experiences, and changing technological and aesthetic context,
You're saying it's _rare_ for developers to want to advance a dependency past the ancient version contained in <whatever the oldest release they want to support> is?
Speaking for the robotics and ML space, that is simply the opposite of a true statement where I work.
Also doesn't your philosophy require me to figure out the packaging story for every separate distro, too? Do you just maintain multiple entirely separate dependency graphs, one for each distro? And then say to hell with Windows and Mac? I've never practiced this "just use the system package manager" mindset so I don't understand how this actually works in practice for cross-platform development.
Check it in and build it yourself using the common build system that you and the third party dependency definitely definitely share, because this is the C/C++ ecosystem?
I find this sentiment bewildering. Can you help me understand your perspective? Is this specifically C or C++? How do you manage a C/C++ project across a team without a package manager? What is your methodology for incorporating third party libraries?
I have spent the better half of 10 years navigating around C++'s deplorable dependency management story with a slurry of Docker and apt, which had better not be part of everyone's story about how C is just fine. I've now been moving our team to Conan, which is also a complete shitshow for the reasons outlined in the article: there is still an imaginary line where Conan lets go and defers to "system" dependencies, with a completely half-assed and non-functional system for communicating and resolving those dependencies which doesn't work at all once you need to cross compile.
For most C and C++ software, you use the system packaging which uses libraries that (usually) have stable ABIs. If your program uses one of those problematic libraries, you might need to recompile your program when you update the library, but most of the time there's no problem.
For your company's custom mission critical application where you need total control of the dependencies, then yes you need to manage it yourself.
Ok - it sounds like you’re right, but I think despite your clarification I remain confused. Isn’t the linked post all about how those two things always have a mingling at the boundary? Like, suppose I want to develop and distribute a c++ user-space application in a cross platform way. I want to manage all my dependencies at the language level, and then there’s some collection of system libraries that I may or may not decide to rely on. How do I manage and communicate that surface area in a cross platform and scalable way? And what does this feel like for a developer - do you just run tests for every supported platform in a separate docker container?
Genuine question - are there examples (research? old systems?) of the interface to the operating system being exposed differently than a library? How might that work exactly?
> examples ... of the interface to the operating system being exposed differently than a library
Linux syscalls, MS-DOS 'software interrupts'...
But that's not the issue, operating system interfaces can be exposed via DLLs, those DLLs interfaces just must be guaranteed to be stable (like on Windows).
Tbh, I'm not sure why I can't simply tell the gcc linker some random old glibc version number from the late 1990s and the gcc linker checks whether I'm using any functions that haven't been available in that old version (and in that case errors out). That would be the most frictionless solution, and surely it can't be too hard to annotate glibc functions with a version number in the gcc system headers when that function first appeared.
reply