grumpyprole

GEM was in ROM on the Atari ST and it was fantastic. It was light years ahead of where Windows was at the time. It was Amiga Workbench that was somewhat limited by being on a floppy disk.

Absolutely, when I first tried Windows Cubase in the 90s, it wasn't long before it ate all my data. Even today's DAWs still haven't caught up with the original ST Cubase in terms of stability.

Well said. I guess such ignorance is not that surprising given that most "programming" today is glueing code together with scripting languages. This is really just a form of configuration. It certainly requires domain knowledge and a tolerance for digital bureaucracy, but not always maths. I do wish schools would do a better job of teaching that the entire fabric of western civilization rests upon mathematics.

The way software is built hasn't changed in decades.

And taking away women's rights.

> To me that's a large part of the very definition of a useful general purpose OS is that it's flexible and enables you to do whatever you need to do today,

NixOS gains most of its power from restrictions. These restrictions enable awesome things like starting a shell with all dependencies in seconds versus minutes using alternative technologies (used by great effect by replit). Nix works surprisingly well for most software, but anything with a ton of dynamic dependencies is going to cause issues. Even knowing what the dependencies might be statically can be hard. Sure, providing an OS with no restrictions and complete flexibility is an option, but then you'll just end up no better off.

Whatever the future of operating systems will be, it certainly will involve more restrictions and less flexibility.

This is fantastic, but of course strictly speaking the use of back references means these aren't true regular language expressions but the "enhanced" kind that give security headaches for all the big tech firms.

> naive inexperient developers blaming the tools

That's not the problem. It's naive inexperienced developers using the tools. Most developers have to maintain code they didn't write themselves. One can learn all the C++ best practices in the world, but it won't protect you from other people. That's why languages with strong restrictions and constraints that force safety and correctness are needed. With such languages, naive inexperienced developers won't be able get anything to compile. We won't have to deal with their mistakes as they'll never be able to ship them. Any experienced developer would surely want this.

A rewrite is not pointless if you are rewriting into a language with additional guarantees. You are checking for and proving the absence of certain classes of software flaws by doing so.

Oops I mean't back references, since that is the problem feature (that requires backtracking).

Are you sure it was Thompson who added backtracking to grep? Note also that the POSIX standard intentionally omits backtracking regex. It is a shame that others have not deprecated them.

This "strong typing" message from the Python community has always sounded like propaganda to me - designed to confuse management. Strong typing is about machine checked proofs of invariants, not whether you avoid a few daft built-in coercions.

Small languages, if they are suitably constrained, offer far more reasoning power and optimisation potential. This is why we need more small languages, not less. Python aims for maximum flexibility and maximum ease of use. This comes with real and serious trade offs. Python programs are very very difficult to reason about, for both people and machines.

A textbook example for you are (proper) regular expressions. This little language guarantees O(n) matching. The Python and Perl communities added backtracking without truly understanding why backtracking was missing in the first place. Now their misnamed "regular expressions" cause security issues for their users.

That Python makes the wrong trade-offs for mission critical software. This goes beyond just lacking static types.

Even with those retrofits, it's still a language designed for maximum flexibility and maximum ease of use. This has trade offs with regard to reasoning for correctness.

> My students are launching a satellite into low earth orbit that has its primary flight computer running python. Yes, sometimes this does waste a few hundred milliseconds

Never mind performance, would it not be good to at least machine check some static properties? A dynamic language is not a good choice for anything mission critical IMHO.

> We do see people try to take it too far though

I see it as a useful guide like any methodology should be. But I have worked with someone who insisted the rules should be followed to the letter, literally not a single sentence of explanation in any tutorial. So yes, that is the danger of these systems.

> these are Google engineers managing a million interacting state machines via a giant pile of global (mutable) state

Yeah that doesn't sound good. I understand the point you are making now and agree.

Objects and "method calls" generally implies mutable state to me, but yes the parent was not explicit about this. I assumed mutable (implicit) state was being argued in favour of an explicit state representation. Perhaps I misunderstood.

For a state machine, I would expect a function such as:

transition : (old_state, event) -> new_state

Or if we use immutable objects, and one method per simple event, then something like:

transition_event1 : () -> new_state

Which I think is similar to what you hace. So I think we are in agreement here.

I was talking in the most general sense. I am sure there are state machine implementations that are terrible to reason about, especially any that emerge from a codegen tool. But hopefully they are the exception and not the rule.

A state machine makes the actual program state first class and easy to reason about. One does not even need mutable state to model one. Whereas you appear to be advocating mutable objects. The state space then becomes a combinatorial explosion of all the hidden mutable state "encapsulated" inside the objects. Object oriented programming is not the only way and often leads to a poor domain model. Some OOP evangelists even model a bank account with a mutable balance field and methods for making deposits. This is a absolutely not a faithful model of the domain (ledgers have been used for hundreds/thousands of years). In summary, yes a state machine can absolutely be a good domain model.

> So scanning processes is the correct thing to do.

Most solutions in engineering involve a trade-off. Clearly this solution trades simplicity for complexity and multiple CVEs. An OS could utilise a known static configuration as described by its packaging system, for a much simpler solution. It could disallow running services any other way.

It still sounds like duct tape to me. An OS should know the dependencies of each service without having to perform complex dynamic scanning to find out. Is this information not already in dpkg?

Reading the CVEs makes this piece of software sound like a Rube Goldberg machine.

You can write imperative programs in Haskell and many people do. You get effect tracking, giving perhaps the "the worlds best imperative language" :)

> For any practical program, memory usage and number of operations are part of the engineering specification

And yet if I read a C++ program, I have no idea with just a local inspection where, if any, the allocations are happening. Reasoning about operational behaviour is not exactly a solved problem in other languages either.

> TLDR: to understand what a Haskell 5-liner does, you sometimes have to read a paper.

You have to understand the syntax and the semantics and genuinely know what you are doing. This is no different to any other programming language. It would require a whole paper to explain JavaScripts equality operator! However, Haskell does has one distinct advantage, the abstractions often come from maths and are very widely applicable. These abstractions will still be around in 10 years time.

And he got it completely wrong, as more and more Haskell features end up in industrial programming languages. Oracle's Java architect even publically stated he was influenced by Haskell.

This is a poor and lazy criticism of Haskell. It might be hard to reason about the memory usage and other operational behaviours of a Haskell program, but the ability to reason about semantics and correctness is far ahead of the mainstream. It actually supports equational reasoning. It has statically checked effect tracking, checked encapsulation of mutable state and much more. There is no all powerful pervasive "ambient monad" that lets code do absolutely anything.

Standard mathematical notation?

So Swift does implicit conversions?

Yes, in fact even a Harrier Jump Jet was designed with pencils and a slide rule!