brainwipe

Came here to say this and delighted to see it!

Met him at GenCon UK in the 1990s. His Doc-From-Back-To-The-Future energy was absolutely mesmeric. He had five towers of D10s in a plastic tubes. Three towers was the standard dice we all had in our bags and two were towers of his Game Science d10s. The standard dice towers all had different heights but the two game science towers were identical heights. He explained that for the regular dice, the smoothing process (which made them nice to hold!) changed the shape enough that they weren't regular sized anymore. The Game Science dice weren't smooth (sharp edged) and so they kept their shape. Of course, if you want a die to roll fairly, it needs to be a regular shape.

I bought a Zocchihedron cos we were playing a game that used percentages (Icar RPG) but rolling it was hilariously haphazard as it was essentially a ball! Loved it tho. I later received the game science dice set as a gift, which I still have. Sadly little time to play these days.

I code modern C# during the day and Unity for fun and I found this a really good roundup.

It's also worth noting that Unity does all sorts of OO-breaking filth before passing to IL2CPP.

XML was much better than what was there before - which was a different standard for every endpoint and often no structure at all.

XML allowed you to use tools to build automatically. We have other better tools now but back then it was like magic. Download an XSD (the more common option to Relax NG but not superior IMO), point a pre-built tool for it and it'd build strongly typed model classes and validation checkers. Then, when you called the service, chances are it would work first time. It could also be used to write the specification too. That was unheard of before. Often the spec you'd get for service was different to what the endpoint served because keeping documentation up to date was not a priority.

XML then got a little overplayed. For example, XSL transforms allowed you to turn one XML into another and because XHTML existed you have people building entire front ends in it (not recommended). You ended up in a weird hinterland where XML wasn't just for representing structured data but it had built in functionality too. It was not the right tool for that job!

I've not needed it in a long time as I prefer lighter weight formats and I don't miss it.

Just my take, others will have their own!

I own my grandfather's slide rule, he was a master toolmaker for Rolls Royce (aerospace engines) in North London during WW2.

The title is irritating, conflating AI with LLMs. LLMs are a subset of AI. I expect future systems will be mobs of expert AI agents rather than relying on LLMs to do everything. An LLM will likely be in the mix for at least the natural language processing but I wouldn't bet the farm on them alone.

I was asked by an SME to code on a whiteboard for an interview (in 2005? I think?). I asked if I could have a computer, they said no. I asked if I would be using a whiteboard during my day-to-day. They said no. I asked why they used whiteboards, they said they were mimicking Google's best practice. That discussion went on for a good few minutes and by the end of it I was teetering on leaving because the fit wasn't good.

I agreed to do it as long as they understood that I felt it was a terrible way of assessing someone's ability to code. I was allowed to use any programming language because they knew them all (allegedly).

The solution was a pretty obvious bit-shift. So I wrote memory registers up on the board and did it in Motorola 68000 Assembler (because I had been doing a lot of it around that time), halfway through they stopped me and I said I'd be happy to do it again if they gave me a computer.

The offered me the job. I went elsewhere.

I've accidentally been using an AI-proof hiring technique for about 20 years: ask a junior developer to bring code with them and ask them to explain it verbally. You can then talk about what they would change, how they would change it, what they would do differently, if they've used patterns (on purpose or by accident) what the benefits/drawbacks are etc. If they're a senior dev, we give them - on the day - a small but humorously-nasty chunk of code and ask them to reason through it live.

Works really well and it mimics the what we find is the most important bit about coding.

I don't mind if they use AI to shortcut the boring stuff in the day-to-day, as long as they can think critically about the result.

Wonderful! My PhD was in stream anomaly detection using dynamic neural networks in 2003. Can't wait to go deep through this paper and find out what the latest thinking is. Thanks, OP.

This has been my life for the last 10 years and I know who my children really are. They're evil and I love it.

Then I would ask anyone to keep building on knowledge rather than training for an arbitrary benchmark. Filling your short-term memory with knowledge to be then dumped straight after will get you a good exam mark but doesn't mean you have anything close to a solid grasp. Most schools (in the UK in particular) optimise for grade outcome because that's how they are judged, that's not the same thing as being good at a task.

Exams are a poor measure of proficiency. Proficiency is gained by doing and stretching a skill over time. You can measure that in small increments than a periodic exam. At the end of a period, a student would have a body of work to demonstrate proficiency rather than relying on a single day.

When I taught at university there was a disparity between exam grades and the physical body of work they had submitted over the years. You'd see the grade and be shocked the did so badly. The grade reflected proficiency in examinations, not in the subject.