Pharo 5.0 Released
pharo.org
pharo.org
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?
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.
http://amber-lang.net/index.html
... not sure how that would work with WebGL though.
But Smalltalk's so simple that writing your own transpiler isn't that hard --- I have an entirely browser-side prototype in about 2kloc:
https://github.com/davidgiven/stellation/tree/stellation5/cl...
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.
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.
Well, one of the cornerstone technologies of the JVM, HotSpot, was actually developed for a Smalltalk implementation, Strongtalk, and later adapted for Java.
Modern JavaScript has many Smalltalk features.. [starts putting on flame retardant suit].
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".
1) I swear I still have nightmares that include OnOk
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.
https://www.youtube.com/watch?v=XPGDQc5LUvE
I take advantage of Pharo Live coding to Live Code 3d graphics in Blender
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.
It is awesome!
In the end, you DO download a binary. Whether you download it with a script or not doesn't matter.
And at least the script, you can examine before running.
There's no excuse not to.
Even better: have the developers agree on a set of GPG signatures to sign their builds with. A bit more complicated...
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
I am curious what those numbers actually look like. I've always wondered about what kind of scale they operate on.
This is just a single actor.
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.
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.
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.
Just like unix!
You have to go to the "About" page to see that is has to do with Smalltalk.
I sent them an email about that. It may be intentional but I would think you would want that somewhere more prominent.
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.
didn't we decide this was a really really bad idea?