For anyone interested, there is a MOOC for Pharo going on here right now : https://www.fun-mooc.fr/courses/inria/41010/session01/ . The video are in French with English subtitle, but all the contents are in dual language French/English.
I'm curious, what do people use Smalltalk/Pharo for?
I've seen a handful of demos and been blown away (especially the debugging tools), but am I wrong in assuming it's mostly for educational purposes? Is there a "real world smalltalk" that I'm missing?
It's useful in education, but it also was competitive in what became the Java market. Weirdly, the world bought into a relatively static language when it had the option to go for the extremely dynamic and flexible SmallTalk instead. I have always thought it an extreme shame that the man-centuries (man-millennia?) sunk into improving the JVM weren't instead spent improving an open-source SmallTalk instead.
Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control?
For a long time, Smalltalk and its brethren were terrible at sharing code; you had a bunch of stuff in an environment, and importing and exporting stuff was a nightmare. Has this changed?
Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run".
I'd be happy to be wrong about any of this. Smalltalk is my favorite language (that I'll never ship a product in) . . . but when you look at a couple of my recent projects, which are PHP + JavaScript + WebGL that interpret and let you look at a bunch of back-end statistics, I'd sure like to be using something better.
> Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control?
Possibly. But you may be looking at history through modern lenses. Java was released in mid 90s, and the open source VC tools of the day were RCS and CVS. SVN came in 2000. The explosive growth of DVCS came after that.
> Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run".
A Smalltalk image is similar to a bunch of Java packages bundled into a jar/war/ear/*ar file. You can run any number of OS processes, each a Smalltalk VM running an image, on a single computer. You can scale out by running Smalltalk VMs across multiple computers. Just as with Java and JVMs.
Performance is adequate, but not great. Method lookup is the dominating factor, because you need different code paths based on the type of the receiver (number, string, object...)
Of course, writing the libraries is the bulk of the work.
> sunk into improving the JVM weren't instead spent improving an open-source SmallTalk instead.
Well, one of the cornerstone technologies of the JVM, HotSpot, was actually developed for a Smalltalk implementation, Strongtalk, and later adapted for Java.
The best parts of JavaScript are where the Lisp and Smalltalk heritage is apparent.
The worst parts are where a PHB told Brandon Eich "we're going to call it Javascript, make it more like Java", and where the PHB told him "I don't care if it's done, we need to ship it".
Self was definitely an influence. It's where the prototype inheritance came from. Not sure that's a good thing. Smalltalk was more traditional in its inheritance model even if it was all duck typing.
For UI, prototype inheritance was nicer on the Newton (NewtonScript) than on the several of the class-based stuff I played with[1]. Morphic include in Pharo / Squeak is based on Self's UI. I actually like a prototype (other than performance issues) more than class-based. It has a much nicer, lighter feel for me. I just don't think Javascript is the best at it. I loved programming NewtonScript other than its clunky syntax in places. NeXTSTEP got around a lot of crappy class-based behavior by having live objects.
1) I swear I still have nightmares that include OnOk
Smalltalk was started to be adopted at the enterprise level when Sun unleashed Java into the world.
I used Smalltalk/V at the university around 1995, and since my focus was programming languages, started devouring all the Xerox PARC books right away.
IBM used to sell VisualAge for Smalltalk, which was reborn as Eclipse. To this day, Eclipse still has a Smalltalk like class navigation when you switch to "Java Browser" perspective.
The first commercial collections for Java in the late 90's, tended to either be influenced by STL's design or Smalltalk's.
The majority of Smalltalk vendors ended up switching to Java.
It didn't help that Sun brought in the startup that was trying to improve Smalltalk performance, to create Hotspot instead.
It's great to see Pharo improving, it has tremendous potential.
I think the groundbreaking changes in terms of immediate
appeal will come in Pharo 6 (new widgets Brick/Bloc, faster graphics with SDL, better font rendering and so on) which will surely attract lots of newcomers to the environment.
To any Pharo devs that may be reading this, there is this snippet in http://www.pharo.org :
$ curl get.pharo.org | bash
In an age where nation states are fighting for control and
MITM attacks are more prevalent than one would think, it does you no favors to promote snippets like the one I pasted. Please consider what the implications are and come up with a better way. I also noticed that you offer no signatures for the Pharo archives or downloads over HTTPS even. You do not need the bad publicity that will come with a security disaster stemming from these issues.
> five minutes to set up a LetsEncrypt certificate
Did you read the LE client source code? Did you verify or set up so that files and directories are with least privilege? All that in five minutes?
Or are you suggesting that the Pharo webmaster git clones certbot onto their web server system and just runs the commands according to the LE getting started guide? That's not a qualitative step-up from "curl ... | bash".
I use acme-tiny. It's a nice short Python script that mostly shells out to OpenSSL. I went through the source code rather carefully, tested it, and then mucked around with file/directory permissions when using it for real. Took me like 12 minutes at least.
I'm kidding about the 12 minutes part, obviously. :-D
An example (QUANTUM) that became public with Snowden revelations, that is also very old by now (so who knows what their current capabilities are) gives NSA the ability to on-demand MITM ANYONE they wish with a minimum of effort.
Smalltalk has been incredibly frustrating in that is one of the most fun languages ever, but makes it incredibly hard to actually produce a standalone program.
Programming in Smalltalk environments compared to regular ones is like gardening, maybe, growing stuff organically as opposed to working in a factory. But I somehow never managed to rip an appplication out of its environment.
That was my frustration. I made a game in SmallTalk at one point but there was no way to distribute it to people without giving them my whole image. I just wanted a simple .exe to hand out.
PS: You should be a bit more flexible. If you insist on programming, say, in Haskell the same way you program in C, all you'll do is hurt yourself.
Same goes when you try to use an image-based environment like a standard IDE or toolchain.
Just look at how Pharo itself is distributed: it's a zip file you can uncompress and run right on your desktop. On Windows, it just works out of the box without even running an installer.
> On Windows, it just works out of the box without even running an installer.
You say this as if it's a good thing, it's not. It's a bad thing on Windows. It means the software will not be able to use a lot of facilities on the Windows platform. It's also a hassle for users who need to pick up a target directory, remember it's there, create a shortcut manually, etc...
There are reasons why modern operating systems use installers
As for the article, it is incredibly dated and wrong on many fronts about how people ship software on Windows.
I'll just address one point:
> Unfortunately is not a very flexible way to package anything into a single compiled executable.
It is hard to ship an update - since you have to redeploy the executable anytime your program
changes.
Installing and updating executables on Windows is a solved problem. Solved. It's so easy to deploy patches and even have software self update that nobody thinks about it any more. The fact that Pharo is reinventing its own process under the cover of doing it better (which they don't, it's worse by all standards) is precisely the problem that I was referring to: Pharo (and Smalltalk people in general) still don't understand how to deploy software on modern computers.
The main reason is because, while Pharo is obviously heavily inspired by (and, in fact, a fork of) Smalltalk, it's not trying to stay Smalltalk-80 compatible. Think of Racket: Racket started life as DrScheme, but as the goals of Racket gradually drifted away from being "just" a Scheme dialect, they decided to just call the entire language Racket to avoid confusion.
Pharo's doing the same thing. For the moment, the changes are relatively minor--new GUI hierarchy, support for method lambdas, some cleanup of the class hierarchy, support for traits alongside classes, and so on--but the team wants the flexibility to break compatibility more thoroughly as time goes on.
In other words, it's not about Pharo not wanting to give credit where it's due, but rather about not setting false expectations.
Maybe to them it is. Smalltalk has been around forever. We've all heard about it, but very few of us have done anything with it so maybe to too many it has been relegated to the "that's cool, but I'll probably never use it" bin.
there is a new compiler this release and a new vm. Over 200 new features over 2000 fixed bugs and a ton of new documentation (my department). Busy Busy :)
Not saying you are wrong (you are not, you technically can download the script in one step, read it and then feed the local copy to bash) but someone posted a proof of concept a couple months ago that used user agent sniffing to potentially fool people into reading one thing and running another if they used the browser to read the source but curl to pipe the script into bash.
