228 karma · joined March 10, 2014
I know virtually nothing about this area but my naive take is that something that means it still only passes tests around half the time doesn't seem like a particularly big jump forwards.
What am I missing?
Yet another rehash of the smoke and mirrors bullshit I've been hearing every 5 years or so for the last 40+ years.
Horses for courses, as they say.
I've written a non-distributed app that uses the Actor model and it's been very successful. It concurrently collects data from hundreds of REST endpoints, a typical run may make 500,000 REST requests, with 250 actors making simultaneous requests - I've tested with 1,000 but that tends to pound the REST servers into the ground. Any failed requests are re-queued. The requests aren't independent, request type C may depend on request types A & B being completed first as it requires data from them, so there's a declarative dependency graph mechanism that does the scheduling.
I started off using Akka but then the license changed and Pekko wasn't a thing yet, so I wrote my own single-process minimalist Actor framework - I only needed message queues, actor pools & supervision to handle scheduling and request failures, so that's all I wrote. It can easily handle 1m messages a second.
I have no idea why that's a "huge dead end", Actors are a model that's a very close fit to my use case, why on earth wouldn't I use it? That "nurseries" link is way TL;DR but it appears to be rubbishing other options in order to promote its particular model. The level of concurrency it provides seems to be very limited and some of it is just plain wrong - "in most concurrency systems, unhandled errors in background tasks are simply discarded". Err, no.
Big Rule 0: No Dogmas: Use The Right Tool For The Job.
Language wars are boring and pointless, they all have areas of suckage. The right approach is to pick whichever one is the least worst for the job at hand.
For non-ringers, in change ringing the bells rotate 360 degrees each time they strike, from mouth up to mouth up. The clapper hits the bell when the it has rotated roughly 270 degrees from mouth up and is more or less horizontal, approximately 2 seconds after it starts moving. The bells are usually in the 100kg to 1000kg range (for US folks, that's 220lb to 2200lb), although they can be up to 4000kg. The only point when the ringer can exert control on the bell via the rope is when it is near the balance and mouth upwards, and speeding it up or slowing it down any more than one "beat" is physically very difficult on heavier bells, particularly if you are doing it for a full peal, which usually takes 3+ hours.
About the least important thing in the 2022 rules changes (https://framework.cccbr.org.uk/version2) was the allowing of jump changes.
p.s. there's a split-screen video showing the ringer and the bell he's ringing here: https://youtu.be/qrdLP15Xsuk?t=67
There are a fair few videos on YouTube as well.
Change ringing is a branch of Group Theory and is mentioned in Knuth. The Steinhaus–Johnson–Trotter algorithm for efficiently generating permutations was published in the early 1960s, but has been known about by change ringers since the 1600s. Source: https://en.wikipedia.org/wiki/Steinhaus%E2%80%93Johnson%E2%8...
But perhaps not in CA.
Although there isn't a vast corpus on Method Ringing, there is a fair amount; the "rules" are online (https://framework.cccbr.org.uk/version2/index.html), Change ringing is based on pure maths (Group Theory) and has been linked with CS from when CS first started - it's mentioned in Knuth, and the Steinhaus–Johnson–Trotter algorithm for generating permutations wasn't invented by them in the 1960's, it was known to Change Ringers in the 1650's. Think of it of Towers of Hanoi with knobs on :-) So it would seem a good fit for automated reasoning, indeed such things already exist - https://ropley.com/?page_id=25777.
If I asked a non-ringing human to explain to me how to ring Cambridge Major, they'd say "Sorry, I don't know" and an LLM with insufficient training data would probably say the same. The problem is when LLMs know just enough to be dangerous, but they don't know what they don't know. The more abstruse a topic is, the worse LLMs are going to do at it, and it's precisely those areas where people are most likely to turn to them for answers. They'll get one that's grammatically correct and sounds authoritative - but they almost certainly won't know if it's nonsense.
Adding a "reliability" score to LLM output seems eminently feasible, but due to the hype and commercial pressures around the current generation of LLMs, that's never going to happen as the pressure is on to produce plausible sounding output, even if it's bullshit.
https://www.lawgazette.co.uk/news/appalling-high-court-judge...
Sure there are now some shinier toys in the Prolog box but the problems with Prolog seem to be the same now as they were 35+ years ago - it's seen as a niche CS-only tool, where to get any traction at all you have to absorb reams of terminology that's mostly unknown outside of academia, or has been forgotten post-graduation - Prolog really doesn't do itself any favours, and never has.
I think expecting academia to ever "sell" Prolog is a bust - if it hasn't happened by now, it never will. Better to directly target people earning their crust writing code, and sell the benefits to them, with real examples, not Towers of Hanoi and N-Queens. And as far as practicable, try to relate them to things that they are more likely to already know, such as SQL or Functional programming?
"Although most people think of twisters striking ‘Tornado Alley’ in the US, the UK actually has more tornadoes per area than any other country."
https://www.manchester.ac.uk/about/news/new-map-of-uk-tornad...
It's just they are small, and short lived.
My car has UWB, there's a LED on the fob that blinks when it is in range and if it's stationary for a short time, it inactivates as well. Some experimentation suggests you need to be within about 5m of the car to open the doors.
The localisation seems to be very accurate, even if you can open the car from a distance it won't start unless the fob is physically within it. If I sit in the driver seat the fob has to be less than 10mm away from the outside of driver's window, otherwise it refuses to start.
The main issue is if you are using reflection, which needs metadata adding to describe it so the necessary metadata is included in the image. Some libraries already have it built in, and there are tools to help.
For building, https://github.com/sbt/sbt-assembly supports native Image.
Getting the musl stuff to work can be tricky, mostly-static (only libc dynamically linked) is an easier option.
I've built a CLI diagnostics app with Scala & NativeImage and I've embedded the Graal Python interpreter inside it to allow extension scripts to be written. The result is a zero-install executable that provides an n entire Python environment. I think that's a good showcase for one of Scala's strengths, it's interoperability with the Java ecosystem.
"Tesla’s drop came as the German EV market in January grew more than 50 per cent year on year, pushing its market share down from 14 to 4 per cent."
Not the sharpest, are you?