Posts by prandeamus 74 publicly visible posts • joined 23 Dec 2019
I definitely remember attending interviews (1980?) for Comp Sci course at Queen Mary College, London. Reading the interviewer's form upside down on his desk, he had a checkbox marked "BASIC Damage" such was the bad reputation that BASIC had in academia. Seemed a bit harsh at the time, though I understand the point.
You're being a bit hard on Pascal implementations there. It is is fair point that a lot of microcomputer compiled languages used some sort of p-code (UCSD Pascal most obviously), and I am sure there were others, if only because generating good re-entrant stack based code is a challenge on a Z80 and a nightmare on the 6502. The 6809 was probably the least awful 8-bit platform for that sort of native code. But true compilers were the norm in the minicomputer world. I remember working as a Southampton Uni undergarduate with OMSI Pascal in 1981 on a heavily overloaded PDP-11/45 running RSTS/E. A year or so before. Boffins in comp. sci. had ported Pascal on some ICL 1900 thing and a Honeywell doo-daa that were the mainstays of campus timeshared computing at that time. I think at the end of the day, too many people were seduced by C's ability to get down to the metal and relative flexibility on type conversion, in an age where programmers still had to consider hardware limits on 16 bit microprocessors. But that's a religious war for another time, I suspect.
I have transcended mere programming these days (I've promoted to places where I do less harm), but I was once heavily involved with C, and I'm currently taking an interest in Rust. What strikes me is that although memory-safety is certainly the Big Thing promoted by rustaceans, Rust has strong opinions about other things, too. There's a powerful macro system, a different approach to object-oriented development compared to C++, enums and exception handling may not match your experience elsewhere. If you are ahead of me you could probably add a half a dozen other aspects.
If you are a C developer trying to learn Rust thinking you only have to learn about memory management stuff, you're in for a world of pain. You've got to keep your mind open to lots of "different ways of doing things".
For the benefit of reflex commenters, I'm not passing judgement on whether Rust has made the "right" decisions compared to Your Preferred Language. I'm just saying it's not *just* about memory management.
Can someone who understands these better explain why "Texas" is the right place for this work to take place? I don't have the context to understand that remark. I'd assume that in general Texas is more generally a conservative/Republican state, thus more generally MAGA-facing, but don't want to jump to conclusions. How dull of me to ask for facts :)
Interviewee: "Here's my undergrad thesis project"
Interviewer: "Great! How do you fancy being head of marketing?"
Bias in LLMs is absolutely an important topic, and I say this as a white male with a traditional white male name.
But I also recall my undergraduate project work as being of sufficient to pass the degree rather than something I'd ever want to quote in public. Maybe reporting is misleading here: do undergraduates write theses in Sweden? I'd associate a thesis with a masters or PhD. Or maybe there's a company who has appointed a raw undergraduate to head of marketing; that would merit a raised eyebrow at least.
A more elegant phrasing is found in the BCPL (strong influence on C) reference documentation
"The philosophy of BCPL is not one of the tyrant who thinks he knows best and lays down the law on what is and what is not allowed; rather, BCPL acts more as a servant offering his services to the best of his ability without complaint, even when confronted with apparent nonsense. The programmer is always assumed to know what he is doing and is not hemmed in by petty restrictions"
https://archive.org/details/richards1979bcpl/page/n11/mode/2up page 5.
"Now had the issue of memory safety, etc, in C (or the lack thereof) been addressed by creating a sub-set of C and/or a few features to mitigate some issues like use-after-free then it would have been fairly trivial to do this..."
If wishes were horses...
I hear ya. But consider that the memory-safety aspects of C have been known since day 1 and no doubt there's chapter-and-verse somewhere out there in K&R or some Bell labs memo. Subsets of C have been created but C is so deeply dependent on certain things being done via pointers I don't think anyone can have something which is both a subset of C and capable enough to build kernel or drivers. Or maybe there is, but for some reason it didn't have traction.
Having worked for an anti-malware provider in a previous life, though not on the frontline, I can tell you that reputation is gold dust. It's true for any commercial organization of course, but particularly true in the antivirus world. I only hope that when the internal investigations happen, it won't be a witch-hunt in which one or two drones are fired. Mistakes happen but that's why we have quality control, right? And that's why you fund your test environments thoroughly, right? That's why there's someone on the board who will own this, right? We shall see.
Off-topic as its not about breaking the LLM or security I guess, but vaguely amusing and it's Friday.
I asked Gemini to suggest proverbs in languages other than English to express the thought "when you have a hammer, everything looks like a nail." It dutifully listed a variety of similar terms in modern major languages, always close in structure to the original. Not being an expert, I couldn't judge if they were accurate.
Then it suggested an equivalent in Yoruba claiming it translated into "The diviner with just the single kola nut cannot perform a major divination."
ok... sounds fascinating
Neither the translation or the claimed Yoruba text show up in google search anywhere. Which is unlikely, if it really was a common proverb (making allowance that the corpus on online Yoruba text would be significantly smaller than major languages like English)
Google translate declares the Yoruba text into "A valley is a threat not to sow great things"
If any Yoruba-phones see this, they can confirm, but that looks like classic hallucination delivered with utter confidence. Excuse me, I'm to buy more than one kola nut as I have major divinations to do this weekend.
The cynic in me says that pressurised support staff will not actually edit or check the content, or do it sloppily. Meanwhile anyone conscientious and half-decent in the team will have perceived low throughput, and will get the boot. Because the performance metrics don't allow for errors in LLM output.
One year later, Octopus energy writes 20% of their responses as haikus advising customers to lick their fingers and shove them into power sockets.
I'm not saying the LLM generation is worthless, but if the beancounters and shareholders don't understand the risk ...
"Ironically, one of the foundational strengths of the US itself is the notion that its Constitution is based on an idea rather than evolving from 'the divine right of kings'"
This is true. But to add irony of their own, too many citizens have elevated The Constitution to a position of majesty in its own right. For document with origins in the 18th century it is a remarkable achievement that merits a great deal of praise. But it should not be used as a gpld standard for evaluation of every new idea in politics and governance. It may be that XYZ is judged to be incompatible with the constitution, but that doesn't make XYZ morally wrong per se.
Although I believe the Z80s internal ALU was 4-bit, which just goes to show the tradeoffs that were made in those early days. That doesn't invalidate your point, to be clear. As a long-time 6502 developer there were times I would have killed for 16-bit registers and a stack that wasn't limited to 256 bytes. Or more than three on-chip registers. Or an increment instruction for A that didn't require you to clear the carry flag first (and so on).
It all prefigures the CISC/RISC architecture wars. Z80 was closer to the CISC camp, and some aspects of 6502 were quite RISC-y. (And before the purists peck my eyes out, I'm not saying that 6502=RISC in a strict sense).
The processor I really enjoyed writing code for was the 6809, but I didn't have many opportunities to do so. Oh, nice addressing modes and a consistent design!
I'm not looking for a flame war, but it's not really "assumption on which your argument pivots", just pointing out an ambiguity that threw me when reading your (interesting) article. I dare say Oberon was a reaction against bloated sorta-Pascal. As was Modula-2 in some ways: Wirth had a genuine skill for reducing things to their simplest form, although sometimes his work resulted in programming environments that were a teeny bit too simple. The world definitely owes a debt to Wirth for Pascal and so on. However, that wasn't the way your line of thought was constructed: you didn't mention Delphi or Turbo Pascal or Object Pascal in that context. You said "Pascal".
To be positive, I found the article worth a read and you make some good points, like making the effort to understand LISP, or something like it, in order to think differently about software. We should periodically jolt ourselves out of complacency.
"Oberon is a smaller, simpler, faster Pascal. Like Pascal, it's strongly-typed and garbage-collected [...]"
I think you lost me there. The original Pascal was stripped down in so many ways from its Algol predecessors, and one could argue it's stripped to the bone in ways which make it an excelled teaching language. Subsequent commercial implementations added back stuff that was needed for large scale development and that's a story in its own right. But is Oberon objectively net simpler than Pascal when it adds new features like dynamic dispatch? Was Wirth's Pascal ever garbage-collected, because I don't recall that? In what sense is Oberon faster - it was certainly possible write fast compilers for Pascal generating pretty decent code.
I don't have a downer on either language but it's thing like this that make it harder to appreciate your wider debating point. I love me a good polemic, but a polemic still has to have a core of hard logic.
Is BCPL's O-code similar enough to count?
Close but no cigar. Ocode successfully separated the front ends of the compiler (lexical, syntax analysis, and all that) from the code generator. The front ends outputted Ocode, and up to that point pretty much all BCPL compiler were the same. Some variations existed e.g. the Acorn BCPL compiler was structured as a set of overlays or whatever because of the extreme RAM limit on a BBC model B. The OCode was fed to the code generator stage which could vary wildly between implementations. So it was not originally conceived as a run-time environment.
Moving on a little, M. Richards did produce INTCODE, that was a simple virtual machine designed for interpretation, to help with bootstrapping. You could cross-compile BCPL to OCODE and code generator would output INTCODE, and then write a simple but slow INTCODE interpreter on the target machine. I think the idea there was to be "just good enough" to bring up a compiler on the target machine for which you could write a native code generator. INTCODE was a bootstrap aid, not an execution environment.
The next iteration was something like CINTCODE which was designed for interpretation. CINTCODE was designed for microprocessors where address space was at a premium (C=Compact). So in the Acorn implementation of BCPL for BBC Micro, the code generator takes OCODE as input and CINTCODE as output, and the CINTCODE was interpreted by code in the *BCPL language ROM. CINTCODE implementations did permit escapes to native compiled code for those time-critical bits. The BBC Micro BCPL was created at Richards Computer Product, run by John Richards, lovely fellow. M. Richards continued to develop this stuff further in academia so there's probably a divergence between the two over time.
That said, I think CINTCODE is roughly contemporary with UCSD p System.
I'm an old man now, forgive my slips of memory.
What VB did very well is to show that certain kinds of small and medium sized apps could be built without recourse to C and complex SDKs. Was it the first? No - there was SQL/Windows, there was Actor, and probably others. Was it the world's cleanest or neatest programming language? Lord, no. After a year or so, Turbo Pascal for Windows knocked it out of the park in so many ways. Was it particularly fast? Nah. Was it the kind of tool that amateurs could write terrible code? Yes. I don't wear rose-tinted glasses when I think about it. "Option Explicit" came too late to stop people making awful errors. People often didn't understand how Variant worked. There was the bizarre DOS-only mutant. Team programming was hard. It never really got to grips with O-O programming until VB.NET forced a complete overhaul. Having two different versions for VB4 (16 and 32 bit) was a pain. "On Error Resume Next" was the dumbest idea ever. I don't think VB6 had a true compiler (feel free to correct me). By all means, list the unfixed quirks and bugs. I never got to grips with data binding. No, I don't want purple and yellow buttons, oh my eyes!
But it opened the market very convincingly. It was just-good-enough, and sometimes that is what counts. You could paint a screen, write the event handlers, and get things done. It had enough extension capability (calling C DLLs, and the VBX/OCX development model) to support a decent third-party tool market. In the city of extreme visual impairment, the monocular one reigns.
My house is a typical 30s built suburban semi, with all internal walls being brick. In some cases, definitely some sort of Friday afternoon brick with neutron star density. It has an extension beyond what were originally the outside walls. As you would expect it's a pain to get coverage from the main router. I've tinkered with additional access points with mains power backhaul, and though they work quite well for devices that don't move around like the Amazon firestick, phones and tablets and laptops don't handle the transitions well as you move around the house. Are true meshes - with reliable switchover as you move around - even possible? Should I try a single access point with a honking big ariel (or whatever)?
"Confusion" was a bit of a weasel word in Unity's statement. The changes were crystal clear and completely understood. That's why people were angry, because they could see exactly what impact they would have. As "Angst" , let it pass.
The correct response would have been "we screwed up, and we're rethinking this". As it stands it feels like one of those classic passive-aggressive fake apologies.
I know a number of people who volunteer in parish councils, town councils and so on as their contribution to a functioning democracy. They genuinely do it out of a willingness to serve. I count as friends in this category both Tory and Labour councillors. But it's hard to get elected without a party ticket of some kind. There are a few independents in local government, but most have affiliated themselves with a party rosette of one kind or another.
Those genuine people who just want to get the paths weeded and timely dustbin collections, through their party allegiances, can also be the levers through others get into higher office.
In all walks of life, the Dunning-Kruger effects (or if you prefer, the Peter Principle) gets us all in the end.
"If Microsoft and Sun had compiled C# and Java native code instead of a virtual machine I believe there would be little demand for a language like Rust. "
I take your point, but feel obliged to point out that C# does have an ahead of time compiler, NGEN. And I believe it's been available since day 1. That said, I don't think you can claim that native code has quite the significance you think it has. Deferring the code generation with JIT has overheads, yes, but it's not intrinsically more or less memory-safe.
I have found lubuntu to be effective as a fairly good unbuntu remix. If that's your starting point and you don't want to deviate far from the true Upath. https://lubuntu.me/
As mentioned elsewhere the Raspberry Pi Desktop for PC's is pretty good. That's a strong debian flavour. https://www.raspberrypi.com/software/raspberry-pi-desktop/
I did try things like puppy linux a long time ago, but my opinion counts for much less there. I could see that puppy was more efficient, by doing less, but it was a learning curve that I wasn't personally prepared to get into.
Dear reader, your mileage may vary.
I have limited exposure to Scribus, but you don't want to edit content in it. Yes, you can, but it's eyeball-scratchingly messy. In old-fashioned office terms, you don't want to write a book in Publisher. For layout and pre-print, I'm sure Scribus is powerful, but it's not a content editor.
" not available in Europe"
Plea to editors and writers. Europe is a geographical entity. You are referring to the EU here. This is an important distinction because the UK is in one, and not the other. As, indeed is Switzerland, or Ukraine.
Have the UK data regulation rules actually deviated wildly from the EU rules, so far? GDPR is still in effect, for instance. Admittedly, they may willfully diverge in future. Or is it the rigour of enforcement that is different, or perhaps an expectation that if the UK all out on Brexit dividends the future privacy regimen will be more favourable to Meta/threads. /today/ what's the biggest different in data privacy/security between UK and EU?
Yes. but public sector projects are not exactly unique in that regard. I've seen private sector projects flail around because systems integrators waltz in, *assume* that their favourite shrink-wrapped software will do 90% or more just out of the box. The wish is father to the thought. When they find out three months into a six week project that maybe some people made stupid assumptions, all is lost.
" some of which was provided for free under the expectation people would not make money off their work directly or indirectly"
This is true in the sense that the "number of people who contributed to linux and the userland expecting that no one would make money from it" is surely non-zero. It would be foolish to deny this. But is that number really significant? The Red Hat model of selling support in some form has been around about 30 years now and the GPL and friends has been endlessly debated for what feels like eternity. Stallman is critical of RH for violating the spirit of the GPL, but he's not unaware of Red Hat.
I think in practical terms pretty much anyone who contributed to Linux kernel has known that Red Hat and other would profit from support services, but went ahead and contributed anyway. It's not as if Red Hat have hidden their business model. I have sympathy with the feeling that this all violates the spirit of the GPL I think most people, even the most blinkered software obsessives, would be aware that "spirit" of a licence agreement isn't exactly assured to stand up in court.
It does feel rather spiteful, though, even if I don't think you could convince a court that it was a contractual breach.
I suppose, on reflection, the market segment for "more than a microcontroller and less than a PI 3 B" is covered by the Pi Zero and Zero W models. Are there any realistic competitors for the price point? Orange Pi Zero is the best I could find, and it's not by any means a slam-dunk choice. (CPU a bit faster, includes ethernet when Pi Zero doesn't, no video)
Anecdotally, I see plenty of ads for /better/ Raspberry PI class SBCs - maybe with more memory or zappier processors or whatever - at higher prices. Usually promoted as "Pi killers". I'm sure there's a market for such things. They are always 20-50 more expensive that RPI list prices, and that's fair enough. However, I /never/ see ads for /cheaper/ PI equivalents, by which I mean low cost SBCs capable of running some sort of lightweight *nix distribution, something like the 2012 vintage PIs. These days, of course, microcontrollers based on ARM or RISCV can be found on boards with wifi or bluetooth or USB but there still seems to be a gap. Is there a via market segment for "more than a microcontroller but less that a PI 3 B", and where is it?" (Maybe just not profitable enough)
Agreed. The cost of lock-in is, let's be clear, a genuine risk whether it's with AWS, Azure, GCP or LinuxONE. So what makes IBM's offering particularly worrying from a lock-in perspective? Using a commodity operating system such as linux would be a mitigation. Would an organisation that is already committed to z/Architecture somehow get more locked in if they rented it in-cloud?
As I recall, the natisemi CPUs were bugging and didn't match quoted performance (https://en.wikipedia.org/wiki/NS32000) and by the time they sorted that out, anyone who wanted a vax-ish CISC architecture had already settled for the 68K line. I had a work colleague who bought a BBC micro co-processor with the 16032 and remembering it running Ackermann's function awfully quickly, but there wasn't enough momentum, no "killer app" or sexy hardware platform.
The odd thing is that this stuff IS on the BBC news site.
The "racist pub owner" thing: https://www.bbc.co.uk/news/uk-england-essex-65260945 and https://www.bbc.co.uk/news/uk-england-essex-65248924
The "every white bloke deserves a black slave" thing: https://www.bbc.co.uk/news/uk-wales-65246336
That was a just a few minutes of searching, but of course I did know what I was looking for. A better discourse would be to look at the publication times and relative prominence of these stories compared to other media & there's a whole PhD thesis waiting to be written there. Countless times I've seen people complain that story X doesn't appear on the BBC news home page or that the Beeb is silent on some issue or another, only to find the said stories on, say, the UK home page. The BBC's reputation for bias-free journalism has taken a knock in recent years. It feels timid when put against the establishment. But it's not Fox or GB news, thank $DEITY, so far.
Oh yes, we all called it pling. In BBC basic of course, the address was a byte address by the unit of transfer was a 4-byte integer, right?
As for tracking down the sideways ROM release I doubt very much that it was a commercial. Acornsoft did publish the basic compiler and full runtime, and two additional modules for floating point math(s) and for generating standalone and rommable code.
The brains behind the product was John Richards who founded Richards Computer Produce in Blewbury, Oxfordshire, near Didcot. Chris Jobson was the first employee and they ported the compiler and runtime first to Z80 CP/M systems and then to 6502 and the Beeb. The Beeb version was a modest success: ROM had the CINTCODE runtime (the VM) an a standard runtime library to encapsulate BBC MOS calls, and RAM-based file system, and a simple version of we would now call dynamic linking. The single disk contained the multi-pass compiler, assembler, a screen editor and a debugger, which was quite an amazing setup for 1984. You could even use the compiler with a cassette tape filing system if you were a masochist with time on your hands, but it was more sane to have two 80-track drivers or whatever since there wasn't much room to spare for source code on an single sided 100K disk.
I applied for a job there in 85, but declined John's offer at the time. After I notified him about a bug in the assembler he wrote back graciously sending a bug fixed version and a new job offer. I worked for several years on Reuters based products. John was a very savvy businessman as well as being techie, a combination I now know to be rare.
The sideways RAM and ROM thing was developed for a rack mount version of the Beeb that Acorn built for Reuters around the time of the stock market "Big Bang". RCP (Chris Jobson as I recall) wrote a modified runtime with "ISE" or in-situ execution. Word addresses < 32K mapped onto the native 6502 memory map. Addresses with the top bit set, in certain cases like global vector calls, were mapped to special case code.
GLOBAL $( Foo:42 $)
LET someproc () BE $(
foo(99)
$)
Would grab Foo from the global vector and map it to an entry point in a sideways ROM. Like overlays but without having to manually load the code into RAM. There was a "build ROM" tool and we spent many happy hours rearranging each hunk of CINTCODE to fit into 5 ROM images.
Bottom line- fantastically neat implementation, but internal only. If the dot-matrix printout of the user guides for the Reuters stuff survive after nearly 40 years I'd be amazed. You could seek out RCP or its successor companies. They were in Didcot about 15 years ago, have not been in touch since then. I doubt anyone there will remember me not least because I changed my surname on marriage. I hope that helps.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
