I would say the same thing (or more exactly, the dual) from a Smalltalk perspective: I just want to send a message to an object, I shouldn't have to figure out what function to call or what to parenthesize. The problem people get into with OO (particularly Java, C#, C++) is thinking in terms of method-function calls rather than message sends.

Although I do like Lisp generics - I did a bunch of programming in rscheme many years ago, and really liked it.

Pharo, like its siblings Cuis, Squeak, and NewSpeak runs on a VM called Open Smalltalk. It is written in a stylized version of Smalltalk so can be debugged with the tandard Smalltalk tools (i.e. you can have the modified VM you're working on load and run an image - but your VM is running in a debugger!)

Then when you're happy with your revised VM, you can spit out portable C code, compile it, and BAM you've got a production VM! Most plug-ins and primitives are also written in the Smalltalk subset (called SLANG), so they will likely be similarly portable.

There is also an FFI for interfacing beyond the standard model.

Here is another web application made with http://pharojs.org which runs on Pharo https://covid.cs.ryerson.ca/compare/

Development is entirely via the most integrated GUI you've ever experienced. It runs on MacOS, Windows, and Linux.

For deployment, you can run it headless.

You can also deploy as Javascript for Node/Browsers via a tool called PharoJS (http://pharojs.org - full disclosure, I'm one of the principals of PharoJS), but it's a work in progress (with a Slack workspace to support it).

GNU Smalltalk can deploy to a standard executable, so you could do most development in Pharo, and then switch to GNU Smalltalk, but you'd lose the fabulous IDE.

One of the key words in that statement was "actively developed". Cincom, Instantiations, and GemTalk have some great people working on them, but Pharo7 had 75 different people contributing - including probably almost as many full-time people as the commercial developers (maybe more).

The small size of methods is a feature, not a bug :-).

And this partly explains why the lack of [your favourite editor] bindings isn't so important. You don't typically spend as much time as you're used to typing in code - and make progress faster as a result - counter-intuitive as that may sound. The integration and the debugger are most of the reason why.

It is an alien world.... but a better one by most measures.

I come from Emacs (20+ years when I first encountered the Smalltalk IDE), and find aspects of code editing irritating sometimes, but the overall value of the IDE more than pays for that irritation.

One of the coolest things is TDD carried to an extreme level. I build my test, and it fails because there's no such method, so I get a debug window and tell it to create the method... then I fill in the contents and click proceed... and picks up where it left off! It either works, or I'm back in a debug window fixing what failed. Total time from thinking of a test to working code, often less than 5-10 minutes.