Thanks. Great insight: "Having to use your military gets expensive fast. Having a military so powerful that nobody challenges it is less expensive than a cheaper military that gets challenged, thus having to be used."

Neat idea about the personal rapid transit system! Might work for packages too.

Yo're right about oil and electricity. Other than fuel for cars, oil vs. energy efficiency is (or was) a bigger issue for home heating. With enough insulation of the right kind (and air-to-air heat exchangers), you don't need a furnace at all.
"No Furnaces but Heat Aplenty in âPassive Housesâ(TM)
https://www.nytimes.com/2008/1...

Again, if people paid the true cost of oil, people would have switched away from home oil heat a long time ago.

Thanks for the reply. Totally agree this is a shifting situation and I am linking to older data. And the essay I linked to I wrote was from 2009. And also totally agree that the US military has many missions (arguably too many) all over the place so it can be hard to allocate costs to a specific mission (especially the costs of creating and maintaining military infrastructure like an aircraft carrier or submarine or various bases or training costs and so on).

That said, the link you supplied has a title "Saudi Arabia has paid $500M toward the cost of US troops in country". That's probably like a week or less of fuel costs for the US military overall? Don't know specific to that deployment.

Granted, this is from 2010, but consider the magnitude of the numbers here:
https://www.sciencedirect.com/...
"This paper presents the first estimate of United States military cost for Persian Gulf force (CPGfp) derived entirely by a quantitative method. An activity-based cost (ABC) model uses geographic distribution of aircraft carriers as a proxy allocator of Department of Defense (DoD) baseline cost to regional operations. Allocation follows simply from DoD data that since 1990 no less than one aircraft carrier has been continuously on-station in the Persian Gulf; that eight are required to keep one on-station there; that the Navy has had eleven-fifteen carriers since 1990; and that Army and Air Force units are virtually never deployed to combat operations without Navy units. For 1976-2007 CPGfp is estimated to be $6.8Ã--10^12 and for 2007 $0.5Ã--10^12 (2008$). This substantial military investment is not a remedy for the market failure at the heart of regional security problem, which is oil market power. When CPGfp is added to economic losses attributed to market power in another recent study (Greene, 2010), the severity of this market failure becomes more apparent."

Those values are $6.8 trillion dollars over that 1976-2007 time period and then $0.5 trillion in one year. $500 million from Saudi Arabia is 1/1000 of $500 billion. Just a token amount. Even if that deployment cost was now just 10% of what it was, it would still be a huge number. (And of course, that is just the monetary costs, not the personal costs.)

As the authors suggest, and others like Amory Lovins in Brittle Power, using fossil fuels without including the cost of defense in the up-front at-the-pump cost leads to a market failure. Capitalism can't work well unless purchases reflect the true costs.

In the book Brittle Power (or was it a related book like Energy, Vulnerability, and War?) it was suggested that the cost of just one year or so of the Persian Gulf Deployment Force in the 1980s would have been enough if invested in energy efficiency and renewables to eliminate the need for foreign oil.

And that is part of why Amory Lovins and others essentially argue locally-produced renewables and energy efficiency have been cheaper than fossil fuels -- all things considered -- since the 1970s. It's just a market failure that benefits some special interests and costs the US taxpayer.

That situation is shifting, agreed, but where are the apologies for the decades of bad policy? Or at least, where is the discussion and learning about such things so it does not happen again? The shift to renewables like solar PV seems more to do with a bunch of dedicated people chipping away for decades at making renewables cheaper than fossil fuels even given a tilted playing vastly in favor of fossil fuels.

I am all for spending money on national security. The questions is how to spend our money effectively to achieve real security? As I suggest here:
https://pdfernhout.net/recogni...
"We the people need to redefine security in a sustainable and resilient way. Much current US military doctrine is based around unilateral security ("I'm safe because you are nervous") and extrinsic security ("I'm safe despite long supply lines because I have a bunch of soldiers to defend them"), which both lead to expensive arms races. We need as a society to move to other paradigms like Morton Deutsch's mutual security ("We're all looking out for each other's safety") and Amory Lovin's intrinsic security ("Our redundant decentralized local systems can take a lot of pounding whether from storm, earthquake, or bombs and would still would keep working")."

Of course, a major reason why the Ukraine issue is such a big deal is that Europe is (or was) dependent on Russia for fossil fuel energy. See also:
https://en.wikipedia.org/wiki/...
"Brittle Power: Energy Strategy for National Security is a 1982 book by Amory B. Lovins and L. Hunter Lovins, prepared originally as a Pentagon study and re-released in 2001 following the September 11 attacks. The book argues that the U.S. domestic energy infrastructure is very vulnerable to disruption, whether by accident or malice, often even more so than US technology is vulnerable to disruption of the imported oil supply. According to the authors, a resilient energy system is feasible, costs less, works better, and is favoured in the market, but is rejected by U.S. policy. In the preface to the 2001 edition, Lovins explains that these themes are still very current."

Granted, some policies have been shifting over the past twenty years. But still relatively little when you consider how much of the US military is involved with defending oil supply lines and what a huge costs that is every year. One estimate (which includes some other overly high numbers):
https://www.energyandcapital.c...
"Due to the enormous military cost of protecting Persian Gulf imports, the hidden cost of oil from that region amounts to $7.41 per gallon of gasoline. The cheapest gas out in my part of the Bay Area is $3.11 a gallon for regular. Add them together, and the true cost of my gas is probably around $10.52 a gallon."

And also from there:
"One 1998 study by the International Center for Technology Assessment (CTA) looked at petroleum industry subsidies, including the percentage depletion allowance and tax-funded programs that directly subsidize oil production and consumption, among other things.
      It assessed up to $17.8 billion per year in tax subsidies, plus government program subsidies (such as vehicle R&D programs, highway construction, and environmental cleanup) of between $38 billion and $114.6 billion per year.
      They pegged health and social costs at an additional $231.7 billion to $942.9 billion per year, counting factors such as health issues due to pollution, loss of crop yields, and so on.
      As for related costs, such as the direct and indirect costs of traffic delays, traffic accidents, subsidized parking and the like, they counted another $191.4 billion to $474.1 billion per year.
      Adjusting the estimates to 2006 dollars and rounding, that makes a total of between $68 and $161 billion in government subsidies, between $283 billion and $1,152 billion in health and social costs, and between $233 billion and $579 billion in related costs.
      All told, $584 billion on the low side, $1.9 trillion on the high side."

So there is a lot of money to be saved if even a fraction of that estimate is true. And presumably some of those savings would end up going back to the individual tax payer and insurance payer.

Air pollution presumably must drive up insurance premiums for everyone, but granted that is a different issue than insurance savings from less car accidents.

And it would be a fair criticism to suggest that even if defense of oil supplies was a non-issue that some people would invent other justifications for a huge US military budget.

Thanks for the reply. And a valid criticism of my point to support your rebuttal includes that in our current economic system, it one good is made free people tend to waste it and also resell it for parts or repurpose it to meet other needs that cost money. An example of that is how in the USA "free" (to the poor user on Medicaid, paid for by tax dollars) emergency rooms are pushed into service for shelter, meals, and primary care. The biggest thing that might derail my suggestion then could be, say, people reselling parts from such "free" cars to use in making other expensive paid-for devices -- or people welding cars together to build housing, or people pulling out the batteries to use in home solar power systems, or stuff like that. But arguably this anomaly (it is costing taxpayers more that such cars are not free, even given second order effects) suggests a need to revise many economic and political assumptions in an age of abundant technology.

https://www.mit.edu/people/dpo...
"So who made the machines? That's who we want to contact."
"They made the machines. That's what I'm trying to tell you. Meat made the machines."
"That's ridiculous. How can meat make a machine? You're asking me to believe in sentient meat. ..."

While people can certainly debate whether a particular entity is conscious or has feelings, it seems likely that the substrate may not matter as far as sentience and feelings.

The more pressing question is whether enslaved AI wielded by oligarchs and giant corporations owned by a relatively small percent of the population is compatible with a lightly-regulated capitalistic system that does little to prevent wealth concentration. See also Marshal Brain's Manna and Robotic Nation/Freedom writings:
https://marshallbrain.com/mann...
https://marshallbrain.com/robo...

Or things I have written years ago:
https://pdfernhout.net/beyond-...
"This article explores the issue of a "Jobless Recovery" mainly from a heterodox economic perspective. It emphasizes the implications of ideas by Marshall Brain and others that improvements in robotics, automation, design, and voluntary social networks are fundamentally changing the structure of the economic landscape. It outlines towards the end four major alternatives to mainstream economic practice (a basic income, a gift economy, stronger local subsistence economies, and resource-based planning). These alternatives could be used in combination to address what, even as far back as 1964, has been described as a breaking "income-through-jobs link". This link between jobs and income is breaking because of the declining value of most paid human labor relative to capital investments in automation and better design. Or, as is now the case, the value of paid human labor like at some newspapers or universities is also declining relative to the output of voluntary social networks such as for digital content production (like represented by this document). It is suggested that we will need to fundamentally reevaluate our economic theories and practices to adjust to these new realities emerging from exponential trends in technology and society."

Including other writings also about the irony of people wielding tools of abundance like AI and robotics but still having a scarcity mindset (like using AI and robotics to fight over what humans are forced to do what labor to what oligarch's benefit by the threat of starvation).

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.