So very sad. Ben Fry is one of my heroes. He's done an amazing job with Processing, over a very long time. I can't think of any other open-source project with the same consistency of vision and quality of execution, plus the level of design and usability.
I read a lot of Ben's code while I was working on the IDE for Arduino. It was always extremely clear, robust, and well-commented. And occasionally hilarious. My favorite part was the prompt to take a walk that showed up when you had created a new sketch for each letter of the alphabet on a particular day (sketch names defaulted to something like 20231003a, 20231003b, etc). But there were also some good digs at the failings of Processing's various dependencies, like Java and Mac OS.
The world of computational design and open-source software is much better for having Ben Fry and Processing in it.
One thing that I think is lost in a lot of the comments here is that, to a large extent, privacy is experienced, not factual. That is, in many cases, the breach of privacy is the act of mentioning something that should be private, not whether or not the system (or the person) knows that thing. This is something we tend to intuitively understand in our human relationships, but one that somehow seems to be forgotten in the design of these systems (or, at least, the conversations about them). We need good ways to tell the Google Assistant that something is private (or for it to figure it out for itself) -- even if it still possesses the underlying data.
(There are, of course, situations in which the actual existence or not of specific data is what matters, but I think those are less relevant to the success of something like Google Assistant than the perception of privacy -- and that perception is important, regardless of the underlying data.)
There are use cases for things like Arduino (a microcontroller development board). We'd like to allow uploading to Arduino boards from an online IDE. We'd also like to allow for interaction between sensors and actuators on an Arduino board and websites (e.g. programs written in the Scratch visual programming language). Yes, we can do much of this by having the user install a local application that communicates via web sockets, but that has its own security implications and adds an additional step for the user.
For hand-soldering, it might be nice to include 1206 packages in addition to 0603 ones, although I realize that would make the list much longer.
Another good reference for this kind of thing is the Fab Lab inventory: http://fab.cba.mit.edu/about/fab/inv.html and it might be worth looking that over to see if there's anything that seems worth adding.
My former advisor, Leah Buechley, and other friends created this introduction to programming and electronics via e-textiles and the LilyPad Arduino: http://sewelectric.org/
As someone who's tried to get from San Francisco to Silicon Valley without a car, I'd love to see companies like Google advocating and supporting better public transportation as well as just providing a private solution.
I've tried to source the components using as few vendors as possible (currently DigiKey, SparkFun, and Arduino, plus ordering the PCB) but it's definitely more work than just buying a kit. I'm working on a better solution but it's probably a ways off.
I read a lot of Ben's code while I was working on the IDE for Arduino. It was always extremely clear, robust, and well-commented. And occasionally hilarious. My favorite part was the prompt to take a walk that showed up when you had created a new sketch for each letter of the alphabet on a particular day (sketch names defaulted to something like 20231003a, 20231003b, etc). But there were also some good digs at the failings of Processing's various dependencies, like Java and Mac OS.
The world of computational design and open-source software is much better for having Ben Fry and Processing in it.