Pharo considers itself to be Smalltalk-inspired.

Maybe the most succinct explanation of what this means comes from their vision document[1]:

> What we want to say is that if there is something that can be improved but does not conform the ANSI Smalltalk, we will do it anyway.

This really does seem to be a fundamental value within the Pharo community, and it distinguishes them from the rest of the Smalltalk community. When observing the communities around Squeak or the commercial Smalltalks, I often get the impression that they view themselves as a sort of Jedi order that's trying to preserve an older, better tradition amidst a decadent modern world. The Pharo community, by contrast, actively acknowledges that Smalltalk was not perfect, and is working hard to improve many things about it, including some of the fundamentals. For example, Pharo's made active steps to make their platform more amenable to source control, and, by extension, collaboration among larger groups of people.

[1]: https://gforge.inria.fr/frs/download.php/30434/PharoVision.p...

It follows Kay's advice:

https://pbs.twimg.com/media/EMJoLicXsAA7dej?format=jpg&name=...

I know a buncha literal rocket scientists who swear by Smalltalk with a heavy bias toward the Squeak VM as bein' the best thing since sliced bread, but I honestly rarely hear about it outside those particular circles. Mostly I hear about Javascript, .NET/Mono, and Python in other programming language circles I frequent.

I guess maybe because Pharo has moved beyond Smalltalk-80, and is its own thing nowadays, just like Raket is no longer just Scheme.

But the language itself is still Smalltalk with some extra classes, right?

Smalltalk is just a simple meta-language (like Lisp and Forth). In your system, you may have the same or very similar syntax and keep some degree of compatibility but be very different in many practical aspects. For example, Pharo has Collections API very similar to Smalltalk but very different Files API or UI API. It has another class building strategy with stateful traits, slots, some syntax extensions, different source files format etc.

Kind of. At the very least you get traits, dynamic array literals and such that you don't get in "classic" Smalltalk.

I've noticed that as well - it's a bit strange given that Pharo is a fork of Squeak, which does proclaim its ST origins on its front page.

I wouldn't say Smalltalk has a bad rep nowadays, but it used to be knocked for being too expensive (the cost of ST licences back when was beyond a joke), too slow, and producing nasty-looking non-native GUIs. These have almost all been fixed.

It has basically two reasons. First, it is to prevent conflicts like: "Pharo is Smalltalk, look, it is written on its web page! How do dare you to change this? You are allowed to improve this if and only if all the other Smalltalk implementations do that too!" [exaggerating]. Pharo has many differences from standard Smalltalk (different File API, class definitions, traits, slots, small grammar changes...).

The second reason is that the general knowledge about Smalltalk is very poor, and most people only remember that it is something old and long dead. Try to sell a dead fish.

Interesting, thank you. It still seems weird to me, though. I feel Smalltalk is mostly mentioned with positive connotations (as opposed to, say Cobol) and would guess more people have heard of Smalltalk than Pharo and it would help orientation. So I was assuming something nefarious :)

Is there an overview of the differences somewhere?

I sometimes ask young programmers or people interested in old computers if they know Smalltalk and what they think of it. Try it too, you might be surprised at the results.

I don't know of any such list of differences, and I don't think it's of much use either.There is ANSI Smalltalk, which is very limited and most implementations go well beyond its scope, so you have to compare each implementation separately anyway.

> cost of ST licences back when was beyond a joke

March 7, 1988

"Smalltalk/V 286 is available now and costs $199.95"

https://books.google.com/books?id=CD8EAAAAMBAJ&pg=PA25&lpg=P...

> nasty-looking non-native GUIs

The "non-native GUI" was quite important because Smalltalk was running on MS-DOS — not on MS-Windows.

Well $200 in 1980s is something like $500 today. I don't think I own any piece of software costing that much.

That seems like an ahistorical objection.

$199 was a very reasonable price for a powerful dev tool in 1988. A lot of software at the time cost much, much more. Look up historical prices for just about any contemporaneous commercial software.

You can still argue they would have done better in the long run by marketing themselves as "Turbo Smalltalk" at $69.99. But that's a different argument than "wow that's way overpriced," which simply wasn't the case.

"The list price is $150 each for Turbo Pascal, Turbo C, and for a bundle containing both Turbo Assembler and Turbo Debugger."

p8 October 1988 https://books.google.com/books?id=WSBVAAAAMAAJ&pg=RA18-PA8

Smalltalk/V 286 included source-code debugger, bit mapped WIMP for MS-DOS, BitBlt graphics, … Turbo Pascal + debugger already cost more.

And … ?

Dec 1988, MS Word 5.0 for MS-DOS, $450.

Adobe products can cost that much on a yearly basis.

The animated screenshots on the website pretty much indicate that the Pharo GUI is still non native and looking very dated and ugly.

Most tools were modified to use Spec framework so they can use the native look (using GTK) as well as the non-native one. (plus, in future, Web and Console backends). This transition should be finished in the next release.

hm, does Pharo have native-looking GUI now?

Well, let's say "better" :-) There was a Smalltalk with a native Windows GUI (Dolphin) but the developers couldn't seem to make any money out if it.

"ParcPlace VisualWorks Smalltalk emulates all the supported operating systems GUIs in Smalltalk …

Digitalk (now ParcPlace) Visual Smalltalk uses more of the underlying operating system GUI, for better performance but at the price of only supporting a common subset of GUI controls …

IBM Smalltalk maps the Motif GUI widgets onto the underlying operating system widgets.This means you get a very rich kit to build your GUI, but the widgets operate at near native speed. You have the best of both worlds."

p87 "VisualAge for Smalltalk" 1997

http://www.redbooks.ibm.com/redbooks/4instantiations/sg24482...

aka What's the difference between Swing and SWT,

see this thread: https://news.ycombinator.com/item?id=27843214

Maybe Smalltalk sounds old like COBOL. It's hard to re-kindle interest in old tech in the eyes of new devs. It seems every generation of programmers want to have their "own" tools, even if they're worse than the previous ones.

I always had positive connotations of Smalltalk. Seemed it was talked about as if it was OOP “done right” before Java messed things up. That’s just me though.

COBOL's big problem has always been verbosity rather than age. Fortran and Lisp are older yet both have a more positive image. Fortran and Lisp are each far more succinct languages than COBOL.

(Contemporary Fortran and Lisp have evolved a lot since their initial version, but the same is true of COBOL.)

You mean like C, born in 1972?

C never really fell out of favor, though. And it's also the only available choice apart from assembler in many circumstances. But trying to revive interest in Ada, D, Sather, Prolog, etc would be a lot more difficult.

It was already out of favour in the early 80's, hence C.A.Hoare turing award speech against it in 1980, but then UNIX took over the world anyway, and the FOSS wave with GNU Manifesto helped to take it further.

Apparently people don't have any issue hanging to an OS about the same age as COBOL.

>"Apparently people don't have any issue hanging to an OS about the same age as COBOL."

Why should they? It works for many cases and has mountains of apps, tooling, libraries, hardware support and whatnot. It takes decades for the new OS/ecosystem to mature.

Same conclusion can be applied to COBOL applications.

https://www.microfocus.com/en-us/products/visual-cobol/overv...

Equating OS and its ecosystem to a single language is not very wise approach I think. In any ways you are obviously free to find fresh and shiny OS of your liking and use it.

It surely is, UNIX and C are a symbiotic relationship, born out of each other, one in 1969, the other in 1972.

I surely have, hence why I have gone back to Windows, where the focus is C++ and .NET, macOS where the focus is Objective-C and Swift (UNIX is there for historical reasons only), Android where the focus are Java/Kotlin and C++ (with Linux kernel being an implementation detail).

UNIX is not a thing anymore, nobody writes UNIX code. People use various compatibility layer or straight up use kernel abis. And they are all improving over time. So no they are not all stuck in 80s. Even linux kernel devs are willing to add rust code in the mix.

> Windows, where the focus is C++ and .NET,

Microsoft is huge organization they have multiple focuses. You seem to be mixing the kernel/userland layer and making very weird argument against UNIX(that nobody uses).

I am not familiar with COBOL is there any effort to improve COBOL?

>UNIX is not a thing anymore, nobody writes UNIX code

Please, get out of the GNU cult and check out what BSD's are doing in C.

BSDs are not just sticking to what UNIX was(let's say v7?). They are also doing their own thing.

For me it is Windows desktop and Linux servers. So far I had no business case to develop for other mobile and somehow do not feel sorry for it as I am in no rush to bend over to things like approval from App stores etc.

Smalltalk never really got substantial adoption...

Thanks Java :(

Smalltalk first appeared in 1972, and was a stable commercial product by 1980.

Java didn't hit the market until over a decade and a half later.

If you can't build adoption with a 15+ year head start, then it's not the next generation's fault. It just wasn't going to happen.

From 1980 to the late 80s or so people were struggling just to get Smalltalk to perform at reasonable speeds on microcomputer class hardware, so saying 1980 isn't really fair. And most of the research that went into getting Smalltalk (and Self) to perform well on those platforms was then used to get Java to perform.

In actuality, Smalltalk gave Java a headstart.

That said, Smalltalk just doesn't in general "play well with others"; its image based development environment, especially.

>people were struggling just to get Smalltalk to perform at reasonable speeds on microcomputer class hardware

I've heard this before, but it confuses me as apparently the majority of the systems at Xerox Parc (Window manager, word processor, etc. ) were written in Smalltalk. So how could these sophisticated GUI apps perform there but not on other platforms, was the hardware really so different?

Yes, they were drastically different. Xerox built their own systems. Look up the Dolphin and Alto, they were basically minicomputer-class systems with custom CPUs built out of 74 series and bitslice components, no single-chip microprocessor. And very expensive.

It wasn't until the mid to late 80s that microprocessor systems built around the 68k series were able to run Smalltalk 80 well. And that was with Tektronix and others spending thousands of man hours developing techniques to implement the VM well. And many of those systems were still basically dedicated to Smalltalk and cost a fortune.

The simple answer to this question is that not all software at Xerox PARC was written in Smalltalk. In fact, Smalltalk was just one out of a few different languages and programming environments that Xerox PARC used. For example, the Bravo word processor was written in BCPL (https://en.wikipedia.org/wiki/Bravo_(software)). Mesa was also developed at Xerox PARC and was commonly used as an implementation language. Interlisp was also largely developed at Xerox PARC.

> stable commercial product by 1980

This is not true. Even the Smalltalk-80 Blue Book wasn't released until 1983.

> If you can't build adoption with a 15+ year head start

Historical context is important here. FOSS etc were not nearly as prevalent as they are now, and most major development environments had a price. The main Smalltalk players probably got it wrong by pricing out expensive licensing fees. But the head start does not matter when the next thing that comes along is released for free, which is what happened with Java.

There was also the issue of "viral pricing". As the application was grown as a extension of the image, people were supposed in some schemes to not only pay for their own copy, but also for every copy of the software they wrote and shipped to customers, as it piggybacked on the original image. While free software thrived on copyleft, the first Smalltalks withered on "payleft".

Wouldn't that be payleftandright? ;)

Except it was happening, that is why gang of four book uses C++ and Smalltalk on their examples.

Had IBM kept selling Visual Age products instead of jumping into Java ship, history would have turned out much differently.

Or if the Strongtalk guys hadn't return back to Sun and basically turn a Smalltalk VM into a Java one.

JUnit was also born in Smalltalk for those not paying attention.

Java was able to ride the wave of the web's rise in popularity, particularly with their marketing of applets and the "network as the computer", with the idea of downloading Java code as needed to supplement the software you're using at the time. That and there was lots of talk about how the JVM was going to be the runtime of the future for all languages.

It's funny how Javascript and the web have turned out to be a more popular target. Nobody back in the late 90s/early 2000s would have thought that. JS was a toy and html was going away in favor of Flash or Java applets or .NET.

At any rate, timing is a really important part of gaining widespread adoption. Smalltalk was way ahead of its time in the 70s, but too early to really take advantage of networking, as their target was stand-alone personal computers.

> … too early to really take advantage of networking…

So how do you explain "HP Distributed Smalltalk" ? :-)

https://www.hpl.hp.com/hpjournal/95apr/apr95a11.pdf

How do you explain "Gemstone/S" ?

https://gemtalksystems.com/products/gs64/

language developers consistently underestimate the importance of "Algol-like syntax" in allowing mainstream adoption.

Actually language developers consistently underestimate the importance of large corporations pushing languages no matter what developers think about them.

Smalltalk lost the day IBM decided to join Sun.

https://en.wikipedia.org/wiki/VisualAge

> VisualAge Micro Edition, which supports development of embedded Java applications and cross system development, is a reimplementation of the IDE in Java. This version of VisualAge morphed into the Eclipse Framework.

some reading from that era: https://techmonitor.ai/technology/the_parcplace_digitalk_mer...

Java was free and open source and based on files rather than an image.

Free as in "free beer", but not open source until much, much later.

Interestingly enough the JVM hotspot compiler was done by Smalltalkers (checkout Strongtalk)

Java was free. (And marketed by a large organization.)

It's true, and a huge point. Until Squeak came along I as a hobbyist -- who was really interested in Smaltalk -- simply couldn't get my hands on a Smalltalk (other than GNU Smalltalk which doesn't count). All through the 80s and early 90s I salivated at screenshots and descriptions of it, but never got to play with it.

That said, When I did finally get Squeak, I found it pretty neat, but it just never blew me away like I thought it would. I just didn't have anything to do with it.

Java was an answer to C++, not to Smalltalk, which had already been dead for a while by the time Java started taking off.

It's more accurate to say it hadn't really come alive yet.

But still as late as 96, 97, 98 you could still find job postings advertising for Smalltalk developers. I know, because early-20s me really wanted to do be doing that, but I wasn't qualified.

Within a few years Smalltalk had vanished from the few industry pockets it had, and was replaced by Java in most cases.

Fun fact: I know one company in Russia which built aerospace-grade product in Smalltalk as late as 2010s. I don't know, maybe they still use it right now, maybe it had been replaced, all my friends in this company changed job in last 10 years.

"Ubiquitous Applications: Embedded Systems to Mainframe" (pdf)

https://www.davethomas.net/papers/ubiquitous1995.pdf

Sure. How many new devs do you see writing C?

How do you think UNIX clones, GNU utilities and IoT devices are kept up to date?

Lots in the embedded space.

Check out https://consortium.pharo.org/ - you will see:

"A clean, innovative, open-source, Smalltalk-inspired environment."

If you look at the home page for Racket, you won't see the word "Scheme" anywhere.

Same thing, basically: neither language wants to be beholden to what's come before, nor to their peers.

It is mostly marketing bullshit.

Pharo IS Smalltalk in the same way Skoda is Volkswagen