As someone who learned programming with scratch in elementary school, the next step they did was using DrRacket but honestly I did not like it. I don’t remember anything I made with it but still remember my scratch projects. I think pygame would be a good next step as it is batteries included and let’s you build similar gui applications with an event loop. However, I haven’t used scratch since around 2010 so it could have evolved a lot since I used it and the concepts might not translate anymore.
Scratch was how I got started in programming back in elementary school. It was taught in our computer classes. Everything this article says is spot on, the social aspect is amazing. I made a few programs and got comments on it and stars which hooked me. Side note hearing griffpatch is still around amazes me, I remember playing his scratch programs and wishing I could eventually do that. What’s amazing is it’s all still around and runs![1]
The robotaxi’s draw will be its lower prices. They are removing the cost of a driver from the equation. Assuming the car felt as safe as a normal taxi, I’d take the cheaper one.
Well, we'd have to look at the cost of the hardware and maintenance and fallback remote operators and the R&D investment to evaluate whether a robotaxi fleet is indeed cheaper. And how much cheaper is it, exactly? 5%? 10%? 15%?
Would you pay a little more to have the most flexible, sophisticated intelligence on Earth (human brain + driver assist) or would you want to save a few dollars and risk having some dumb piece of software strand you in the middle of the road somewhere?
We all use Google Maps or Apple Maps when driving and most of us have seen these systems do boneheaded things. Just imagine the dumb things a robotaxi could do.
So robotaxis are perhaps mainly attractive to the very low income parts of population, people who might buy an inferior product to save a dollar or two. People who buy store-brand ketchup instead of Heinz ketchup even though it doesn't taste as good.
It's hard for a normal person to be excited about this.
I presume the human is still the most expensive cost. So you might be looking at cost reduction of over 50%. If that were true, then I would definitely take the robotaxi, assuming it's reached human safety levels of course. On the off chance that they leave me stranded, I'll file a complaint for full refund, and then just take another one
In other words, you believe the cost of the human is subtracted but there is no additional hardware/maintenance/remote-operation/R&D-investment cost to add?
Anyway, I think we can all agree that the only benefit of a robotaxi is that it's cheaper. And we don't know how much cheaper. So it's not surprising that most people aren't excited about them.
I don't know a single person who cares about robotaxis. In my experience, if you talk to people about robotaxis they just don't see it as big step forward. "What's the point?"
I think people under estimate just how much cheaper it is.
Conservatively, suppose the car lasts 100k miles, and costs $50k including maintenance. Suppose it gets 10mpg, and each trip is 5 miles. Gas is $6/gallon.
100k miles = 20k trips.
20k trips for $50k cost = $2.50 per ride + $3 gas = $5.50 fixed cost per ride, which is significantly cheaper than pretty much anything.
If my city had better public transport, I would use it more often. I don't like driving around everywhere. It's labor. While I am also pushing for better public transport, robotaxis can also fill that gap, provided it is cheap enough
Not even lower prices, but even to continue the current prices of Uber and Lyft (without burning VC cash), automation is needed. Even with the low pay for human drivers today, that's still too much for the prices charged by ride sharing to be sustainable.
Based on what? Ride share companies don't absorb any of the cost of vehicle maintenance, insurance, or fuel. Drivers are subsidizing a significant amount of the capital costs of running a taxi business that isn't exactly reflected in prices.
Additionally there's the problem of the market tolerating current prices. Like gasoline, even if the cost comes down it doesn't mean price goes down. Profit margins will increase if the market can sustain current prices.
> Based on what? Ride share companies don't absorb any of the cost of vehicle maintenance, insurance, or fuel. Drivers are subsidizing a significant amount of the capital costs of running a taxi business that isn't exactly reflected in prices.
Ultimately there's profit, drivers wouldn't do it if it weren't profitable.
> Additionally there's the problem of the market tolerating current prices. Like gasoline, even if the cost comes down it doesn't mean price goes down. Profit margins will increase if the market can sustain current prices.
I see a lot of competition in the space and the history of taxi services has been one of very low prices so I see the trend to continue in self driving.
I’ve had this research paper on my reading list for a while (but haven’t gotten to reading the full thing)[1]. Not necessarily just a file system but It lays out an entire operating system backed by a database and OS state interactions are done through SQL.
I’m not sure how one could enable others to contribute easily but just making the code open source as is would be interesting. Those with a passing interest in search engines can browse the code of a capable engine and pick up some knowledge. While those who really want to help out will find a way to run it and contribute (in the process helping document and maybe making it easier).
My philosophy to open source is just do my personal projects in the open even if it’s not “accessible” and if someone comes along and likes it they can contribute or fork it and modify to their liking. Or they might just browse the code and pick up something in passing.
Ah that’s cool didn’t realize how old it was. The content seems to have held up well. Showed up in google when researching NAT and imo it’s up there with Tailscale’s article in terms of how well it’s written with the drawings.
What’s powerful about nix is the language IMO. I was able to build an automatic WireGuard setup[1] with tagging that automatically works on each new machine thanks to the ability to do config as code. Just provide some basic config for each machine and the code turns it into an interface with peers.
The issue to me isn’t the language persay (it’s really a tiny surface area language, see the built in/lib functions [2]) but the tooling built around packaging is a hodgepodge mess of semi-documented workarounds (with Nixpkgs blessed ways vs user libraries) and is extremely difficult to approach and understand.
Here are my two favorite (bookmarked) links for packaging and developing for rust. The trick is keep packaging and rust development separate and use specific dev environment flakes. So for dev work just bring cargo and rust as the nativeBuildInputs in mkShell (and any non rust dependencies) and then use standard cargo for development. But for packaging use one of the fancy tools.
1. https://srid.ca/rust-nix
