You also missed: "There is no alternative to creating and unleashing super-smart competitive AIs to outcompete all other humans in various other social groups than ours so we ourselves can succeed in business and life."

Related:
"The Case Against Competition" By Alfie Kohn
https://www.alfiekohn.org/arti...
https://www.alfiekohn.org/cont...
"No Contest, which has been stirring up controversy since its publication in 1986, stands as the definitive critique of competition. Drawing from hundreds of studies, Alfie Kohn eloquently argues that our struggle to defeat each other -- at work, at school, at play, and at home -- turns all of us into losers.
      Contrary to the myths with which we have been raised, Kohn shows that competition is not an inevitable part of "human nature." It does not motivate us to do our best (in fact, the reason our workplaces and schools are in trouble is that they value competitiveness instead of excellence.) Rather than building character, competition sabotages self-esteem and ruins relationships. It even warps recreation by turning the playing field into a battlefield.
        No Contest makes a powerful case that "healthy competition" is a contradiction in terms. Because any win/lose arrangement is undesirable, we will have to restructure our institutions for the benefit of ourselves, our children, and our society. For this [1992] revised edition, Kohn adds a comprehensive account of how students can learn more effectively by working cooperatively in the classroom instead of struggling to be Number One. He also offers a pointed and personal afterword, assessing shifts in American thinking on competition and describing reactions to his provocative message."

And also:
"The Surprising Truth About What Motivates Us" by Dan Pink
https://www.youtube.com/watch?...

See also my sig: "The biggest challenge of the 21st century is the irony of technologies of abundance in the hands of those still thinking in terms of scarcity."

(Inspired by by iAmWaySmarterThanYou's previous reply.)

Me from 2009: https://groups.google.com/g/op...
"... Put the cost of crashes together with other costs of bad design, and add in
the indirect cost of oil (all aspects of fundamental market failures), and
essentially, luxury electric cars produced using open designs (similar to
the Volvo above) should essentially be *free* to the user, paid for in cost
savings to society. :-) And, if that was the case, as a whole, our society
would *save* money on medical costs from injuries, costs related to deaths,
maintenance costs, production costs, defense costs for oil, and pollution
costs that are associated with other related health costs and global climate
change issues. :-)
      Essentially, I am suggesting that not giving away free safe luxury electric
cars to everyone who wants one is purely based on scarcity ideology, and
charging money to buy proprietary cars is costing the USA literally
trillions of dollars a year in hidden costs. :-)
      And, because we do pay those hidden cost one way or another in the USA,
through higher insurance costs, higher medical costs, less volunteerism that
can be put into other areas than responding to car crashes, and higher taxes
to cover the uninsured or pay for police and non-volunteer firefighters and
ambulance cores, I'll go out on a limb here and say, overall, if the USA
started giving away free-to-the-user electric cars (especially as trade-in
for "clunkers"), then US taxes would actually go *down* in the long run. :-)
      As a rough approximation, sixteen million new cars a year times US$30,000 a
car (lower price through volume) would be US$480 billion a year, an amount
easily found by reducing some of the about US$1 trillion defense budget
(including everything) and US$2.5 trillion health care cost which is about
half paid in taxes (total US$3.trillion for those two things, about US$2.25
trillion in takes). Essentially, US$480 billion a year for free-to-the-user
safe electric cars would be only about 20% of the US$2.25 trillion a year in
taxes we spend on health care and defense. And in turn, we would save a big
chunk of US$164 billion a year for accidents, and a big chunk of the defense
budget spent to defend oil supplies, and a big chunk of other medical costs
related to environmental pollution, and a big chunk of costs related to
global climate change. So, overall, the US tax payer would probably save
money on taxes by giving away free open-source safe luxury electric cars
(or, at least plug-in hybrids to start).
      Beyond that, then there is the additional benefits that more research in
auto safety (even to the cost of hundreds of billions of US dollars a year),
especially in perfecting cars that drive themselves at night using radar.
Such cars might eliminate virtually all driving accidents eventually, as
well as let the human "driver" of such a car use the internet or sleep
during the trip (about 90% of serious accidents happen at night, often
related to poor visibility or tiredness). ..."

Poking around the Pharo project (which I had not looked at lately) I see TelePharo which sounds like it supports one VM+Image inspecting another:
https://github.com/pharo-ide/T...
"Complete toolset for remote development of Pharo images."

Not having tried it, it sounds from the description not quite as lightweight and fluid an interaction as I had in mind? (In contrast with previous PataPata versions in Python/Jython circa 2007 that had multiple worlds in the same VM.) But a huge step in the direction of being a telescope/microscope for code in any case. And maybe sufficient for such purposes.

Pharo also has a long list of other add-on packages that address to some extent several of the issues I have raised here:
https://github.com/pharo-open-...

There is even a Tiling Window Manager.

And Squeak also has its own different projects:
https://squeak.org/projects/

So maybe some flavors of Smalltalk have gotten closer to many of the ideals I outlined above than I had realized?

https://pdfernhout.net/recogni...
"The big problem is that all these new war machines [and competitive businesses] and the surrounding infrastructure are created with the tools of abundance. The irony is that these tools of abundance are being wielded by people still obsessed with fighting over scarcity. So, the scarcity-based political mindset driving the military [and commercial] uses the technologies of abundance to create artificial scarcity [and other ills like using supernormal stimuli to direct attention]. That is a tremendously deep irony that remains so far unappreciated by the mainstream."

From 2012 by me: https://pdfernhout.net/recogni...
"Nuclear weapons are ironic because they are about using space age systems to fight over oil and land. Why not just use advanced materials as found in nuclear missiles to make renewable energy sources (like windmills or solar panels) to replace oil, or why not use rocketry to move into space by building space habitats for more land? ... There is a fundamental mismatch between 21st century reality and 20th century security thinking. Those "security" agencies are using those tools of abundance, cooperation, and sharing mainly from a mindset of scarcity, competition, and secrecy. Given the power of 21st century technology as an amplifier (including as weapons of mass destruction), a scarcity-based approach to using such technology ultimately is just making us all insecure. Such powerful technologies of abundance, designed, organized, and used from a mindset of scarcity could well ironically doom us all whether through military robots, nukes, plagues, propaganda, or whatever else... Or alternatively, as Bucky Fuller and others have suggested, we could use such technologies to build a world that is abundant and secure for all."

Some thoughts to amplify on a previous point about a tool-oriented paradigm for interacting with other systems (as it otherwise references linked discussion and ideas).

A key part of the Smalltalk paradigm is that you are working with one sea of objects which contains your development tools as well as whatever else you are working on. This certainly made sense early on in Smalltalk's development history with limited computational resources and a need to rapidly innovate development tools themselves along with the core language. But fifty years later, it is probably more useful generally most of the time to have a stable set of development tools (with one sea of objects) working on an application in another sea of objects. That way, when you make changes (including to core system classes, especially things like windows), you won't break your development tools.

Probably any Smalltalker has seen what can happen if you make a change to a window class that breaks the ability of Smalltalk to put up debugging windows, resulting in an endless loop of crashing windows.

As another example, the sadly late Les Tyrrell (who I worked together with at the Principal Financial Group in the 1990s using Smalltalk) once unintentionally corrupted the ENVY repository IIRC by adding a class-side method somewhere that was named something like class or name or such. He was very embarrassed by the whole thing, even as it was not his fault that ENVY was so fragile in that undocumented way. The project eventually recovered (might have taken a week to debug fix by cloning the repository?), and we all moved on. But that experience remained a sore point for Les, and led eventually to his work on OASIS related to being able to load Smalltalk classes into a (remote) browser for inspection without loading them into the local image.
https://wiki.squeak.org/squeak...

Today I was looking at some Cuis Smalltalk add-on packages using the Cuis file list, such as the ones that add lots of names colors. I wanted to understand what the packages did (including looking at any class comments). But I did not want to potentially pollute the pristine Cuis image by loading the packages just then since I did not know if I really wanted to use them. I could really have used Les' Oasis tools then, to be able to browse the classes in that code easily without modifying my local image.

With the PataPata experiments I did in Python/Jython, I also took steps in that direction that Les previously explored. Each window was sort-of its own "world" which could be saved in a separate world file. One window could reach out to inspect and change the underlying behavior in another window's world without modifying its own behavior. And you could potentially use that window you were modifying to modify yet another windows and so on. In theory you could potentially make a circle of changed windows back to modifying the first window if you really wanted.
https://sourceforge.net/projec...

This idea is about having tools that work like telescopes or microscopes to view other worlds, and also tools which support essentially using remote robotic manipulators to change those other worlds from a distance. It is a key idea that is not really in the Smalltalk cultural mainstream. The Smalltalk culture is still shaped around having just one sea of objects you work in at a time. The idea that you view or reach from one world to another is still not a mainstream idea there. But in most other development systems, you work with an editor or IDE like emacs, vi, VSCode, or Eclipse as an application implemented as one lump of code with one sea of objects when it runs, and you use that tool to modify some other totally different lump of code running some other sea of objects.

Smalltalk has powerful ideas like a uniform layout for objects in memory, and also being easily able to inspect, debug, and modify running code. Those are great. But the Smalltalk culture overall seems to have missed the idea that you as a developer might want to have several separate pools of code and objects which are only selectively connected (like when you use the browser in one pool to modify a browser in another pool, reducing the risk you will break the tool you are using to develop). Part of it just may be that in the past programming tools were often compiled and proprietary and seemingly immutable when you used them. Smalltalk made great progress towards source-available mutable tools, but it lost that useful-in-practice distinction between the tools you are using and the application you are working on. Yes, it is great to modify your tools as needed, but it is probably generally best to modify your tools in an intentional way at specific times.

This idea of remote control from one image to another is perhaps a deep idea in some ways. But it goes against so much past Smalltalk culture of having just one sea of objects you are working in at a time where every object can interact with every other object in an unrestricted way and where you can rapidly make changes to anything using the same tools you may be modifying. How can we have the best of both paradigms?

This idea of a self-reflective self-modifying system is celebrated in so much of Smalltalk culture. But I don't think it unreasonable to see an ocean of many loosely connected seas as any less self-reflective overall than doing all your programming travels in just one sea of objects which is disconnected from all the other seas out there.

A few more ideas (inspired in part by playing with Cuis Smalltalk):

* Favoring scrolling over clicking. Modern interfaces assume a scroll wheel which makes scrolling relatively easier than clicking a lot. Smalltalk UIs should consider this more in their design. But right now, Smalltalk UIs require a lot of clicking all the time to use. I used to prefer the click-ish interface of a Smalltalk code browser because it -- with ENVY in VisualWorks -- could show the history of each method and because navigating long text files with code (especially for C with separate header files) could become challenging. But with scroll wheels and outline tools and project-level text search (like in VSCode), that is less of an issue.

* Tiling window managers and/or better browsers. This also relates to the previous point. It's very common when doing development or debugging in Smalltalk to end up with dozens of windows showing the state of objects and various bits of code. Then you need to close them all. In general, managing a lot of windows is busy work. Smalltalk should address this better.

* Beyond the idea that image files could be plain text (aside from a minimal bootstrap image or compiled code to read them), image files could be split up by file or subdirectory for each class or package. Presumably 99% of Cuis Smalltalk's ~20MB base image could be supplied this way which means that it would be manageable much more easily in Git. Dan Ingalls has had a desire to preserve continuity from the earliest Smalltalk binary images by tracing and rewriting them. I respect that desire, but doesn't it still count as continuity if those objects just get rewritten out in a human-readable form instead of binary? So, almost all of the Cuis image could look like this part of its git repository that is just about add-ons (with a bit of extra for defining specific instances of objects):
https://github.com/Cuis-Smallt...

* Simpler code storage format. Smalltalk has an odd extra syntax for defining code that is recorded in changes files (with various exclamation marks). It would be simpler and cleaner if Smalltalk just defined such code using Smalltalk (like Python or Forth or Lisp does). Parsers that wanted to inspect such code instead of load it could read the limited subset of the language used for this. For example, something like perhaps: VM forClass: ... withMetadata: ... addMethod: ... (or shorter if it directly asks a class to do something).

* Better ability to do screen scraping from browsers. A lot of data now is on the web but it can be hard to work with. SqueakJS's JavaScript bridge is a step there. As is Smalltalk ports of Python's JQuery-like Beautiful Soup. HTML, CSS, and JavaScript -- while workable with care -- are a very complex and often inconsistent mess. Then companies with a vested interest in making money by standing between people and their data make things even more messy and complex. Being able to essentially scrape and import web data into Smalltalk easily provides an end run around the problem of more and more human knowledge being encoded amidst such clutter. Related:
https://github.com/pharo-contr...

* Numerical engines. BitBlit is an amazing idea about how to take a computationally-intensive process of moving bits around and wrap it in such a way that a graphics system can be reasonably fast overall even if the language calling the engine is not that fast. NumPy is a similar concept for Python and numerical approaches. Smalltalk could have better support for numerical processing by some sort of NumPy-like engine supporting quick math using multi-dimensional arrays and standard numerical algorithms. Ideally such an engine would be generated from typed Smalltalk (Slang) code. See also:
https://medium.com/smalltalk-t...
https://github.com/PolyMathOrg...

* Other computational engines. The previous point could be generalized somehow to having computational engines supporting other domains like text processing, audio processing, video processing, spreadsheets, and so on. These engines could be considered plugins. But going further, and building on a previous point on supporting assembler and a machine language monitor, ideally a Smalltalk (or whatever this new thing was called) system would support debugging and dynamically modifying theses specialized computational engines during a development cycle. This could be done initially in a portable way by leveraging WebAssembly. See also:
https://thiscontext.com/2023/0...

Again, I know there are likely various tools and experiments in all these directions. And some links are provided to related projects, But are they the default? How well do they work? And are they considered important ideas in the Smalltalk culture yet?

Still, many are happening as the links show. So I can hope Smalltalk (or whatever it will be called) will have a bright future.

I copied the previous points here as a test of Lively and plan to add the text of this comment there as well:
https://lively-web.org/pdfernh...

As an experiment, Lively Kernel is amazing and was well worth doing. But, as I think on whether to use it myself today for new projects, for all the impressive innovations and hard work in Lively, now that SqueakJS can load Smalltalk images into a web browser, is it really worth it anymore to make jump through so many extra hoops just to get JavaScript to act more like what Smalltalk can do out of the box? Leveraging portable WebAssembly to support Smalltalk everywhere is maybe more of the future than working with problematical overly-complex and inconsistent JavaScript/HTML/CSS itself?

A different path though is, say, TypeScript, Mithril, and Tachyons, which I have used for other projects to paper over the warts of JavaScript, and HTML, and CSS. But then you are still left with all the underlying complexity needed to support those (and VSCode as a developer environment as well).

Thanks for your reply. One key point from Daniel Quinn's "Beyond Civilization" on just walking away instead of pursuing violent revolution:
https://en.wikipedia.org/wiki/...
"Part 4: Toward the New Tribalism
Quinn states that abandonment is a more workable technique to be rid of hierarchy when compared with violent upheaval; this is because, unlike with upheaval, the people in power have no way to defend themselves against abandonment. He also claims that people do not (and cannot) transform our culture toward tribalism in one single event and, therefore, do not need to wait for conditions to improve before starting to act more tribally (for example, by first ending sexism or racism before moving on to tribal endeavors). Quinn proposes an "incremental revolution" in which groups of people begin to form tribes little by little. These tribes, he speculates, would not be based on shared ethnicity like their historical precedents, but rather, on shared occupational interests. In addition, he proposes that no move beyond civilization could cause greater harm to the environment than already does our civilized society, which he thus terms the "culture of maximum harm", since it incites each and all of its members to attain the highest, most world-destructive point of affluence."

That theme can be found in many places, from the US Civil Rights Movement (like the Birmingham Bus Boycott) to Gandhi's non-violent overthrow of the British in India to labor union movements with general strikes and so on.

See also:
https://www.aeinstein.org/198-...
"Practitioners of nonviolent struggle have an entire arsenal of âoenonviolent weaponsâ at their disposal. Listed below are 198 of them, classified into three broad categories: nonviolent protest and persuasion, noncooperation (social, economic and political), and nonviolent intervention. A description and historical examples of each can be found in volume two of The Politics of Nonviolent Action by Dr. Gene Sharp."

Although in general most such actions are usually to accomplish social change, which is somewhat different than the idea of just walking away to something else.

Another book on that idea is James P. Hogan's Voyage from Yesteryear:
https://web.archive.org/web/20...
"The book has an interesting corollary. Around about the mid eighties, I received a letter notifying me that the story had been serialized in an underground Polish s.f. magazine. They hadn't exactly "stolen" it, the publishers explained, but had credited zlotys to an account in my name there, so if I ever decided to take a holiday in Poland the expenses would be covered (there was no exchange mechanism with Western currencies at that time). Then the story started surfacing in other countries of Eastern Europe, by all accounts to an enthusiastic reception. What they liked there, apparently, was the updated "Ghandiesque" formula on how bring down an oppressive regime when it's got all the guns. And a couple of years later, they were all doing it! So I claim the credit. Forget all the tales you hear about the contradictions of Marxist economics, truth getting past the Iron Curtain via satellites and the Internet, Reagan's Star Wars program, and so on. In 1989, after communist rule and the Wall came tumbling down, the annual European s.f. convention was held at Krakow in southern Poland, and I was invited as one of the Western guests. On the way home, I spent a few days in Warsaw and at last was able to meet the people who had published that original magazine. "Well, fine," I told them. "Finally, I can draw out all that money that you stashed away for me back in '85. One of the remarked-too hastily--that "It was worth something when we put it in the bank." (There had been two years of ruinous inflation following the outgoing regime's policy of sabotaging everything in order to be able to prove that the new ideas wouldn't work.) I said, resignedly, "Okay. How much are we talking about?" The one with a calculator tapped away for a few seconds, looked embarrassed, and announced, "Eight dollars and forty-three cents." So after the U.S. had spent trillions on its B-52s, Trident submarines, NSA, CIA, and the rest--all of it."

==== On inequality harming the rich

Also, as pointed out by numerous people, "rising inequality hurts the rich":
https://duckduckgo.com/?q=risi...

One reason that capitalist economies grow more slowly when wealth is concentrated because most people become cash-starved and the market is unable to perceive their needs and so can't respond by production. Since the wealthy save most of their money, essentially more and more cash is sucked out of productive uses and into the "Casino Economy" of the FIRE (finance, insurance, and real estate) sector. Less money is spent on research, development, and material production.

Another reason is just that such an unequal wealth balance leads to a lot of social strife because of all the needless human suffering. That strife just makes for unpleasant places to live, with lots of broken marriages, lots of homeless people, lots of avoidable disease, lots of property crime, lots of violent crime, and so on.

Also, wealth can be an isolating factor, as Sunita Luthar explores:
https://www.psychologytoday.co...
"It is widely accepted in America that youth in poverty are a population at risk for being troubled. Research has repeatedly demonstrated that low family income is a major determinant of protracted stress and social, emotional, and behavioral problems. Experiencing poverty before age 5 is especially associated with negative outcomes. But increasingly, significant problems are occurring at the other end of the socioeconomic spectrum, among youth en route to the most prestigious universities and well-paying, high-status careers in America. These are young people from communities dominated by white-collar, well-educated parents. They attend schools distinguished by rich academic curricula, high standardized test scores, and diverse extracurricular opportunities. The parents' annual income, at $150,000 and more, is well over twice the national average. And yet they show serious levels of maladjustment as teens, displaying problems that tend to get worse as they approach college. ..."

As she mentions elsewhere, wealthy people tend to live on larger plots of land more isolated from neighbors (both due to distance and due to purchasing services instead of bartering with neighbors). As a result, wealthy people typically receive less community support from these fewer nearby neighbors when they have some issue money can't easily solve (like a death in the family, or child behavioral problems, or health issues, or depression, and so on). So wealthy people tend to develop a dim distrustful view of community support in contrast to people who live in happier tighter knit communities on smaller lots with a lot of local interactions. Essentially, middle class people tend to have more fun get-togethers with neighbors than wealthy people who are more likely to barbecue alone.

Some wealthy people also end up living in fear of losing their wealth because they don't have a lot of these local social connections and so don't have as many alternatives to paying for service as middle class people in healthy communities.

As I write about, there are five interwoven economies (or forms of transactions): subsistence, gift, exchange, planned, and theft. A healthy society has a good balance of the first four (reflecting cultural history) and minimal theft (which tends to happen more when social consensus breaks down). The push in the USA to have more and more exchange transactions (e.g. women moving into the paid workforce; monetizing every interaction; widespread rent-seeking made possible in part by a changing political environment) has increased precarity greatly for many families who no longer have time or energy to participate in subsistence, gift, or planned transactions.

This issue of increasing precarity from a greater exchange emphasis also relates to Elizabeth Warren's book "The Two Income Trap".

And from a different direction, as the FSF points out:
"Studies Find Reward Often No Motivator: Creativity and intrinsic interest diminish if task is done for gain"
https://www.gnu.org/philosophy...

Dan Pink says much the same here:
"The Surprising Truth About What Motivates Us | Dan Pink"
https://www.youtube.com/watch?...

So, essentially, the wealthy and even upper middle class are not served that well by current political and economic ideologies celebrating unlimited wealth concentration. But as a sort of tragedy of the commons, individual people may be slightly better off with a lot more personal wealth than otherwise (especially in areas of strife where they need to pay ever more for personal security guards) -- even as overall the rising wealth inequality in the society required for those individual economic gains makes their life much worse overall. Extreme wealth concentration is kind of like burning a house down to keep warm; it's just a dumb idea even if it might seem to make sense in the short-term for specific individuals when taking a very narrow view of things.

And, sadly, the USA is increasingly becoming a poster child for parasitism as your list reflects. In every example you cite, one can easily find some group who is privatizing gains while socializing costs and risks. And the institutions that should help prevent such parasitism (e.g. Congress, executive regulatory bodies) are increasingly dysfunctional and often corrupted by regulator capture. One thing parasites become very good at through evolution is evading the immune system or co-opting it.

Ultimately, capitalism can't functional well if wealth becomes so concentrated. Then it becomes trivial for financially obese people to buy laws in their favor to ensure wealth becomes even more concentrated, resulting in more and more people suffering for want of access to money (even when the poor are working two jobs).

See also Jane Jacobs' "Dark Age Ahead":
https://en.wikipedia.org/wiki/...
"Dark Age Ahead is a 2004 book by Jane Jacobs describing what she sees as the decay of five key "pillars" in "North America": community and family, higher education, science and technology, taxes and government responsiveness to citizen's needs, and self-regulation by the learned professions.[ She argues that this decay threatens to create a Dark Age unless the trends are reversed. Jacobs characterizes a Dark Age as a "mass amnesia" where even the memory of what was lost is lost.âS"

How to fix this?

One option is to build new alternatives within the decaying husk of the old. The Free and Open Source software movement (for both code and data) is one positive thing there -- strengthening the gift and subsistence economies even if the exchange and planned economies are increasingly dysfunctional.

Another option is a universal basic income to help level the economic playing field a bit and give people more options when faced with bad economic deals.

There are obviously many other specific reforms (like the FSF proposes here, or things like ending the cap on social security taxes, or various other tax loopholes like "carried interest"), but each runs into a specific special interest of concentrated wealth that is hard to get past. So roundabout things like FOSS or a UBI are more like water in a stream running around rocks (and maybe eventually wearing them down the seemingly immovable and impregnable rocks over a long time).

Like mentioned in Daniel Quinn's book "Beyond Cvilization", time and time again civilizations (as represented by capital cities) have collapsed as people have literally walked away into the wilderness leaving behind increasingly dysfunctional social hierarchies in such cities (and related issues they may have failed to manage whether drought or plague which are typical stressors before collapses). Granted, some places can be well run for centuries and great places to live for most of that time, so this isn't a complaint on cities in general either then or now.

Two differences from the past are large populations and WMDs (like nuclear bombs and engineered plagues). When cities collapse in the future, there will be no intact ecosystems to migrate too, and too many mouths to feed without modern technology. And there may be too many crazy self-absorbed people up the hierarchy willing to start a nuclear war for whatever crazy reasons of the moment (Ukraine being a potential example). So that all will make it harder on the survivors of the collapse.

One other way to prepare for a collapse is to have better technology libraries (like in the "Mote on God's Eye" sci-fi novel by Larry Niven and Jerry Pournellel). OSCOMAK is an idea in that direction by me:
https://www.kurtz-fernhout.com...

My mother saw relatives starve to death during the politically-created "Hunger Winter" in the Netherlands during WWII after she also saw her home city of Rotterdam firebombed to a moonscape, so these issues are perhaps a bit closer to my own experience (even if second-hand) than for many people in the USA.

Alan Kay has talked about improving Smalltalk and also suggested to "burn the disk packs" now and then to start fresh. Like he said, Dan Ingalls would rewrite the Smalltalk class library every few years. Here are some ideas off the top of my head for transcending Smalltalk (as a system and culture) to something better based largely on embracing other innovations that happened elsewhere. I acknowledge that some flavors of Smalltalk as well as other languages inspired by Smalltalk explore some of these already. And admittedly I have been away from the Smalltalk community for many years, so some of my concerns here may be somewhat dated -- even if they were concerns that originally drove me to look for alternatives or to experiment with building alternatives in Python/Jython, Java, JavaScript/TypeScript, and so on.

Smalltalk (or whatever it would be called) as a system and culture could more firmly embrace:

* The UNIX philosophy of working well with a filesystem with small utilities that use pipes and redirects to get work done. In some ways this is very close to what happens in a Smalltalk image of objects, except the filesystem provides an immediately persistent store and (unfortunately) a bunch of varying binary and textual formats for data. It is a common complaint that Smalltalk does not play nice with other tools. Smalltalk does not have to be that way since it can easily read files and do anything with them, but it is just a cultural thing perhaps? This would also include being able to easily run small stand-alone single-purpose apps like a Fahrenheit to Celsius temperature converter or other utility (which relates to later points on building simpler Smalltalk "image" files).

* "The power of plain text". Smalltalk could write out its image in plain text, but does not for whatever initial reason to be more compact. Smalltalkers created and improved image write code to rewrite binary images. But just cutting and pasting textual code is a lot easier than messing around with binary formats when defining Smalltalk âoeimagesâ. Ironically, the original Smalltalk's like Smalltalk-72 started with a readable plain text file to bootstrap themselves. (Craig Latta and others have explored building modern images from the ground up like with Spoon.) Smalltalk would benefit from being plain text first in every aspect, with binary formats for saving data used sparingly in special cases, given disk space is relatively cheap these days. JSON is a touchstone here, even if the ability to define complex literal constants was in VisualWorks using a notation that preceded JSON. Related is the idea of writing out JSON-like data but with a standard way to supply metadata like types.

* "If it does not have a URL it is broken" (my adage). The URL (Uniform Resource Locator) or really the broader URI (Uniform Resource Identifier) is a deep idea that uses the power of plain text to define a pointer. Typically, using the http scheme, that pointer names a computer on the internet and a path to a specific file for retrieval. But URIs can do more that that but in http and in a variety of other schemes liek, say, the magnet scheme for identifying resource via a hash of their content. URIs can also encapsulate the state of a small part of a system and used to return that part of the system to that state. While objects in a Smalltalk image can be found in various ways, why couldn't they all have consistent URLs or URIs? And why couldn't every operation or state in a Smalltalk browser (or other app) have a URI that can be used to return to it (perhaps also as part of an undo/redo system)? And what are other ways that Smalltalk could embrace the URI?

* Multiuser support. Related to the point on URLS, Smalltalk typically sees itself as a single-user system. With Squeak, we had a long debate over purpose, about whether Squeak was to support an individual or a community. As with the rise of Git and GitHub, we can see how important it is to support a community of coders. Smalltalkers have been moving in that direction (like with Montecello and Metacello and the Lively "parts bin"), but there still may be a cultural speed bump there which translated into less native support for that.

* Support for modules. It is hard for programmers to work together without some sort of module support with local namespaces. Sure programmers can prefix classes in an adhoc way with a couple of unique letters. But even such an adhoc workaround does not address people adding new methods to base classes. In JavaScript, adding new methods to base classes (other than as polyfills for a standard) is considered bad practice nowadays. Smalltalk derives a lot of power from a having a sea of objects in a common format that tool can work with. But there is some aspect of that which has not worked well and which can still be improved. Yes, there ar various suggestions and approaches for supporting modular code with Smalltalk, but it remains an issue.

* Image segments. A broader related idea is to be able to read and write parts of images. Some Smalltalks have supported image segmentation. Somehow it would be great to link that idea transparently with the ideas of modules, which would probably require tagging objects somehow with what segment (or perhaps application) they belonged to.

* Implementation inheritance is problematical. It's one thing for objects to delegate responsibility to other objects. But inheriting behavior form superclasses tends to lead to brittle code. A more powerful and modular paradigm might be to have classes which did not inherit code formally but defined all the behaviors they needed by drawing from methods or sets of methods that were defined elsewhere as well-crafted algorithms. The earliest Smalltalks were a bit more like this (without inheritance). See also the later point on functional programming support. Inheritance is one of those ideas that sounds great in theory (especially with overly simplistic examples) but creates immense problems in practice. Visual Basic has done really well by just having non-inheritable importable components that can be configured using an inspector.

* Parallel processing support. Smalltalk is inherently a parallel-processing language given the idea of message passing. But in practice the VMs people use tend to be single threaded (with perhaps cooperative threads within that model). Java, as an example, has a parallel processing model that makes it more scalable (see for example the book "Java Concurrency in Practice"). Occam is a language designed from the beginning in the 1980s to be for parallel processing on Transputers. Erlang is another great example to look at. Again there are Smalltalk systems that support parallelism like GemStone but they are not common. Python has also suffered from this issue with a "global interpreter lock". Yes, you can sort-of get around this by launching multiple VMs, but it is not the same and support within a language.

* A Free and Open Source license. This used to be an issue for decades among the mainstream Smalltalks. Even Squeak initially had a license that was problematical. I spent years trying to get people to see how the initial Squeak licenses was problematical for community development. I'm glad that was eventually resolved for Squeak. But Smalltalk has lost a lot of momentum over that. And VisualWorks -- arguably still the premier Smalltalk system -- is still under a proprietary license. Admittedly this is not that big of an issue anymore -- although I would still suggest having better tools to track licenses in code you import into a Smalltalk system.

* Reifying the VM. The base object in Smalltalk has a lot of behavior. I'd prefer it if the base Smalltalk object has no behavior and you used messaged like "VM print: object." to do basic things with it. Then you could explicitly add whatever behavior you wanted. Yes I know some Smalltalks support a more basic object -- again this is more a cultural thing reflected in libraries and programming practices.

* Better database support in the core. Like the above about files this is a sort-of cultural thing. Yes, Smalltalks can be great at accessing databases via various wrappers â" but with an object/table mismatch. I donâ(TM)t know what the answer is other than this remains a challenge. See also the point below on transactional and functional programming.

* Better native RDF / triple / semantic support and a tool-oriented paradigm for interacting with other systems. See my comments here for example:
"[fonc] On inventing the computing microscope/telescope for the dynamic semantic web"
https://fonc.vpri.narkive.com/...

* A "killer" application driving adoption like a better Thunderbird for handling email and all a person's social media (and then going beyond to add in ideas from the "Analyst" software). See for example my comments here:
https://pdfernhout.net/thunder...
https://mail.mozilla.org/piper...

* Functional programming (or multi-paradigm). I know that Smalltalk defined the message-passing "object-oriented" paradigm. But before Smalltalk there was Lisp, from which Smalltalk borrowed some ideas. Modern Lisps support functional programming using multiple dispatch for functions based on argument types. Functional programming is a great paradigm for a lot of a code base (even if conceptually writing 100% functional programming code tend to become problematical, especially with I/O). JavaScript and Python are multi-paradigm languages that support functional programming as well as class based programming (even if they don't support message passing, like with "doesNotUnderstand", which is part of the Smalltalk magic). SQL is also essentially a functional programming languages (if you squint at it). The notion of having a lump of typed data in memory or in a database on which you perform operations (often via transactions) is a powerful idea. Smalltalk can support that, but again this is a cultural thing.

* Undo and redo. As with the point above on transactions, MacApp (a programming framework fro Apple form the 1980s) and some other UI libraries supported creating actions which transformed the state of an application and were undoable. The Redux model in JavaScript for React is also in this direction somewhat (but not completely). Granted, Lively Kernel supports time-travel debugging to go back in time. But this is till not the same as UI library (or language) paradigms oriented around creating undoable and redoable transactions. This idea becomes even more important when support multi-user interactions on a shared virtual world.

* Reactive programming done like Mithril for JavaScript or as with the Elm language. Essentially, rather that the typical way of hooking up Smalltalk UIs using dependencies and observable data which sends "changed" messages (which can be hard to debug), complex UIs are easier to reason about if they work like some 3D video games and are re-rendered after they are "dirty" by being touched by user events (like mouse clicks). React itself also gets this wrong by prematurely optimizing an assumption that state should be stored and updates in each component. Stuff like RxJS is even worse, reinventing dependencies in strange way. It is a much easier to write and maintain UI code when you just write event handlers and the system knows that if such an even arrives, a redraw will eventually be needed. And if performance or other considerations are an issue, then you tweak things a bit or use Observables in a very sparing way.

* Being event driven instead of using polling. This is less of an issue the past decade with Squeak, but polling in early Smalltalks could burn a lot of CPU and make systems less responsive (higher latency) compared to being fully event driven. More recent Smalltalks are doing better here, but they may go too far (as with Morphic perhaps?) to make it hard to respond to basic events cleanly.

* Optional type declarations (like TypeScript for JavaScript) especially at a minimum for documentation or run-time assertions. Debatable if it creates excessive complexity for implementation.

* Better assembler support and perhaps even Forth support for self-hosted code generation, along with better tools for low-level interaction with hardware like a Commodore 64 machine language monitor.

* Minor changes to make the language a bit like more popular languages (like C or Java or Python), such as using double quotes for strings (instead of comments), using double slashes for line comments, using slash star for multi-line comments, and using multi-quotes for longer multi-line strings with embedded quotes like with Python triple quotes. Personally I feel the apostrophe should be generally reserved for its use in text instead of defining a string. Such changes are not especially essential though, but they would ease the learning curve a bit for people who are already used to other languages.

* Support for both text-based and visual programming. Fabrik and Morphic are interesting visual programming ideas and make for impressive demos for simpler systems (like Dan Ingall's "windmill" example with a rotating stars and a rectangle and another star). Stormworks and Minecraft and more games and applications also support visual programming. But using visual programming can involve a lot of mouse clicking and the results can be problematical to view and search and change as plain text (see for example VisualAge Smalltalk). There obviously is a power to visual programming and hooking up components that way. But more thought need to go into making visual programming transparently inter-operable with plain text programming. And yes, I know there are some experiments in these directions already, but again maybe it is a cultural thing? But if I could only have one paradigm, I would still prefer the plain text approach to hook stuff up (especially coupled with Mithril-like reactive programming for UIs as above).

* A great set of common UI widgets that work in expected ways and are well-documented and reasonably stable.

* An emphasis more on *standards* than *implementations*. Standards need FOSS reference implementations, but the two are different. When I was at IBM Research circa 2000, a mantra there was cooperate with other companies on standards but compete on implementations. By emphasizing good standards for storing, transmitting, inspecting, and transforming all types of objects, the Smalltalk community could make it easier to collaborate over the long haul. Of course, FOSS developers don't have to compete on implementations either, but it is true that as developers may have different implementation approaches they want to experiment with and advocate for. But the key question is what standards can Smalltalk developers agree on? Including on what ways to make standards extensible with semantic versioning or whatever so they can continue to be adapted to future needs while still preserving the best of the past?

Things Smalltalk should keep:
* the distinction between named code (from a class) and named data in an object (something both JavaScript and Python lack and suffer for as they in practice mix code and data in each object).
* message passing and "doesNotUnderstand"
* being written in itself
* great inspectors
* great debugger which you can write code in
* keyword syntax to label arguments
* tunable garbage collection
* the ability to generate code in other languages like C
* being able to be put on bare metal
* running in a browser like with SqueakJS or Lively Kernel
* the shared effort for supporting a great cross-platform VM

That said, I have followed Dan Ingalls' lead to work in JavaScript/TypeScript for the ubiquitous nature of it. If the original Smalltalk team had to choose between JavaScript everything on systems with over 1000X more speed and memory than what they worked with in 1972 or using Smalltalk, they probably would pick the modern option.

But can we do better? As with some criticisms on Quora by Pharo developers of Dan Ingall's Lively Kernel work, what if we had put the same effort into making a Smalltalk better?

Web technologies also have lots of issues. It took quite a while yesterday and like a zillion downloaded components (well, hundreds, via npm) to get Lively Kernel installed locally (including of both Babel and Google's Closure library). The disk footprint in the lively.kernel directory is about 1,659,240,000 bytes (without having written any substantial code in it). Meanwhile Cuis Smalltalk -- as an example -- strives for clarity and purity and small footprint. And Pharo can be installed much more easily. Both are less than one tenth the size of lively kernel install. Likely Kernel is an impressive work of art and ingenuity. Maybe disk space does not matter much now -- but complexity still does, and building on JavaScript and web technologies introduces a lot of complexity. Is it worth it? Good question.

Anyway, about all the time I have to refine this list right now.

https://www.quora.com/Are-Smal...

From Alan Kay, on the question "Are Smalltalk and Pharo out-dated?":

====

Sure. What's disappointing is that Smalltalk is still quite comparable to most programming languages in use today (and not always negatively).

This means that the computing establishment has done a terrible job in coming up with something qualitatively better over more than 40 years.

Added: October 27, 2020.

In a conscious analogy to Lisp, Smalltalk is made from just a few ideas with as much of the language as possible as "library". Both languages have enough of a reflective meta-structure to allow many different pathways from the kernel.

So, a simple way to improve things using Smalltalk would be just to completely rewrite the library from scratch. Dan Ingalls used to do this every few years at Parc, and we did quite a bit -- though not enough -- when Squeak was done in the 90s.

One of the human "cognitive biases" is "loss aversion" and this ties in with others such as "investment value" (the time put into something makes it worth more), etc. There is also plain laziness, etc. All these have made the history of Smalltalk after Parc completely different from how we used Smalltalk within Parc.

But the 40 years since 1980, with the immense scalings and other happenings that have taken place -- really demand a deeper set of designs, some of which affect the underlying semantics, especially for message passing.

I've written and talked about some of these elsewhere, so won't iterate here. People who consider themselves to be computerists and who are interested in languages, should take a look at what languages need to be able to do. If they did, they could not just answer the question, but also start to provide some of the new problems to be solved and the start of solutions for them.

====

See also:

"Alan Kay at OOPSLA 1997 - The computer revolution hasnt happened yet"
https://www.youtube.com/watch?...

Other reflections, by Dan Ingalls:

"YOW! 2016 Dan Ingalls - Pronto: Toward a Live Designer's Notebook #YOW"
https://www.youtube.com/watch?...

"The evolution of Smalltalk: from Smalltalk-72 through Squeak"
https://dl.acm.org/doi/10.1145...

And also from Doug Engelbart on "The Unfinished Revolution II":
https://www.dougengelbart.org/...

But yeah,the lack of progress -- and even frequent regress -- since Xerox PARC in the 1970s is pretty disappointing in many ways...

Still waiting on Theodore Sturgeon's 1950s vision of "The Skills of Xanadu", too (a story which sparked a lot of this innovation including Ted Nelson and hypertext and thence the world wide web):
https://archive.org/details/pr...
https://archive.org/details/ga...

I agree that in theory nuclear fission energy can be done well in an environmentally-sound way overall -- except, as I wrote year ago to James P. Hogan in response to his "Know Nukes" essay, that probably requires a change to our socio-politico-economic system because our current system incentivizes organizations to privatize profits and socialize costs and risks. For example, the too-low Fukushima sea wall which saved one group a little bit of money in the short term but then created a disaster for hundreds of thousands of people later. And of course putting backup generators in a basement where they could be flooded was also short-sighted -- although it is not clear to me if that decision also was about cost-savings as opposed to just lack of imagination.

In any case, current nuclear energy done within our current economic system has a legacy of exclusion zones which also kill wildlife (and displace people) and their size should be considered when calculating the "footprint" of nuclear energy:
https://www.britannica.com/sto...
"Following the [Chernobyl] disaster, the Soviet Union placed a circle-shaped exclusion zone with an 18-mile (about 30-km) radius around the plant. The total area of the zone was about 1,017 square miles (2,634 square km), which was later expanded to 1,600 square miles (4,143 square km) to include additional areas that were later found to be heavily radiated. ...
      [For Fukushima] As more information about the path of fallout emerged, 80 square miles (207 square km) of land northwest of the initial exclusion zone were also declared dangerous by the Fukushima prefectural government and included in the greater exclusion zone (which increased the total area off-limits to 311.5 square miles [807 square km]). However, starting in August 2015, some areas in the greater exclusion zone that earlier had been declared contaminated were considered safe enough for former residents to either visit their homes and businesses for short periods or return to them permanently. By 2017 the exclusion zone had declined to 143 square miles (371 square km). Despite this seemingly good news, few people have returned so far, most of them elderly. Some studies investigating the effects of the Fukushima nuclear disaster on birds and insects have reported population declines in some species, as well as declines in overall biodiversity among these groups in the exclusion zones. However, as in Chernobyl, some populations of persecuted wild animals, such as wild boar, have increased."

It's reasonable to debate whether *future* *different* nuclear systems used in a different *post-scarcity* social context could be much safer and lower environmental impact than the nuclear energy systems we have now. And where post-scarcity abundance for all (with an accompanying social shift) is made possible in part from abundant energy from nuclear processes which indeed is "too cheap to meter". And also where nuclear cycles are designed without the constraint that they also are part of a nuclear energy system designed to support nuclear bomb construction (which is part of why, say, the US did not explore thorium nuclear power more.) And where a lot of the same recent improvements to our understanding about materials and our ability to design collaboratively better through the internet and via free and open source gift-economy philosophy are as applicable to designing better nuclear systems as to designing better renewable systems and improving energy efficiency. But that is not the discussion most people seem to be having about nuclear energy today.

Meanwhile, renewables like solar PV (and -- to an extent -- wind turbines) and also energy efficiency (like LED bulbs and home insulation) have different small-scale short-lead-time local-effect characteristics that make them more compatible with our current profit-privatizing-and-cost-socializing economic system.

And then there is also the eventual possibility of hot and cold fusion energy, which also may have a different social dynamic and is likely less risky overall than fission energy.

Personally, I'd rather see much slower-moving vertical-axis wind turbines (for ones built on a huge scale) for the reasons you mention about harm to birds, as well as to reduce low-frequency sound that subtly harms other creatures (including humans and whales). Related (but partisan):
https://www.wind-watch.org/doc...
"Infrasound is common in our world, but most natural infrasound is irregular and random, or is caused by a transient event (e.g. earthquakes). Some frequency bands below 20 Hz have been shown experimentally to cause a physiological stress response in humans at below audible levels.[3] Industrial machinery noises are often regular and repetitive, as is the case with wind farm noise emissions, across the audible and infrasonic frequency spectrum."

Vertical axis alternative example (where reduced turbulence and vibration means less unwanted noise):
https://www.forbes.com/sites/a...
"A recent discovery by engineers of Oxford Brookes University's School of Engineering, Computing, and Mathematics could change the design of offshore wind farms forever. The study, led by Professor Iakovos Tzanakis, demonstrates that deep sea and coastal wind turbines could achieve a 15% increase in power output if traditional horizontal axis wind turbines (HAWTs) are replaced by a vertical axis wind turbine (VAWT) design. While classic HAWT windmills produce energy with a standard three-blade "pinwheel" design, VAWT utilizes a more cylindrical shape with blades rotating around a central shaft. The main issue with conventional HAWT windfarms - which can number 60 to 70 turbines over 1500 acres - is that efficiency degrades rapidly in the back rows due to turbulence from the first rows of the formation. Vertical axis turbines solve this issue by generating less turbulence, and in some cases even improving the efficiency of nearby turbines."

Also:
https://newatlas.com/energy/co...
"Some engineers and operators believe this could be a niche where VAWTs could shine instead. Their blades reach upward, but all their other heavy bits are at the bottom, so their natural tendency is to sit upright. Also, they can accept wind energy from any direction, rather than needing to turn to face into the wind, cutting down on some more heavy gear you'd find up high on a HAWT. They're typically far less efficient than a regular three-blade HAWT, sucking less energy out of a given breeze, but on the other hand, you can place them closer together without a drop in performance, meaning they could potentially suck more energy out of a given patch of ocean."

But to be fair, in the same way people talking about next-generation nuclear are not debating today's nuclear issues, my comments above about next-generating wind turbines also don't address the drawbacks of deploying more of current-generation high-speed horizontal access wind turbines where turbulence becomes harmful sound and (as you mentioned) fast moving blades are unavoidable by many birds.

What are the odds some company gets an exclusive sweatheart deal and this technology is essentially locked up for 20 years?

Related by me from twenty years ago:
https://pdfernhout.net/on-fund...
"As a software developer and content creator, I find it continually frustrating to visit web sites of projects funded directly or indirectly by government agencies or foundations, only to discover I can't easily improve on those projects because of licensing restrictions both on redistribution and on making derived works of their content and software. ..."

A shorter version of that:
https://pdfernhout.net/open-le...
"Foundations, other grantmaking agencies handling public tax-exempt dollars, and charitable donors need to consider the implications for their grantmaking or donation policies if they use a now obsolete charitable model of subsidizing proprietary publishing and proprietary research. In order to improve the effectiveness and collaborativeness of the non-profit sector overall, it is suggested these grantmaking organizations and donors move to requiring grantees to make any resulting copyrighted digital materials freely available on the internet, including free licenses granting the right for others to make and redistribute new derivative works without further permission. It is also suggested patents resulting from charitably subsidized research research also be made freely available for general use. The alternative of allowing charitable dollars to result in proprietary copyrights and proprietary patents is corrupting the non-profit sector as it results in a conflict of interest between a non-profit's primary mission of helping humanity through freely sharing knowledge (made possible at little cost by the internet) and a desire to maximize short term revenues through charging licensing fees for access to patents and copyrights. In essence, with the change of publishing and communication economics made possible by the wide spread use of the internet, tax-exempt non-profits have become, perhaps unwittingly, caught up in a new form of "self-dealing", and it is up to donors and grantmakers (and eventually lawmakers) to prevent this by requiring free licensing of results as a condition of their grants and donations."

https://inhabitat.com/

Lots of ideas there on doing more with less -- as well as doing more with more.

One example from there:
https://inhabitat.com/tiny-hom...
"Starting at a price of $339,995 plus customizations, the Living Vehicle features a spa-like bathroom, home theater and a chefâ(TM)s kitchen. It even has a convertible mobile office loaded with the most up-to-date Apple technology. ... This year, the 2023 Living Vehicle model comes with a more powerful, self-sufficient technology called Watergen (added for $25,995) that can generate drinking water from humidity in the air. The designers say this technology not only allows owners to drive and live anywhere, even the most arid regions, but also reduces the ownerâ(TM)s carbon footprint and plastic pollution by eliminating single-use plastic containers for water and transportation supply chain pollution. The system provides up to five gallons of drinking water per day, enough for a family. ... Moreover, solar panels on top of the roof create more power than is available to most solar-powered homes. The newest model has a larger water tank for longer off-grid adventures."

Sure, you are going to say most people in Pakistan don't have a third of a million US dollars to spend on one, and it still does not solve the agricultural issue. But it shows what is possible.

And if you go a step further, indoor agriculture can be far more water efficient.
https://inhabitat.com/?s=indoo...

Example:
"This hexagonal indoor farm grows more food in less space with 90% less water"
https://inhabitat.com/this-hex...

There are valid reasons for despair -- but they are not about lack of resources. As Julian Simon said, the human imagination is the ultimate resource.
https://www.juliansimon.com/wr...

What is a limiting resource is human greed, stupidity, ignorance, irony, recklessness, and competitiveness. Essentially, all our serious problems are social and psychological -- usually stemming from human habits tuned for scarcity producing maladaptive behavior when faced with abundance. See also the books "The Pleasure Trap" and "Supernormal Stimuli" for a start.

Also related: https://www.pop.org/overpopula...

And that is all even without "Mr. Fusion" (which may be in the cards, someday).

Or at least a much more moral and cooperative society than we have now?
What if the path we end up coming out of a singularity has a lot to do with our moral direction going into it?