_sh
If you consider that an ecosystem evolves to the constraints of its environment, even from their pre-history at Xerox Parc, early GUI frameworks were incredibly constrained. But I think the most important constraint in their development was object orientation. Smalltalk blazed the trail for GUI programming, everyone else following after modeled their systems in that way. Object orientation became the most expressive way to program a hierarchical widget system (which most desktop systems are). Even early Windows HWND-style programming emulates virtual dispatch in non-object oriented C (also 'gobject').
In response, a vast body of knowledge and techniques around object orientation were amassed to mitigate these constraints as the ecosystem matured through the 80s and 90s. Not just patterns like MVC, Flyweight, Command et al, but also structural techniques like the event loop.
> Eventually, somewhere near the end of the 90s/middle of the 2000s, most of these things were "solved" for desktop/native, or put less charitably, they stopped changing.
So at the end of the 90s/middle of the 2000s the web browser grew out of being a document viewer into a very constrained widget kit, but the programming model was not object oriented and so the 'solved' problems needed to be solved again for a new set of constraints. Few of the traditional techniques applied, and the old object oriented way was either adapted (e.g. data binding became Redux, Flyweight/Prototype became templates) or disposed. Personally I find it a bit of a waste, but I don't expend any energy in the new ecosystem, so I don't want to be too judgy.
But I don't think desktop widget kits 'stopped changing', and are cherry-picking ideas from the browser, like 'declarative' (XAML, QML, etc) and 'responsive' (widget containers that re-flow the viewport for phone/tablet orientation etc). I hope I haven't misunderstood your question and wasted everyone's time.
In the section "Questioning the Foundations of Traditional Safety Engineering":
Old Assumption
Most accidents are caused by operator error. Rewarding safe behaviour and punishing unsafe behaviours will eliminate or reduce accidents significantly.
New Assumption
Operator error is a product of the environment in which it occurs. To reduce operator "error" we must change the environment in which the operator works.
Old Assumption
Major accidents occur from the chance simultaneous occurrence of random events.
New Assumption
Systems will tend to migrate toward states of higher risk. Such migration is predictable and can be prevented by appropriate system design or detected during operations using leading indicators of increasing risk.
[0] Open Access PDF: https://mitpress.mit.edu/books/engineering-safer-world
No reason at all, if they still solve the same problem, they're still the best solution. The problem with 'problems' though, is that once they're cornered they tend to change into a whole new problem. A nasty one the current solution won't work for, usually.
Another take: what is the ratio of the same software still in use after, say, 10 years to all software in use? I would argue that more than 99% of all software (e.g. by version number) is no longer in use after a mere 5 years. Software is inherently disposable, let's not pretend we're building bridges that will stand for generations.
My point is that developers (I'm one) have a hard time with the qualities of software: we don't understand the nature of software change, and bicker about what bumping a semver number means, and we fight its disposable nature by engineering it to the point where it could run for a decade (it won't).
> These values reflect a deeper sense within me: that software can be permanent
Maybe it can be permanent, but it shouldn't be. Software is disposable and all the time developers are mistakenly fighting this aspect of its nature instead of embracing it. Great software is malleable and develops, over time, to adapt to the human that is using it. But it is impermanent--parts are snipped off here, fleshed out there, nothing stays the same, it is obsolete as soon as it is released. Don't delude yourself that your software will run for a thousand years, be like Warhol and celebrate the ephemera that is pretty much every program ever written.
> I have believed (and continue to believe) that we are living in a Golden Age of software, one that will produce artifacts that will endure for generations
Museum pieces, sure, but do we still want to be using generations-old software in the years to come? Hope not. Times change, needs change, and software that doesn't change is replaced by software that does, and quick. What about such monumental artifacts as 'cc', 'awk', or even the UNIX kernel? For years they have dominated the landscape, they are the Ozymandias, the King of Kings. If we are still clinging to these titans in another 20, 50 years, is that a good thing?
Cortex-Ms typically can't run linux (excepting uClinux) as they don't have the RAM and typically don't need to as they address a different need (dedicated function instead of general-purpose compute), and have far fewer peripheral interfaces. It used to be all about power profile, but the recent SoCs are getting pretty competitive there as well.
But as I said the traditional segmentation at this end of the spectrum is being re-cast seemingly every second week, and so terms such as 'microcontroller' are becoming less meaningful all the time. And who the hell can agree on just what 'embedded' means these days?
While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (the linked transcript cites 'memory bugs' as the most common class of bugs). Embedded software practitioners long ago abandoned dynamic memory allocation and with it the 'use-after-free' and 'out-of-bounds access' bugs, instead re-defining the problem as one of latency (e.g. you'll need to process that static buffer before it gets re-used by your UART interrupt). Take away the borrow-checker, and Rust looks less compelling.
In time, Rust will find its niche in the embedded space, most likely occupying the high-level RPi/BBB/iMX SoC layer and perhaps working its way down to microcontrollers. As wiremine points out, it will require vendor support--moving away from your vendor's toolchain is a world of hurt that seasoned embedded developers just won't even consider. Pragmatism reigns: time-to-market and a cheap BoM are the main metrics, programming language a distant 10th.
The best description I've heard of it goes: "Given a choice between X and Y, a person says 'Oh, I love Y!' but then chooses X, X, X, and X".
The author's point is that the so-called great innovators of today--Apple and Google are cited--are really doing nothing to innovate the workspace, despite having plenty of opportunity to do so.
He was Danish, we called it the 'Scando Sweep'.
Hardly equation solving.
Doesn't support full numeric tower (no floats), but does implement 'unbound precision integers'. See §5.1 of this paper: http://www.iro.umontreal.ca/~feeley/papers/StAmourFeeleyIFL0...
I wish I had this back in the day when I first learnt C and was doing all this by hand with pencil and paper. The VCR-style rewind is a nice touch.
I also do a lot of embedded C, and can confirm that dynamic allocation is rare, so why not try restructuring your program to avoid it? It's good practice and will sharpen your skills by raising all sorts of questions like why dynamic allocation is discouraged in embedded systems in the first place, and what alternatives there are, and how to use a profiler to compare different trade-offs. Heaps of exploratory fun to be had!
And hey, Graph-Reply is really cool, and so are space robots.
http://www.6502.org/source/interpreters/sweet16.htm
"While writing Apple BASIC, I ran into the problem of manipulating the 16 bit pointer data and its arithmetic in an 8 bit machine..."
Both frameworks seem to offer similar advantages: decoupled model and view, UI state playback (VCR style) and instrumentation. How significantly do these frameworks differ? Or are we seeing different paths towards a convergence around a new set of model/view practices?
I too once thought that it would make a great movie. Thought the same about Ubik too. Now, my feeling is to just let these classics be.
if __name__ == "__main__":
For everyone else, there's javascript: open up your browser console and you have a full IDE with breakpoints and inspection, and an interactive REPL. Object orientation is there if you want it, but what 5-year-old does? Functional paradigms are there when you're ready for them (map and foreach on arrays, for example). A smooth learning curve that gives you power when you reach for it, and a fast, flexible GUI environment. Free source code to study comes with every web site.
Best of all, its flexibility fosters many differing programming styles: consider jQuery and Angular. Very few programming ecosystems could give rise to such unique styles. I wish my first programming language was javascript, instead of C64 BASIC, with its 38911 basic bytes free.