Today, there are hundreds of programming languages competing for attention. It is in your interest to put an example front and center of why one should spend time looking into yet another programming language.
[source code] -> [interpreter] -> [running program]
[running program] + [auto persistence] + [editing tools]
The syntax of Smalltlak is interesting (can be seen here https://en.wikipedia.org/wiki/Smalltalk#Syntax). But the more interesting aspects of the experience are the live editing, working with network of objects, hybrid text/non-text ways of modifying these objects, etc.
How do you use TDD when coding like this?
There were some utilities that let you run the tests at the push of a button.
You first extend the environment with tests, then add the code to make them green. All without ever having to restart the "program".
Pharo: https://youtu.be/ymITEeAOtEA
Cinecom Smalltalk: https://youtu.be/mXoxfmcDDJM
Basically you write a test first, say it calls an undefined method `x.somemethod()`. You push a button to run the test, as soon as the method call fails, the environment shows you a popup which lets you define the method right then and there, while you have all the details of the suspended execution. You can write the method and the 'resume' the execution from where it excepted.
http://files.pharo.org/books-pdfs/updated-pharo-by-example/2...
There are pictures :-)
Slightly longer discussion here: https://pharo.fogbugz.com/default.asp?W78
Really, not much different than any interpreted language, where you do source + runtime; the image just replaces the source.
For MS Windows based Dolphin Smalltalk -- "The Lagoon Deployment Wizard strips out redundant components from your image and shrinks your code down to a tight, single click EXE file. Alternatively, you can choose to additively compose your application by building it up from the raw Dolphin boot image."
So, based on these slides about Pharo 6[0], it seems that they use multiple things. First, they have a tool called Epicea, which is a more modern way of tracking changes to an image[1]. Then, for git integration, they have a bunch of tools at pharo-vcs, specifically Iceberg[2].
[0] https://www.slideshare.net/pharoproject/pharo-6
[1] http://smalltalkhub.com/#!/~MartinDias/Epicea
[2] https://github.com/pharo-vcs, https://github.com/pharo-vcs/iceberg
Typically with Smalltalk you would have an Image live on and on and maybe forget how to create it from scratch. And depending on your audience, you may have wanted to strip out development tools, something like this old example for Squeak... http://squeak.preeminent.org/tut2007/html/205.html
Pharo has put a lot of effort into "bootstrapping" the Image via CI to address this weakness of Image based systems. So you only need to load the parts you want in a reproducible way.
" this sends a message to the transcript "
Transcript show: 'hello world '.
" compute 10 factorial and send the result to the Transcript "
Transcript show: 10 factorial.
" now, try this: "
Transcript show: 100 factorial.
" a loop (the timesRepeat-method evaluates its argument n-times)"
10 timesRepeat: [
Transcript show:'hello'.
Transcript cr.
].
" another loop "
1 to: 10 do:[ :i |
Transcript show:i.
Transcript show:' '.
Transcript show:i sqt.
Transcript cr.
].
" looping over a collection "
#('a' 'b' 'c' ) do:[:each |
Transcript show: each.
Transcript cr.
].Now, your program also has state. If you want, you can also save the state of the program (i.e. by using the "save-lisp-and-die" command). This can create large files, because this allows you not only to quickly "run" the program again, but to also run it with the same state that it had when you did the save.
The runtime makes possible having the condition-restart system, and the full power of macros (your program can compile lisp code at runtime if needed, thanks to the runtime.)
From what I understand, none of this applies to Smalltalk. You always modify code on the fly, so you may end up with properties which exists, but no current code ever sets them. Or your program ends up in the invalid state, and you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete?
Repeat daily or weekly as you please.
> You always modify code on the fly
Since back in the '70s when Smalltalk was being created at Xerox PARC and used there for experimental systems development, changes were automagically recorded in a changes .cha text file.
For more information on the primitive techniques from back in those days see -- "Managing the Evolution of Smalltalk-80 Systems" in Smalltalk-80: Bits of History, Words of Advice
http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOf...
Really? So we're back to "MyImage.img.bak.2.old.works", "MyImage.img.bak.3.works", "MyImage.img.bak.2.test"?
Now that is an experience I do not want to ever have to experience again.
No, that's a bizarre suggestion you just invented, it has nothing to do with what I wrote.
So it doesn't get lost in the mass of other comments, here again is some info on Pharo's bootstrap process... http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...
That's what I loved best about Smalltalk. You could just hard quit out of the image, then go back to the Change Log and replay all but the last few changes. If you save off an image every day or so, you're always back in minutes, no matter how dangerously you've been coding.
There are a variety of utilities which let you load code quickly. Most often, deployment was done using one of these loading onto a clean or a stripped image. You can certainly control changes to your environment. In fact, I'd say you can often control them more easily than in other environments.
you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete?
The Change Log makes it very easy to figure that out. All of your ad-hoc "command-line" (do-it) state changes to the image are recorded there as well.
Somewhat related, you can use unit tests of as-yet unimplemented functionality as a jumping-off point for live-coding your way towards the right implementation, with the debugger acting as a combined code editor and REPL (since the formal parameter names in the code will have real, evaluatable values behind them - as supplied by the test case).
Were I a major Test Driven Development adherent, I might claim that this is the non-cargo-cult way of doing TDD.
http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...
Like this clock[0]:
Time now asValueHolder in: [ :clock |
[ [
1 second asDelay wait.
clock value: Time now ] repeat ] fork.
clock inspect ]
There's no excuse for not having any examples of a programming language on that programming language's home page. Here are some languages that do it right:
https://www.rust-lang.org/en-US/
Notice there at least one example (often executable!) on the home page of each site.
I'm actually pleasantly surprised how well all those sites do. Most smaller programming languages get this bit horribly wrong.
I see examples on their home page.
Then there is a textual example consisting of two lines of Posix shell, embedded in which is indeed a tiny Pharo program in a string.
The parent's point mostly stands.
(Oh, and there is a frickin' popup for a frickin' email newsletter hiding the content.)
Why would you copy and paste code before you'd done anything more than glance at a language home page?
Perhaps the better comparison is with some other languge IDE:
I haven't been able to find a clear statement of language differences between Pharo and other Smalltalks. The closest thing I've come across is this statement of intent:
"We want to stress the fact that Pharo will certainly derive from ANSI and other Smalltalks. We will not change for the sake of change. 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."
Perhaps a Pharo expert can clarify?
However one novel thing Pharo has added is Slots... http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.653...
2. Image that you can download (30Mb) and test easily. The installation consists in unzipping the damn thing, that's all you need to run Pharo right away. If you don't like it, you delete the folder. That's the un-install procedure.
3. If you actually do test it for yourself, you'll find plenty of examples in the image itself, ready to copy/paste... OR NOT! Because actually, most of the times you don't even have to copy/paste; you can just select, right click and execute those examples.
The article might be a little too dithyrambic, but your criticism on this particular point shows more your own laziness than anything. Where is the adventurous programmer that bravely goes off the beaten tracks in order to discover new exciting things?
Over the last 15 years or so, I have regularly played around with Squeak and Pharo, and I have not found this to be the case. I mean, yes, there is code, but that's like saying "Oh, you wanna learn C? Here is the Linux source code."
Maybe I just didn't manage to find these great examples because the Pharo community's approach is "it's there, but I won't tell you where exactly; if you can't find it yourself, you are lazy/dumb/not a real programmer".
As such, C++, Java and C#, which constitute a significant chunk of OO programming, are probably better thought of as descended from Simula (and C).
There's a clearer lineage to the likes of Ruby and Objective-C, and to a lesser extent Javascript and Python.
I would definitely concur regarding looking into it, it definitely makes you think about things in a different way.
Whether or not it makes one a better programmer, I can't say. I only programmed professionally in it for a relatively brief time and it was a hugely frustrating experience. I was glad to get out of it.
In the sense that it made me understand that a programming environment has a big influence on how well a codebase can scale then, yes, I learnt loads. But that was because it really wasn't very good at scaling without an awful lot of TLC. I moved onto a Java application which was bliss by comparison (ironically, given its reputation for classpath hell etc).
This was some years ago mind so the state of the art of Smalltalk has, I'm sure, moved on.
True, what is often called object oriented is often more about classes and inheritance, and less about (instantiated) objects communicating via messages.
It's really rather odd how Smalltalk, Strongtalk and Self could be major influences behind the jvm, jre and java - when you look at were java ended up...
[ed: on the other hand if you start with Self and add Algol syntax you get javascript - maybe it makes sense that Strongtalk and Algol makes java...]
C# is a Java clone so I need only address your Java misstatement, Java was far more influenced by Objective C and Smalltalk than by C++ as far as OO goes; it looked to C++ only for syntax. Java is semantically a direct descendant of Smalltalk and was inspired directly by Smalltalk as both of its creators knew Smalltalk and Objective C (another Smalltalk derivative). [1] Direct from the co-creator of java not to mention that Gosling himself was a Smalltalker.
So no, what we know as modern OO came directly from Smalltalk.
The difference between the two is that Smalltalk methods semantics are message passing. In Simula, method calls are just that, function calls generalized to have a receiver. And Java follows that pattern.
If Java was a direct descendant of Smalltalk, it would look a lot different. For one thing, it would have a lot less syntax baked into the language, and a lot more closures, from the get go.
And I quote..
> When I left Sun to go to NeXT, I thought Objective-C was the coolest thing since sliced bread, and I hated C++. So, naturally when I stayed to start the eventually) Java project, Obj-C had a big influence. James Gosling, being much older than I was, he had lots of experience with SmallTalk and Simula68, which we also borrowed from liberally.
A relatively simple mental exercise to prove the point is to look at various Simula and Smalltalk constructs, and see how well they map to Java (1.0) constructs. For Simula, you'll find a nearly 1:1 correspondence on syntax alone, with nested functions being the primary pain point. With Smalltalk, you'd stumble as soon as you run into the first block.
Objective-C is message-passing, Java and C++ are not.
To start Java's interfaces are loosey based on Objective-C protocols.
As for the rest,
https://i.pinimg.com/564x/b9/45/71/b9457106d7a5d602a2923597d...
https://ccrma.stanford.edu/courses/250a-fall-2005/docs/Compu...
Not really, I just assumed the one I posted was trying to highlight syntax similarity. The ones you posted are just as terse, there's no way I can figure out if the Lisp arrow to Java in your first link is something about the type system or how it handles reference or the like