Everyone sees the world through their own eyes, filtered by what their past and what know.
A peculiar perspective of Smalltalk programmers is to consider that "code in files is dead code". External tools are needed to query it, modify it, compile it.
In Pharo you can evaluate...
Integer methods first inspect
and in different tabs you can see this method's source code, the AST, the compiled bytecode.
Or in a similar way we can look at how PLUS is implemented by evaluating
(Integer>>#+) inspect
Or look at all the methods that use PLUS
#+ senders inspect
Within Smalltalk, classes and methods are themselves objects. You can operate on them like any other object. They are ALIVE!!! AHAhahaHaaaaa :)
You can also load Metacello configurations from the command line per last snippet of [1]
Metacello provides version pinning.
You might consider every Smalltalk Image to be a container.
Its like a uni sports tour. What happens in the Image, stays in the Image ;)
> * Some languages come with support for interactive REPL -- you can evaluate arbitrary commands inside running processes.
As you say, Smalltalk has a super REPL.
How easy is it for other REPLs to modify and query the code of the system?
For example in Pharo if I define a class and methods like this...
> What can smalltalk offer? Obviously it has great REPL. Anything else?
> What is the cool new 'software development process' feature that you are referring to?
For me, the greatest thing about Smalltalk is the very tight code/compile/debug loop.
Indeed, its common to "code from within the debugger" where you compile your first method calling methods that don't exist yet,
and when execution hits them, the system asks you to define that method and then continues execution.
This is great for protoyping and (purely subjective) I feel program architecture ends up being closer to how a "user" of the library would like it layered.
Now this is not "cool and new" for Smalltalk. It has had this since 1980. But its a "blub" [4] feature that not many people get exposed to.
The saying goes "the only languages worth learning are those that change how you think about programming".
And for me, this is what changed how I thought about programming.
[4] http://paulgraham.com/avg.html
> For example, I have found exactly one sentence about version control and sharing in the article you have linked: "We may even see Pharo 7, which promises a Git-integration tool called Iceberg for source code version control." . Is this what you wanted to show me? Because my takeaway is that the only way to work on Smalltalk software as a team is to use file-based tools (git). I see no improvements in software development process here.
Git interaction is not what Pharo is selling a better development process.
But its an important thing for the Pharo community to make it easier to participate in polygot projects.
Historically one of the common criticisms that Smalltalk was insular and didn't play well with others.
Monticello had three-way merge for a long time so we were able to live a long time without external version control.
Monticello works well for small teams, but doesn't scale well to Internet size teams.
We've now recognized those other advances and fixing those reasons "not to use Pharo."
The advantage of Pharo is not so much inter-developer processes. Its simliar to other languages, especially now we are integrating.
Pharo's benefit is improving the "flow" of moving thoughts into code.
The very tight code/compile/debug loop and minimal syntax reduces the friction of coding.
I heard of a few projects where clients initially resistant to the use of "new" technology like Pharo,
but accepted using Pharo to prototype with - but in the end were very happy to leave it all in Pharo.
> The other commenter mentioned Monticello and Smalltalk Hub. Ok, this looks like a decent version control system.
> It is interesting how without files, you have to add a prefix to a name of every class and tag each function which you want checked in. Still, I could not find which features it has that git does not.
This prefixing of class names has nothing to do with sans-files.
It is just that Pharo does not have namespaces.
This does leave the potential for name classes, but in practice the prefixing works well.
btw, as another minor demonstration of Pharo REPL, you can change every reference to the class in one line like this...
> criticisms I've seen of OOP, that it too easily results in overly-complex software
With respect to other languages, many don't do OOP well ;]
Indeed in the OP video Alan Kay said "Object oriented programming never made it outside of Xerox Parc - only the term did" (1:06:40)
> Smalltalk encourages an explosion of complexity
Smalltalk is a fantastic prototyping language. Its easy to explore a new domain and get something working fast. Such an exploratory process can lead to overly-complex software. I guess the trick is to have the discipline to go back and do the "science" to distil and refactor.
Having said that, coming to Pharo from a C programming background, one area that for "a while" I found over complex was use of the visitor pattern and double-delegation. This was facilitated by Smalltalk's duck typing over static typing. It took me a while "to get my eye in." But then... the only programming languages worth learning are those that change the way you think about programming.
Just because it isn't what Alan Kay intended doesn't make what emerged not Object orientated programming. Usage defines the meaning of words, and when people use object orientated programing, they do mean as implemented in languages which did escape Xerox Parc...
My point was there it isn't necessarily particular imperative to move towards a language which has a pure implementation of object-orientated programming on a mere 'Alan Kay wasn't thinking of this' point, especially given in the real world we have concrete evidence that such a language has never escaped an academic setting.
That's given you a false impression. The .st file is only an the export/transfer format to be loaded into another Smalltalk system. Smalltalk code is best read using its System Browser. Think of opening a .docx file in Notepad, and how clean you think it looks compared to editing the file from within MS Word.
Yet not being able to use your favourite text editor is one of the common arguments some people use against Smalltalk, but perhaps there's also an element of them trying cast something "new" (Smalltalk) to them, back into what they already know (as Alan Kay touches on after 1:04:00 in the OP video link)
Noel Rappin has written a few books about Ruby & Javascript. He provides an introduction to Smalltalk in "MountainWest RubyConf 2014 - But Really, You Should Learn Smalltalk"
> That was likely Squeak, not Pharo. Pharo has muted a lot of the UI colours to be more appropriate for a business environment.
I've used both. Yes, Pharo is considerably more professional-looking, but it's still rather ugly and alien (as in, it looks very odd when juxtaposed with the other applications running on the host system).
> Avdi Grimm has written a few books about Ruby. He records his experience trying Pharo in "I make you hate Ruby in 7 minutes"
Does it normally take 7 minutes to write "hello world" in Pharo? If so, that doesn't sound productive to me at all. Really, the only thing I saw in that video that made me feel envious in the least was the exemplary method search. But you don't need an environment like that to have exemplary search; I've been told Hoogle offers something like it for Haskell, for example.
Apart from that, I was pretty unimpressed with most of what I saw in that video, to be honest. The class browsing didn't seem particularly different from what Eclipse has to offer (which should be unsurprising given Eclipse's heritage in IBM VisualAge Smalltalk). The debugger didn't seem to be anything special -- it looks like a debugger. Going further, the heavy reliance on the mouse and the floating/stacking model of window management seriously cramp my style and slow me down.
Even as a language, I don't see what Smalltalk has to offer the programmer when compared to other languages. Yes, it's nice- and clean-looking. Yes, it was hugely influential. But it forces you to build your entire application out of nothing but objects and methods belonging to them, and cannot offer the flexibility of a multiparadigm language. Even as a strictly-OO language, it limits you to single inheritance and single dispatch. What other tools does it offer for creating and composing abstractions beyond its degenerate notions of objects and methods? Perhaps in 1980 it was an excellent choice, but we've had better choices since the 90s rolled in.
I've got enormous respect for the likes of Alan Kay, Dan Ingalls, L Peter Deutsche, and their whole crew at PARC. They certainly made history and have had a great deal of influence on our field. Notwithstanding, they were not alone in their innovation, and their product was not and is not perfect. Perhaps nothing will ever be perfect, but I feel as though Smalltalk has been surpassed at this point in time.
There are some massive advantages to smalltalk's all-object approach: Metaprogramming (like MOP), becomes far easier and more useful.
And while the object model is degenerate, and there is only single dispatch, It's not that bad: The above are similar to Java, and smalltalk has much better metaprogramming than Java. I think dynamic dispatch in ST wouldn't be too hard to hack in. But I haven't explored enough about ST metaprogramming to be sure.
>Perhaps nothing will ever be perfect, but I feel as though Smalltalk has been surpassed at this point in time.
You may well be right, but it IS one of the very few OO languages that meet Kay's definition of the term, and is said to be akin to lisp in many respects. And lisp is a language many would say the same for.
But you may be right, and while much the ST family aside from ST-80 died, a few survived: namely, Self, Newspeak, and Io, all based to some degree upon ST-80. Of the three, at least one seems dead, all three are still usable and offer glimpses into what might have been.
> There are some massive advantages to smalltalk's all-object approach: Metaprogramming (like MOP), becomes far easier and more useful.
That's fine. I wasn't questioning Smalltalk's all-object approach, though. Lots of languages do that now.
> And while the object model is degenerate, and there is only single dispatch, It's not that bad: The above are similar to Java, and smalltalk has much better metaprogramming than Java.
"It's better than Java" is hardly a consolation :p
> I think dynamic dispatch in ST wouldn't be too hard to hack in. But I haven't explored enough about ST metaprogramming to be sure.
From what I could tell when I looked into it, the standard solution is to use the Visitor pattern, as you would in Java or C++. That leaves me pretty wanting, to say the least, and anything beyond double dispatch via Visitor is too tedious and spaghetti-like to be worth it at all.
> You may well be right, but it IS one of the very few OO languages that meet Kay's definition of the term, and is said to be akin to lisp in many respects.
That's because Lisp was one of Kay's inspirations for Smalltalk. It's not unique to Smalltalk, either, and it wasn't unique to Smalltalk even when it was conceived -- tons of languages are "akin to Lisp in many respects" nowadays. Doesn't make them Lisp, though :p
> And lisp is a language many would say the same for.
Sure, you can implement Smalltalk-style message-passing semantics in Lisp (it's how Scheme was born, after all), but I find CLOS-style generic-function-application semantics to be far more powerful and expressive. Not only do you get multiple dispatch and multiple inheritance, but the separation of methods from objects means that the methods themselves (the generic functions, technically) are first-class objects and can be passed to and returned from other functions, stored in data structures, etc. The separation also leads to a nice solution to what I call the "Expression Problem for Untyped Languages", which is a weaker form of the Expression Problem, differing only in that it relaxes the requirement for static type safety.
Anyway, what I'm trying to get at here is twofold: 1) CLOS > ST; 2) I wonder how Alan Kay feels about CLOS-style OOP, given that objects no longer behave as actors sending and receiving messages (though, I guess if you squint a little, you can view multiple dispatch as sending a message to a group of actors, such that they work in parallel to accomplish some task and produce a response; and, of course, you can still write singly-dispatched methods in CLOS, too).
> But you may be right, and while much the ST family aside from ST-80 died, a few survived: namely, Self, Newspeak, and Io, all based to some degree upon ST-80. Of the three, at least one seems dead, all three are still usable and offer glimpses into what might have been.
Smalltalk doesn't only rely on OOP. It has lambdas and closures so that you have functional capabilities, too. Not strictly multi-paradigm, but close enough. This is why Smalltalk is so powerful.
Multiple inheritance has its problems, too. I prefer the greater simplicity of single inheritance.
Most "problems" with multiple inheritance stem from languages that don't provide a well-defined method resolution scheme. Languages that do have a well-defined hierarchy linearization tend to avoid most of the problems with multiple inheritance.
See, for example: Common Lisp, Dylan, Python (since 2.3), Perl 6, ...
However, to use Steve Yegge's example, say you're making a game, and you have a LightSource class, and a Weapon class, and now you want a glowing sword. :)
Given, this sort of problem is far easier in ST than in java, because we have MessageNotUnderstood (I think that's what it's called), so you don't have to do as much stubbing.
> How anyone could possibly be productive in such an environment. What is it that's so attractive about it to Smalltalkers?
Now you've probably heard that in Smalltalk everything is an object. Sure its an nice catch-phrase but hard to grasp its significance. Consider then, that classes and methods are live objects within the Image. You can operate on them as you work within the live Image and from your application program.
For example, the Pharo mail list was recently asked the following question...
> I want to have many different object instances with different
> behaviors picked at random from a list of available behaviors. What I had in mind was a functionality similar
> to prototyped languages like Self and Javascript in which you
> could change the behavior inside the object and not the class/prototype.
A way to achieve this is to define each behavior as a normal method. For convenience, we'll define two protocols, 'behaviors' and 'non-behaviors' in the system Browser to hold these. For the uninitiated here is a short intro to the Browser. Protocols show in the third pane.
https://www.youtube.com/watch?v=zgQjcZ9SCCs
The class MyObject is defined with an instance variable to hold which behavior to invoke...
When an object is created, we'll set an object's behavior by asking its class for all its methods, selecting those that are in the #behaviors protocol, then from that collection making a random selection.
In the Browser, add these two methods to the 'non-behaviors' protocol...
To test this, from Playground (our REPL) evaluate...
Transcript open.
10 timesRepeat: [ MyObject new perform ].
==> 2221212212
But how do I add new behavior at run-time you may ask? Now since classes are objects within the runtime Image, the application can ask the class to compile a new behavior. This is can be demonstrated by evaluating this code in the Playground...
That's pretty neat. Thank you for taking the time to write all this up.
That said, you can get the same kind of flexibility in Lisp or even Lua, among others, and I'm having a hard time thinking of a use-case where such a thing would come in handy.
A peculiar perspective of Smalltalk programmers is to consider that "code in files is dead code". External tools are needed to query it, modify it, compile it.
In Pharo you can evaluate... Integer methods first inspect
and in different tabs you can see this method's source code, the AST, the compiled bytecode.
Or in a similar way we can look at how PLUS is implemented by evaluating (Integer>>#+) inspect
Or look at all the methods that use PLUS
Within Smalltalk, classes and methods are themselves objects. You can operate on them like any other object. They are ALIVE!!! AHAhahaHaaaaa :)