_sh

As a developer of desktop applications as well, I've asked myself these same questions. While I don't have any definitive answers for you, I'll share my thoughts.

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.

Interesting... How do you schedule this? If the queue is empty, do you back off and retry later, or spin the query until it returns a queue item, or some other way? It's a nice approach.

Indeed, the whole press release brings to mind a couple of points from "Engineering a Safer World" which, if you're interested in this stuff, I can't recommend enough[0].

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.

And:

  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.

In the press release we see both the "operator error" and "random events" hand-waving. Regardless of the fiduciary duty of this man, this is just not good enough.

[0] Open Access PDF: https://mitpress.mit.edu/books/engineering-safer-world

Thanks so much for your comment. I've just read (and played around with) your waveguide synthesis article, which led me down the rabbit hole of Sporth, ChucK, Soundpipe and now I find myself really excited looking over the contents of the "Physical Audio Signal Processing" book. I am going to learn a lot of new stuff today, thanks!

SNOBOL!

> why shouldn't I expect to be using these programs in 50 years?

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.

There are a couple of ways to look at this. Philosophically, to pick any one of your examples, my emacs is version 26.1. Is this the same software as emacs 15.10 released April 1985? Will a perl 6 program run on perl 5? Am I the same person I was 5 years ago?

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).

My thoughts on the philosophical aspects of the article don't really relate to Rust.

> 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?

...like all Linux installs will eventually be replaced by BSD? I don't think the big, complex picture of technology licensing can be reduced as flippantly as that.

"Fast is my favourite feature" --Someone, maybe from Google? Not sure.

Hey no problem, just add -Werror to your compiler flags (C/C++/Java) or '<TreatWarningsAsErrors>true</TreatWarningsAsErrors>' to your csproj (C#).

You're right, but there is a lot of misunderstanding around this end of the market, mainly because advances have blurred the traditional segmentation. When talking about ARM, the 'M' in Cortex-M means 'microcontroller' whereas the 'A' in Cortex-A means 'application'. Cortex-A systems are often at the centre of 'System-on-Chips' and will run linux, and indeed the NT kernel as well, as they are bundled with enough RAM and fairly modern peripheral interfaces such as HDMI.

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?

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king.

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.

Isn't this well understood as the 'revealed preference'?

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".

https://en.wikipedia.org/wiki/Revealed_preference

Electron sits in the same hybrid space as Cordova/Phonegap, and will suffer the same fate once React Native, or something similar, starts eating its lunch.

Dr Racket has something similar.

http://soegaard.github.io/blog/2013/06/21/running-man/

It's not so much a question of benchmarks, it's that one of the standard C tools for reading an arbitrary string from standard input is gets(). And if you reach for that from the standard toolbox, you've failed before you've started.

Whatever the causes may be, the effects are the same: these large institutional office parks are designed to isolate employees and reinforce the automobile-centric suburban lifestyle.

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.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses" --Bjarne Stroustrup

The guy at my Uni would stand stand at the door when they closed the Uni bar every Friday night and proposition every girl as they filed out the door. Every one. Never failed to score. He had no standards, but was amazing to watch.

He was Danish, we called it the 'Scando Sweep'.

"Fill in your job title. If you are unemployed or a student, put N/A."

Hardly equation solving.

Also picobit for scheme goodness: https://github.com/stamourv/picobit

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...

What an amazing thing!

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.

As well as jotux's excellent reply, I'd like to add that clint, valgrind and friends help out a lot when starting out with C. Learning to use these tools well (by using them all the time), will teach you a lot about the language.

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.

I doubt PICBIT (or Microscheme for that matter) could run on the PIC16 family, with it's 25 bytes of RAM. Wouldn't be much of stretch to port Microscheme to PIC18s though (with 512+ bytes of RAM), the code generator is pretty straight-forward: https://github.com/ryansuchocki/microscheme/blob/master/src/...

Through a co-op, not a middleman: http://noisetrade.com/info/about

The story of Sweet 16, Steve Wozniak ports BASIC to the Apple II.

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..."

Thanks for posting this. Forgive me for not looking over your code before asking: how does Om compare with Pedestal? Am I correct in thinking there is a lot of architecture overlap, with Pedestal's application state map occupying a similar role to React's virtual DOM, and mutation through message tuples in channels?

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?

The Stars My Destination stood out for me as something entirely different of it's time. A particularly memorable passage even featured ascii art!

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.

Python, seriously? How do you explain to 5-year-olds what the following line does?

  if __name__ == "__main__":

Python is there for when you move beyond beginner and you start to need libraries.

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.