I've actually been toying with writing an Algol 68 compiler myself for a while.
While I doubt I'll do any major development in it, I'll definitely have a play with it, just to revisit old memories and remind myself of its many innovations.
As a fan of Algol 68, I'm pretty excited for this.
For people who aren't familiar with the language, pretty much all modern languages are descended from Algol 60 or Algol 68. C descends from Algol 60, so pretty much every popular modern language derives from Algol in some way [1].
I should have said "supermini". While mainframes had tried a variety of virtual memory schemes, the VAX was the first supermini to adopt the style of demand paged flat address space virtual memory which pretty much set the style for all CPUs since then. A lot of VAX features, like the protection rings etc., were copied to the 80386 and its successors.
Cockies are the pranksters of the bird world. They're smart and they think it's hilarious to mess with each other and anyone else. They also tear everything to pieces. So it's no surprise really that if any bird worked out how to operate a drinking fountain it'd be these hilarious little jerks.
The Bellmac-32 was pretty amazing for its time - yet I note that the article fails to mention the immense debt that it owes to the VAX-11/780 architecture, which preceded it by three years.
The VAX was a 32-bit CPU with a two stage pipeline which introduced modern demand paged virtual memory. It was also the dominant platform for C and Unix by the time the Bellmac-32 was released.
The Bellmac-32 was a 32-bit CPU with a two stage pipeline and demand paged virtual memory very like the VAX's, which ran C and Unix. It's no mystery where it was getting a lot of its inspiration. I think the article makes it sound like these features were more original than they were.
Where the Bellmac-32 was impressive is in their success in implementing the latest features in CMOS, when the VAX was languishing in the supermini world of discrete logic. Ultimately the Bellmax-32 was a step in the right direction, and the VAX line ended up adopting LSI too slowly and became obsolete.
That's one vision, but it's probably not the most likely one. People like privately owning cars, and as long as they're more convenient than hiring taxis it'll probably stay that way.
Here's another vision of the future - gradually everyone's cars become self-driving, and now cars are more accessible to a wider range of people. 30% of the population currently can't drive due to age or disability, but if cars drive themselves the elderly, disabled, and even children can now own and operate vehicles. And now you have 30% more cars on an already congested road system. That should be enough to make traffic jams the norm everywhere.
But in case that wasn't bad enough, consider this - now people can do other things while they travel, because they don't have to be driving. So, in turn, they can live further and further away from their workplaces in cheaper, larger houses and do more of their work on the go. And while they do this they're spending more time on the roads, and - you guessed it - causing more congestion.
And because parking will always be expensive and hard to find in busy city centers, people will set their cars to loiter while they visit, rather than parking. Just going round and round while their owners shop. Causing - you guessed it - even more congestion.
TL;DR - the most likely result of autonomous vehicles is out of control congestion.
This is a very cool project but I feel like the claim is overstated: "PyXL is a custom hardware processor that executes Python directly — no interpreter, no JIT, and no tricks. It takes regular Python code and runs it in silicon."
Reading further down the page it says you have to compile the python code using CPython, then generate binary code for its custom ISA. That's neat, but it doesn't "execute python directly" - it runs compiled binaries just like any other CPU. You'd use the same process to compile for x86, for example. It certainly doesn't "take regular python code and run it in silicon" as claimed.
A more realistic claim would be "A processor with a custom architecture designed to support python".
I remember the excitement around VR back in the late 80s. These new polhemous motion tracking devices and LED microdisplays were going to change the world! Except the technology was expensive and ultimately it kinda sucked. It was barely used outside academia, interest died off gradually and eventually it was tacitly acknowledged to be going nowhere.
Then 30 years on Oculus was founded and everyone who'd never used one of the old VR systems was super excited. To be fair, the technology was a step better - much cheaper and more accessible, low motion input latencies, better resolutions. But ultimately it's still not really quite good enough and it seems that the hard reality is it's not going to make its way into mainstream consumer everyday use this time either.
His estimate the LCoE of an electric vehicle with lithium batteries is off by a factor of ten. My back-of-the-napkin calculations make it to be $0.22–0.25 per kWh.
Let's compare two vehicles - an EV car vs an ICE car - in terms of their energy costs per mile, including energy storage. Using the above numbers the EV comes out to around $0.07 per mile including the lifetime costs of the battery, and the ICE comes out to around $0.125 per mile.
In short - his numbers are completely wrong and when calculated correctly prove the opposite of what he's trying to say.
In my country (Australia), companies have been found guilty in court when making that claim. It considered false advertising to claim your product is "unlimited" when it is not, in fact, unlimited.
In the end it was a dumb comment by one of the Go devs which got jumped on by all the Go haters. Contrary to the popular meme, Go's not just for mid-tier programmers - it never was (and to be fair to Rob Pike, they've twisted what he said). But sure, it makes it easier for programmers at all levels to get started, and to get real work done. That includes advanced people as well as the inexperienced.
I think the ultimate goal of making a programming language is to cause the least friction for a programmer trying to get real work done, and in my experience Go's great from that point of view. Language bells and whistles may be exciting, but often don't pay their way in terms of real world productivity, IMHO.
