I think the lesson here is that you should always save (backup) your data on storage (services) and never on functional services. And this certainly includes Google, Apple and Microsoft Photos.
Totalle agree, I just googled it:
"Yukihiro 'Matz' Matsumoto heavily credits Smalltalk as the deepest structural inspiration behind Ruby’s object model. He combined Smalltalk’s beautiful object-oriented architecture and message-passing system with features from other languages to create a tool designed primarily for developer happiness."
Including the closures and collection operations.
I studied Scheme in CS around 1990, but also found it hard to grasp and to apply to real world problems. And all those parethesis, brrr... :)
The idea that "everying is an object and classes are nothing special" is neat, but it does not fit the way people (okay, I) think about real world problems. So I stuck with Smalltalk/OOP and am stil there :-).
In 1979, I made a program called VisiBase in this BASIC.
It's a visual database modeled after VisiCalc.
That won me a joystick in at a competition by the local computer store. :-)
Still have the source, that works in an Apple 2 emulator. It's 13 K in ASCII (untokenized).
This announcement terrfies me. I dont think MS now has developers that are competent enough to reliably change core parts of Windows like the Explorer (taskbar). This plan will not only introduce bloat with reduced performance, but will also reduce core stability further. (Explorer has hanging issues since the april update). So please, please, please @Marcus. If you want to add stuff, please do it in side apps. Leave the core alone, that's above your ability currently. For the core please only focus on bug fixing and removing bloat again.
I've downloaded the entire thing a while back for nostalgia sake.
And I am (of course) the proud owner of a physical copy of the "Smalltalk" issue :-)
https://archive.org/details/byte-magazine-1981-08
The appeal of having a very simple, base syntax and almost everything in the library / primitives, would be that code is always easy to read and write, also on the 'reflection' level, where most languages have specific keywords that cannot be used 'first class' with the rest of the language. E.g: Types next to class objects or operator overloading, look at Swift..
(Of course the complexity of a full working system (library) does not disappear in Smalltalk, it's just easier to read and modify. :)
I have this stored locally, of course.
And re-bought one physical issue from 1981,
that defined computer interaction and programming
as we know it today. Say my name... :-)
https://archive.org/details/byte-magazine-1981-08
Yes, and the hubris sting-of-death was UWP.
They tried to make Windows into a mobile OS,
severely restricting the alowed actions of programs,
including strict certification to be able to run them (elsewhere).
Of course nobody went for this and UWP died a quiet death.
Recently there are signs that MS is trying to go back
to making products that users actualle want (Win11 reverts).
We'll see...
Totally agree the only viewing methods in isolation,
is less valuable than viewing the methods around it "for free".
Indeed the methods in my classes are caryfully ordered,
to keep ones that are used together on the source together.
(And SmallJS is file based)
Imo, the problem with the 4-pane browsers are:
1 - The left-most 'package' pane is a flat list. And there are 10K + classes in e.g. Pharo. There are 900+ (!) packages in Pharo, in the pane, so its not easy to scroll through. This is solved 'manually' by have a hierarchical naming of packages. I think this pane should just have tree view.
2 - When developing an app, you may be working on classes in multiple packages. You want to have 'project' view with a simple way of switching between them, without having 10+ system browser windows open, like shown in the article. Dolphin Smalltalk has implemented this concept.
Shameless plug: SmallJS (https://small-js.org) has these too..