Interesting findings on the internet

[bd139]

I have no beef with Swindon. It's just a nothing. Like Peterborough.

[Zenith]

I've never been to Slough, but it has a reputation. I think it was a designated new town developed just after WWII, so in the 50s and 60s it had a reputation for being prosperous, but soulless.

https://www.best-poems.net/john_betjeman/slough.html

That poem got Betjemen into a lot of trouble with some.

[bd139]

I spent many a day in Slough. The reputation is both earned and accurate.

It was a day out when Uxbridge became too much. And incidentally where one of our data centres was until recently.

[bd139]

A very interesting read on the notion of 0 and 1 based array indexes

https://exple.tive.org/blarg/2013/10/22 ... on-needed/

[tggzzz]

A very interesting read on the notion of 0 and 1 based array indexes

https://exple.tive.org/blarg/2013/10/22 ... on-needed/

He seems a little perverse about the 0/1 thing. The simple point is that an N-bit number can express 0..2^N-1, not 1..2^N. Even as a kid, it rankled with me that the first ten numbers are 1,2,3,4,5,6,7,8,9,10. It also rankled with me that The best composer is Beethoven, and The Russian composer is Tchaikovsky. Never liked either; always preferred Bach and Scarlatti.

The one about square brackets rings true. Back Then there were many many different keyboard layouts; the letters and numbers were more or less fixed, but the rest appeared all over the place - and you had a few odd keys/characters like "figure shift" and "letter shift". Until recently it was easy to type square brackets; now it is a pain in the arse to type, say, "[/quote]" on a fondleslab; we now have three shift keyboards to deal with

Gabriel's The Rise of Worse id Better is spot on, of course I liked C in the early 80s, but by the early 90s I merely tolerated it; I knew there were better alternatives (no, not C++ of course!)

[bd139]

A very interesting read on the notion of 0 and 1 based array indexes

https://exple.tive.org/blarg/2013/10/22 ... on-needed/

He seems a little perverse about the 0/1 thing. The simple point is that an N-bit number can express 0..2^N-1, not 1..2^N. Even as a kid, it rankled with me that the first ten numbers are 1,2,3,4,5,6,7,8,9,10. It also rankled with me that The best composer is Beethoven, and The Russian composer is Tchaikovsky. Never liked either; always preferred Bach and Scarlatti.

The one about square brackets rings true. Back Then there were many many different keyboard layouts; the letters and numbers were more or less fixed, but the rest appeared all over the place - and you had a few odd keys/characters like "figure shift" and "letter shift". Until recently it was easy to type square brackets; now it is a pain in the arse to type, say, bd139:FUCK PHPBB PARSER! on a fondleslab; we now have three shift keyboards to deal with

Gabriel's The Rise of Worse id Better is spot on, of course I liked C in the early 80s, but by the early 90s I merely tolerated it; I knew there were better alternatives (no, not C++ of course!)

I'm honestly on the fence with the 0/1 at the moment. There are times each makes sense. Everyone gets pissy if you use the wrong one. There is a nice demonstration of integers being representable as the difference of natural numbers (m,n) which is handy when you have identities -n_=(0,n), m_=(m,0) and 0=(0,0) but this is a pain in the but if you have m_=(m+1,1) and n_=(1,n+1). That is the only viable complaint I've seen. Everything else seems arbitrary. Arrays are easier. Cardinality is no worse

I rather like C if you treat it for what it is: a higher level assembler. If I don't want to solve problems then I would rather use something else. Go is rather nice there. It's basically Algol 68 with a modern syntax and standard library.

[tggzzz]

Sorry about the /quote

Algal 60 was my first language.. At uni I looked at Algol68 and what was necessary with cardpunch character sets. Took me all of 30 mins to work out that the chance of me getting all the single quotes right was too small to be worth considering.co

C could have chosen to remain a high level assembler, but decided to be a general applications language (and failed), but doing that caused it to cease to be close enough to the silicon.

I like CSP, particularly in its modern incarnation, xC running on highly parallel processors. I suspect I would like Go, but I have less interest in the domains for which it is applicable.

[bd139]

No need to apologise for the shortcomings of a badly designed markup language and bit of software

I dislike Go less. That's all I'm saying.

Currently playing with Julia. It has some interesting capabilities and is compiled using LLVM on the fly to something actually fast...

Screenshot 2024-04-12 at 22.24.07.png

[Zenith]

I started with FORTRAN on cards at school and then university. I eventually found myself earning a living as a COBOL programmer when Hollerith cards were mercifully a distant memory. I know it's non U but liked COBOL. I learned SPL which was an architecture specific version of ALGOL 60. I had a flirtation with FORTH, which I've always found fascinating, as well as 8086 assembler. I had a job supporting a couple of COBOL compilers (66 and 74) plus a few other languages. Then I had a job writing Pascal for a couple of years, until politics overtook it. Then it was C for a couple of years*. An intuitive and proper language C. Never liked C++ or Java. The last language I was paid to write was PERL, also an intuitive and proper language. I've played a bit with Python and also PIC assembler along the way.

*At the end of it it cost me a girlfriend who was a COBOL programmer, who worked for an insurance company. She had a problem with a batch program that ran impossibly slowly and no one could see why. They were sending off tapes to the computer manufacturer. I explained it was to do with relying on the compiler's treatment of run time loading, which was necessarily inefficient, and jotted out some code she might try. She had a 2.1 in computer science. She tried it and it worked. She was delighted and said it had saved her from the sack. I said that in my COBOL support days it was the sort of problem I'd solve two or three times a week, without any need for tapes being sent. She said I was seriously weird. The next I knew she'd abandoned me for another.

[tggzzz]

No need to apologise for the shortcomings of a badly designed markup language and bit of software

I dislike Go less. That's all I'm saying.

Currently playing with Julia. It has some interesting capabilities and is compiled using LLVM on the fly to something actually fast...

Screenshot 2024-04-12 at 22.24.07.png

I was apologising for not thinking

I'm aware of Julia, and at first glance it seems like something I would investigate further - but only if there was a reason I might want to use it. From the little I've seen, my two questions would be whether it offers sufficient over other languages, and what's the quality of the libraries and tool support.

Whatever else you might think of Java, the range of libraries that rapidly appeared and simply worked with each other was stunning. In one year it was orders of magnitude better C++ had managed in a decade. The tool support rapidly appeared, and the "cntl-space" "what can I do here" anticipation is something that C++ can never match.

[tggzzz]

Ah COBOL.

There was a book in the school library about Fortran, Algol, (probably BASIC), and COBOL. I read it.

The one thing I remember about COBOL was that near the end it introduced an "advanced" way of doing atithmetic: "a=b*c" . Back then I didn't understand how.many applications were simply Create Read Update Delete, so it sounded grossly simplistic and tedious. It was about that time I also decided to never to have anything to do with database. I almost succeeded[1]

[1] did have to learn SQL to interrogate a database containing data suggesting why cellphone calls failed. The other contribution was removing a database and replacing it with in-memory key-value pairs.

[tggzzz]

I wish I had known of this paste a few years ago. I suspect BD might still find a use for it...

Sullivan Supply Attitude Adjustment Paste
https://www.amazon.com/Sullivan-Supply- ... B08X97BXWV

Might still be worth buying one, to display alongside "BUM scouring powder" and "Fat-free Sour Cream". When on the west coast of LeftPondia, I should also have nicked breakfast menus proclaiming "egg-free omelettes".

[Specmaster]

I spent many a day in Slough. The reputation is both earned and accurate.

It was a day out when Uxbridge became too much. And incidentally where one of our data centres was until recently.

Slough is the pits, I used to spend loads of time with customers there and I just couldn't get away quick enough, I loathed it.

It also used to have a sickly smell hanging around from the huge great Mars factory there.

https://www.youtube.com/watch?v=WSpfywz8IPc

[Cerebus]

It also used to have a sickly smell hanging around from the huge great Mars factory there.

Slough smells of dust, stale piss, and Maltesers.

On days when someone has to desperately dump fuel to land at Heathrow with a problem it also smells of Jet A or Jet A-1.

[bd139]

No need to apologise for the shortcomings of a badly designed markup language and bit of software

I dislike Go less. That's all I'm saying.

Currently playing with Julia. It has some interesting capabilities and is compiled using LLVM on the fly to something actually fast...

Screenshot 2024-04-12 at 22.24.07.png

I was apologising for not thinking

I'm aware of Julia, and at first glance it seems like something I would investigate further - but only if there was a reason I might want to use it. From the little I've seen, my two questions would be whether it offers sufficient over other languages, and what's the quality of the libraries and tool support.

So far so good. My application for it is actually numerical computing and modelling (Ferengi stock market shenanigans) so that pretty much hits the nail on the head. It also has decent stats package with data frames and reporting functionality. I was using R for this but it's showing its age and crankiness for the task.

As for a general purpose language Go is probably better. It does that wonderful thing of farting out a single static binary with no dependencies that can just be deployed with a "cp".

Whatever else you might think of Java, the range of libraries that rapidly appeared and simply worked with each other was stunning. In one year it was orders of magnitude better C++ had managed in a decade. The tool support rapidly appeared, and the "cntl-space" "what can I do here" anticipation is something that C++ can never match.

I've written a fair bit of Java over time. This migrated to c# which is roughly equivalent but without some of the horrible design mistakes Java made along the way (missing then terrible generics). I'd be lying if I didn't agree with you though. It paid the mortgage off. But it was very easy to build unwieldy abstractions on top of through over-engineering and that's exactly what happened. Using the core of either Java or .Net is a radical approach these days and shunned by the framework architect religious types.

Again saying good things about Go, it had people who knew how to build a decent and powerful standard library on the project. It's rare I need to pull in a 3rd party dependency.

So conclusions for 2024 so far...

Julia -> scientific computing / stats / modelling
Go -> everything else

[bd139]

I wish I had known of this paste a few years ago. I suspect BD might still find a use for it...

Sullivan Supply Attitude Adjustment Paste
https://www.amazon.com/Sullivan-Supply- ... B08X97BXWV

Might still be worth buying one, to display alongside "BUM scouring powder" and "Fat-free Sour Cream". When on the west coast of LeftPondia, I should also have nicked breakfast menus proclaiming "egg-free omelettes".

Dr Ivan Mcraisey's Original Turd Polish as well.

[bd139]

The last language I was paid to write was PERL, also an intuitive and proper language.

I would argue Perl is neither intuitive or proper. It's one of those things that sort of, well, happened. I inherited a lot of it (Horrible parsing and mucky Perl CGI) back in the early 00's and ended up porting it to C# rather than trying to fix it. That product is still in production today apparently (Association of mathematics teachers membership system).

You can tell it's not proper because they tried to make it a proper language recently and no one used it because if you want a proper language there are plenty of others to choose from

[tggzzz]

As for a general purpose language Go is probably better. It does that wonderful thing of farting out a single static binary with no dependencies that can just be deployed with a "cp".

Oh, how... passé. And pleasing.

Whatever else you might think of Java, the range of libraries that rapidly appeared and simply worked with each other was stunning. In one year it was orders of magnitude better C++ had managed in a decade. The tool support rapidly appeared, and the "cntl-space" "what can I do here" anticipation is something that C++ can never match.

I've written a fair bit of Java over time. This migrated to c# which is roughly equivalent but without some of the horrible design mistakes Java made along the way (missing then terrible generics).

Java generics are suitable for avoiding downcasting when using containers, and not much more. I have successfully used them for more, but it was a trial-and-error pain only possible because I wasn't under time pressure.

Chash never interested me. Hejlsberg came and gave us a talk just before it escaped. Nobody in the audience was impressed, since it didn't offer anything radical over Java. Basically it was (and is) a traditional me-too Microsoft attempt to lock people into Windows.

The only distinctive thing was its ahead of time assembly optimisation. Sounds good on paper, but causes immensely slow installation/update time delays, and is limited to static optimisations. It can only optimise what it guesses will be runtime behaviour, whereas HotSpot can optimise the actual runtime behaviour. (See HP's Dynamo for surprising results which surprise the young/ignorant!)

I'd be lying if I didn't agree with you though. It paid the mortgage off. But it was very easy to build unwieldy abstractions on top of through over-engineering and that's exactly what happened. Using the core of either Java or .Net is a radical approach these days and shunned by the framework architect religious types.

Yeah. Sod 'em

Again saying good things about Go, it had people who knew how to build a decent and powerful standard library on the project. It's rare I need to pull in a 3rd party dependency.

By the time Go was being designed, they had plenty of examples to "copy", dating back to to the late 70s early 80s That they did copy (cf reinventing an elliptical wheel!) is a principal reason I've kept an eye on Go.

So conclusions for 2024 so far...
Julia -> scientific computing / stats / modelling
Go -> everything else

For 2023 mine are:
xC for hard realtime embedded
For specialised application domains, choose (and learn) whatever's easiest. (Think stats, modelling, CAD...)
Java for everything else
C if there's no practical alternative

[Zenith]

The last language I was paid to write was PERL, also an intuitive and proper language.

I would argue Perl is neither intuitive or proper. It's one of those things that sort of, well, happened. I inherited a lot of it (Horrible parsing and mucky Perl CGI) back in the early 00's and ended up porting it to C# rather than trying to fix it. That product is still in production today apparently (Association of mathematics teachers membership system).

You can tell it's not proper because they tried to make it a proper language recently and no one used it because if you want a proper language there are plenty of others to choose from

It's a glorious concoction of C, shell script, both of which I knew quite well, (and so I found it intuitive) and a few things of its own. I found it did what I wanted very well. It had the huge CPAN libraries.

It fell from prominence because Larry Wall became distracted and it became riven by politics.

Define a "proper" language. I recall that at one time, Pascal was the ultimately proper language, although it's been pretty much dead for some years. People raved over it. Wirth developed it as a teaching medium and was shocked that compilers had been written to implement it. He set to work to create Modula 2, with much stronger typing. That never caught on.

[bd139]

The last language I was paid to write was PERL, also an intuitive and proper language.

I would argue Perl is neither intuitive or proper. It's one of those things that sort of, well, happened. I inherited a lot of it (Horrible parsing and mucky Perl CGI) back in the early 00's and ended up porting it to C# rather than trying to fix it. That product is still in production today apparently (Association of mathematics teachers membership system).

You can tell it's not proper because they tried to make it a proper language recently and no one used it because if you want a proper language there are plenty of others to choose from

It's a glorious concoction of C, shell script, both of which I knew quite well, (and so I found it intuitive) and a few things of its own. I found it did what I wanted very well. It had the huge CPAN libraries.

It fell from prominence because Larry Wall became distracted and it became riven by politics.

Define a "proper" language. I recall that at one time, Pascal was the ultimately proper language, although it's been pretty much dead for some years. People raved over it. Wirth developed it as a teaching medium and was shocked that compilers had been written to implement it. He set to work to create Modula 2, with much stronger typing. That never caught on.

It fell from prominence because it had numerous problems including performance, scalability and the notion of being a write once language. Also the propensity for people to try and solve everything with layers of regular expressions and naive parsing.

Proper language: strong type system, compiled, fast, managed memory, strong standard library, native concurrency primitives, fast round trip time, not crazy runtime environment. I think Perl ticks perhaps 2 of those.

Pascal was ok for the time.

[bd139]

As for a general purpose language Go is probably better. It does that wonderful thing of farting out a single static binary with no dependencies that can just be deployed with a "cp".

Oh, how... passé. And pleasing.

It is actually. Very nice when you have a thing on your plate of "evaluate this complicated distributed system" and it turns out this is done by downloading a single binary, running it and that's it. Our entire logging (loki/promtail) and metrics system (prometheus/alertmanager) and visualisation (grafana) is sitting on top of it. You can literally bring the whole thing up on your laptop in about 5 minutes. We started building utility applications in it and they start up fast, run fast and bugger off quickly.

Not to mention Kubernetes is written in it as well which is testament to how much crap you can shovel into one language if there ever was one.

Java generics are suitable for avoiding downcasting when using containers, and not much more. I have successfully used them for more, but it was a trial-and-error pain only possible because I wasn't under time pressure.

Chash never interested me. Hejlsberg came and gave us a talk just before it escaped. Nobody in the audience was impressed, since it didn't offer anything radical over Java. Basically it was (and is) a traditional me-too Microsoft attempt to lock people into Windows.

The only distinctive thing was its ahead of time assembly optimisation. Sounds good on paper, but causes immensely slow installation/update time delays, and is limited to static optimisations. It can only optimise what it guesses will be runtime behaviour, whereas HotSpot can optimise the actual runtime behaviour. (See HP's Dynamo for surprising results which surprise the young/ignorant!)

The problem with Java is that the generic implementation is unboxing and boxing which is time consuming. C# actually natively compiles this, again using JIT. There isn't really AOT optimisation although promised in C#. It never materialised. It's like cold fusion.

JIT compilers have some downsides which I am no longer a fan of. I much prefer entirely ahead-of-time compilation even if the solution is less optimal because the principal problems these days are warm up time and latency. It's a bit difficult swapping out a couple of hundred megs of code when there are 6000 requests/second landing on it without annoying someone. The warm up code which makes sure the hot paths aren't going to kill users is pretty hefty and requires a lot of maintenance. cost-benefit shot.

By the time Go was being designed, they had plenty of examples to "copy", dating back to to the late 70s early 80s That they did copy (cf reinventing an elliptical wheel!) is a principal reason I've kept an eye on Go.

Learning from other people's mistakes is good.

For 2023 mine are:
xC for hard realtime embedded
For specialised application domains, choose (and learn) whatever's easiest. (Think stats, modelling, CAD...)
Java for everything else
C if there's no practical alternative

A reasonable choice too

[tggzzz]

The problem with Java is that the generic implementation is unboxing and boxing which is time consuming. C# actually natively compiles this, again using JIT. There isn't really AOT optimisation although promised in C#. It never materialised. It's like cold fusion.

I thought boxing/unboxing was only relevant for int/Integer and other primitive types, and was irrelevant for non-primitive classes. I can't recall putting naked primitives into a collection class.

JIT compilers have some downsides which I am no longer a fan of. I much prefer entirely ahead-of-time compilation even if the solution is less optimal because the principal problems these days are warm up time and latency. It's a bit difficult swapping out a couple of hundred megs of code when there are 6000 requests/second landing on it without annoying someone. The warm up code which makes sure the hot paths aren't going to kill users is pretty hefty and requires a lot of maintenance. cost-benefit shot.

Warm up time is a "which day of the week is it thing" for me. On Mondays I like the fast load and start, and don't mind the slight performance penalties at the beginning of running. On patch Tuesday I hate having a machine crippled while it installs updates (or would if I had such machines connected to the net). On Wednesdays I hate having to have "warm up" periods when doing benchmarking. On Thursdays I hate have to explain to another youngster about why the university lessons about performance don't apply to Java on modern SMP machines.

The maintenance for HotSpot internals are an externality, and of no more interest to me than compiler internals

By the time Go was being designed, they had plenty of examples to "copy", dating back to to the late 70s early 80s That they did copy (cf reinventing an elliptical wheel!) is a principal reason I've kept an eye on Go.

Learning from other people's mistakes is good.

Oh yes indeed. When Java was first announced, Gosling's whitepaper was a beautiful contrast to the stuff emitted by the C++ community. That convinced me Java was a good way to go

C++ discussions were always about C++; it had the stink of "we've had this neat idea and figuring out how to use it isn't out problem".

By contrast, Gosling took a bit from this community (because x), a bit from that community (because Y), ignored a bit from another community (because Z), and demonstrated why the chosen concepts worked well together as a whole.

Oh, another case for using C: it is small and it doesn't matter if it fails. Example: using an arduino to turn my 1973 digital clock into a Vetinari clock

[bd139]

The problem with Java is that the generic implementation is unboxing and boxing which is time consuming. C# actually natively compiles this, again using JIT. There isn't really AOT optimisation although promised in C#. It never materialised. It's like cold fusion.

I thought boxing/unboxing was only relevant for int/Integer and other primitive types, and was irrelevant for non-primitive classes. I can't recall putting naked primitives into a collection class.

It's more that if you have an ArrayList<Integer> then add(1) will autobox it from a primitive to a reference type which is costly at bytecode/JIT level whereas in C# this is natively supported thus is not costly.

JIT compilers have some downsides which I am no longer a fan of. I much prefer entirely ahead-of-time compilation even if the solution is less optimal because the principal problems these days are warm up time and latency. It's a bit difficult swapping out a couple of hundred megs of code when there are 6000 requests/second landing on it without annoying someone. The warm up code which makes sure the hot paths aren't going to kill users is pretty hefty and requires a lot of maintenance. cost-benefit shot.

Warm up time is a "which day of the week is it thing" for me. On Mondays I like the fast load and start, and don't mind the slight performance penalties at the beginning of running. On patch Tuesday I hate having a machine crippled while it installs updates (or would if I had such machines connected to the net). On Wednesdays I hate having to have "warm up" periods when doing benchmarking. On Thursdays I hate have to explain to another youngster about why the university lessons about performance don't apply to Java on modern SMP machines.

The maintenance for HotSpot internals are an externality, and of no more interest to me than compiler internals

That's fine but it's a leaky performance abstraction. I like my food served hot and ready. I don't want my egg to start cooking the moment I poke it with a fork.

Oh yes indeed. When Java was first announced, Gosling's whitepaper was a beautiful contrast to the stuff emitted by the C++ community. That convinced me Java was a good way to go

C++ discussions were always about C++; it had the stink of "we've had this neat idea and figuring out how to use it isn't out problem".

By contrast, Gosling took a bit from this community (because x), a bit from that community (because Y), ignored a bit from another community (because Z), and demonstrated why the chosen concepts worked well together as a whole.

Indeed. C++ is a bad solution for everything. You can tell this when there are more guides about which bits not to use than bits to use.

Oh, another case for using C: it is small and it doesn't matter if it fails. Example: using an arduino to turn my 1973 digital clock into a Vetinari clock

A perfect use case. Of course make sure that you didn't accidentally include any Arduino C++ crap in it. I wrote my own semi-functional RTOS and libraries and used AVR-libc rather than touch that steaming pile.

[tggzzz]

The problem with Java is that the generic implementation is unboxing and boxing which is time consuming. C# actually natively compiles this, again using JIT. There isn't really AOT optimisation although promised in C#. It never materialised. It's like cold fusion.

I thought boxing/unboxing was only relevant for int/Integer and other primitive types, and was irrelevant for non-primitive classes. I can't recall putting naked primitives into a collection class.

It's more that if you have an ArrayList<Integer> then add(1) will autobox it from a primitive to a reference type which is costly at bytecode/JIT level whereas in C# this is natively supported thus is not costly.

When I have done something close to that, the integer will have been fetched from a distributed key-value "database". I know what not to bother optimising

JIT compilers have some downsides which I am no longer a fan of. I much prefer entirely ahead-of-time compilation even if the solution is less optimal because the principal problems these days are warm up time and latency. It's a bit difficult swapping out a couple of hundred megs of code when there are 6000 requests/second landing on it without annoying someone. The warm up code which makes sure the hot paths aren't going to kill users is pretty hefty and requires a lot of maintenance. cost-benefit shot.

Warm up time is a "which day of the week is it thing" for me. On Mondays I like the fast load and start, and don't mind the slight performance penalties at the beginning of running. On patch Tuesday I hate having a machine crippled while it installs updates (or would if I had such machines connected to the net). On Wednesdays I hate having to have "warm up" periods when doing benchmarking. On Thursdays I hate have to explain to another youngster about why the university lessons about performance don't apply to Java on modern SMP machines.

The maintenance for HotSpot internals are an externality, and of no more interest to me than compiler internals

That's fine but it's a leaky performance abstraction. I like my food served hot and ready. I don't want my egg to start cooking the moment I poke it with a fork.

Yeah, but you end up getting something the chef decided you wanted when he created the buffet. I prefer something put together when I want it.

Aren't analogies fun, and full of hot air from one of the new-fangled hot air fryers.

Oh yes indeed. When Java was first announced, Gosling's whitepaper was a beautiful contrast to the stuff emitted by the C++ community. That convinced me Java was a good way to go

C++ discussions were always about C++; it had the stink of "we've had this neat idea and figuring out how to use it isn't out problem".

By contrast, Gosling took a bit from this community (because x), a bit from that community (because Y), ignored a bit from another community (because Z), and demonstrated why the chosen concepts worked well together as a whole.

Indeed. C++ is a bad solution for everything. You can tell this when there are more guides about which bits not to use than bits to use.

But but but that a benefit: you can choose, the language didn't dictate to you

Oh, another case for using C: it is small and it doesn't matter if it fails. Example: using an arduino to turn my 1973 digital clock into a Vetinari clock

A perfect use case. Of course make sure that you didn't accidentally include any Arduino C++ crap in it. I wrote my own semi-functional RTOS and libraries and used AVR-libc rather than touch that steaming pile.

It fitted in an 8-pin ATtiny85 processor, and - even using the arduino digital read/write abstractions - ran fast enough.

You wrote an RTOS? Surely that's implemented in silicon Having said that, I did write a co-routine mechanism in 6800 assembler. It was half a dozen instructions

Nowadays I prefer event-driven designs using the half-sync-half-async design pattern. https://www.dre.vanderbilt.edu/~schmidt/PDF/PLoP-95.pdf and https://java-design-patterns.com/patter ... alf-async/ That works from bare silicon up to telecoms enterprise applications Only thing left for an RTOS to do is encapsulate the networking/USB comms libraries that I don't want to think about

[bd139]

When I have done something close to that, the integer will have been fetched from a distributed key-value "database". I know what not to bother optimising

It of course depends on what you are doing. We had some low latency stuff running through the reactor patter (only way to get a managed language to perform well enough) that this was offensive enough to cause issues. Totally eliminated by modern CPUs of course now.

Yeah, but you end up getting something the chef decided you wanted when he created the buffet. I prefer something put together when I want it.

Aren't analogies fun, and full of hot air from one of the new-fangled hot air fryers.

Actually the nature of what I want is all the food variations to be cooked up front ready to go.

It fitted in an 8-pin ATtiny85 processor, and - even using the arduino digital read/write abstractions - ran fast enough.

They are surprisingly fast. Anyone who's written anything 8-bit-ish in the dark ages (I started on 6502 assembly) knows how fast things can be even on slow old things!

You wrote an RTOS? Surely that's implemented in silicon Having said that, I did write a co-routine mechanism in 6800 assembler. It was half a dozen instructions

Ha. The implementation was extremely light. The entire code for it was 800 bytes approximately and other than intialisation code was actually a header file. It had two functions: doing more than one thing and responding to interrupts. Everything else was bolted on. And it used coroutines which could yield at any point arbitrarily. The real time guarantee came from if it didn't yield it was yielded anyway.

Nowadays I prefer event-driven designs using the half-sync-half-async design pattern. https://www.dre.vanderbilt.edu/~schmidt/PDF/PLoP-95.pdf and https://java-design-patterns.com/patter ... alf-async/ That works from bare silicon up to telecoms enterprise applications Only thing left for an RTOS to do is encapsulate the networking/USB comms libraries that I don't want to think about

That is roughly how my somewhat giant commissions processing constraint resolver works. If only I had the opportunity to use it on an interesting problem.