I tried out Smalltalk for a day and I was completely amazed by the some of the features that still haven't made it into other languages. One of the features that I remember in particular was the ability to search for functions by examples. I don't remember the exact syntax for it, but you could search by something like:
"hi" => "HI"
and Smalltalk would tell you "toUpperCase". Immediately after seeing this, I wanted the languages that I use everyday to be able to do it.
> The synthesis algorithm takes a generate-and-test approach: it generates an infinite stream of all the expressions having the same type as f; then, they are tested against the given predicate.
I'm really impressed that such a simple approach works. Initially I thought it was something similar to FOIL[0]. FOIL was a program that could learn function definitions by examples. One version of FOIL was able to solve exercises from a Prolog book. For one of the exercises, it was able to come up with a solution that was shorter than what humans had previously come up with. I don't remember exactly how FOIL worked, but if I recall correctly, it would repeatedly add predicates to it's currently best solution while trying to maximize the number of test cases which it had solved correctly.
There's probably some overlap with the different search strategies that can be applied to logic languages and Prolog-like systems. Further heuristics can limit the search space. Now we have programs that write programs!
Searching by type signature is very useful. I think searching by example input and output pairs would be a great addition to Haskell as well, especially for beginners and the base libraries.
A technique I use for poorly documented libraries is searching in github '<some keywords> <optionally library name> language:<language>'. Unfortunately there are some serious limitations in github search, no way escape certain characters.
The article highlights several contributions of Smalltalk to CS, but here's a few more:
David Ungar and Randall Smith, originally at Xerox PARC, then Stanford, designed Self, a prototype-based dynamic JITted Smalltalk dialect. In 1991 they joined Sun Microsystems, where Self kept being developed.
In 1994, Urs Hölzle at Stanford wrote a better compiler for Self. He was approached by Dave Griswold, who wrote a paper in 1993 with Gilad Bracha titled 'Strongtalk: Typechecking Smalltalk in a Production Environment', and together with Lars Bak the four of them started a company to commercialize Strongtalk. They were acquihired by Sun in 1997.
Together, the Self and Strongtalk teams' work resulted in the HotSpot VM for Java in 1999.
- David Ungar went on to be a member of the 'Dynamic Optimization Group' at IBM Research.
- Randall Smith now works at the 'Modeling, Simulation, and Optimization Group' at Oracle Labs.
- Urs Hölzle was one of Google's first hires and its first VP of Engineering and significantly shaped the company.
- Lars Bak joined Google in 2004 and went on to design the V8 runtime and Dart.
- Gilad Bracha went on to co-author much of the Java Language Specification and the Java VM Specification, then started a company to design the language Newspeak, and now works at Google on Dart.
- Dave Griswold continued to develop Strongtalk well into the 2000s, but I can't find any current info on him. If you know what he's up to these days, let me know!
I'm not really an ST fan myself. I'm not averse to it, or anything, but it has a steep learning curve, because you have to learn the class library, the IDE, and the language, and the poor tutorials and documentation make it even worse. Lisp had way better docs, and could be written in any text editor, so that's what I learned.
However, if you want to learn Smalltalk, might I reccomend GNU smalltalk? it's got the excellent docs you'd expect from a GNU project, unix integration, and while it does have a class browser and an image, it supports plain old text files for code, so you don't have to master an IDE if you don't want to, plus it's good for scripting. However, it has (mostly) the same class library as Squeak and other smalltalks, so it lessens the learning curve somewhat.
That you're so unwilling to leave your text editor makes you unsuitable for Smalltalk, because Smalltalk without its image and IDE stuffed into text files that work with all your normal tools isn't Smalltalk. It's missing everything Smalltalk'ers love about developing in Smalltalk. Someone who wants to learn Smalltalk should try Pharo or Squeak, not GNU, GNU will just leave them with a bad taste of weirdness for no good reason.
> Someone who wants to learn Smalltalk should try Pharo or Squeak, not GNU, GNU will just leave them with a bad taste of weirdness for no good reason.
As someone who has tried Pharo and Squeak, I was left with a bad taste of weirdness for no good reason. The colorful Playskool environment, while neat at first, was not only ugly and alien, but also quite minimal compared to Vim or Emacs. I still don't understand how anyone could possibly be productive in such an environment. What is it that's so attractive about it to Smalltalkers?
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.
The article explains how you can be productive. It's mostly in the "live coding/debugging" environment, which dramatically shortens the edit-test-debug cycle. The low cognitive friction of the language itself is also preeminent.
The clutter-free Smalltalk IDE is one its main selling points. I've used Xcode and Eclipse and Visual Studio, and the Smalltalk IDE is a breath of fresh air. Beauty is in the eye of the beholder, and I like Smalltalk very much. Dolphin, in particular, is prized for its excellent IDE implementation.
In practice, you don't need the full power of Vim or Emacs in a programming environment where you're ever only dealing with small methods and where everything is laid out neatly in the System or Class Browser. I love Vim, but I don't miss it here.
I think this is what it comes down to in the end. I don't find anything about it beautiful, from the aesthetics to the workflow to the isolation from the rest of the system. But I'm coming to realize thanks to the massive response to my comment why someone else might find any or all of those things beautiful, so thank you for that.
I find it interesting that you compare it favorably against Eclipse, considering that Eclipse is a direct descendant of IBM's VisualAge Smalltalk environment. Would you mind going into more detail why it is that the Squeak or Pharo environment is better for you than Eclipse?
> In practice, you don't need the full power of Vim or Emacs in a programming environment where you're ever only dealing with small methods and where everything is laid out neatly in the System or Class Browser. I love Vim, but I don't miss it here.
I disagree, and I think that dealing with a well-organized codebase composed of cohesive modules each containing an array of small methods (or equivalent) is an area (though far from the only one) where Emacs and Vim shine, especially when making use of multiple buffers, windows, netrw/dired-mode, wildmode/wildmenu, something like ctags/etags, registers, marks, ... the list goes on and on. I have a feeling that if you're not missing Vim or Emacs when using the Squeak/Pharo environment, you likely weren't making full use of Vim's or Emacs's power (which is excusable, given the learning curve of the those tools).
When I say that I've been using Vim for over 10 years, the implication is not that I've just been getting used to it for 10 years, it's that I've been constantly learning it for 10 years, and even now not a month goes by where I'm not able to more fully utilize its power than before. The only environment I've found that's more powerful/productive for me than Vim has been SLIME with Emacs (I've recently found out about SLIMV and am looking forward to giving it a try, though I tend to have an aversion to using plugins in Vim).
In the end, though, I think what it comes down to is the different emphasis on the environments. Whereas Vim and Emacs emphasize navigating and manipulating text, Squeak and Pharo emphasize navigating and manipulating a live environment. I personally loath that style of development because I'm lacking tools to track changes to the product and tools to reproduce the product from a fresh image. But if that style of development has been beneficial for you, then of course a tool like Vim or Emacs isn't going to cut it. To each their own, I suppose.
> considering that Eclipse is a direct descendant of IBM's VisualAge Smalltalk environment.
I was an active Smalltalker and Java developer in that timeframe and I used both Java and Smalltalk environments. IBM’s titles were "VisualAge for Smalltalk" (VAST) and "VisualAge for Java" (VA Java). They were both built on top of Smalltalk. . In fact, or at least my recollection, the VA Java environment had basically the same code browsers and tools available as the VAST environment, and the word on the street was that building on top of the Smalltalk environment allowed IBM to meet their time-to-market objectives for the Java product.
So I have to disagree with the idea that Eclipse is a direct descendant of VisualAge for Smalltalk. The same company was involved, but at best they’re siblings, and really, bastard siblings at that. Eclipse was a "rewrite" of the environment in verb only; it was a new environment in it’s own right and the tools didn’t allow for exploring and debugging existing code, or trying out new code, as well as VA Java did.
> I personally loath that style of development because I'm lacking tools to track changes to the product and tools to reproduce the product from a fresh image.
Both VisualAge for Smalltalk and Digitalk/V (the first of many subsequent re-writes that avoided Xerox’s licensing fees of Smalltalk-80) could commit "change sets" to an external code repository. Loading those changes to a fresh image would allow reproducing a product predictably, perhaps addressing your objection. I can speak definitively only for the Digitalk/V case, but the resulting image would include the dev tools and for the application, the VM would ensure that only the application code was executed. There was subsequent development (after a merger of Digitalk and it’s competitor, ParcPlace) that would allow creating an application in the more traditional sense, but that was never released. It was rumored that Dolphin Smalltalk had that capability, but that, too, never saw the light of day (as far as I'm aware).
Thank you for the history lesson. I find this stuff very interesting, but it can be hard to find reliable information except by talking to people who know (I mean, you don't get that kind of detail from typical articles on the Web). That pretty much means we have to piece together a lot of this history by talking to people, which seems strange to me in this day and age given how easily we can record and preserve such information.
If you see programs as a collection of static text files, you're not going to understand, but if you approach it as Smalltalk does, no files, no compile time, see the image as a live runtime, you'll realize you can prototype things via on the fly tinkering faster than virtually any other environment; you don't even need a database as you can just store collects of objects in class variables since it's always run-time in Smalltalk your object instances live in the image as long as you want them to.
Smalltalk'ers believe that code should be optimized for reading, not writing, which is why Smalltalk code browsers focus far more on organization than any other languages IDE's do and the power of this cannot be emphasized enough.
Simply put, once you let go of your text editor addiction, and embrace the image, it's the most productive programming environment there is as far as Smalltalk'ers are concerned.
I'm familiar and reasonably comfortable with the "image" concept from Lisp, but frankly I think outside of prototyping it's an inferior way to program.
When you're doing some sort of exploratory/experimental programming or trying to incrementally prototype some program, the ability to modify a live environment is fine, but it's only just barely better than coding in a file, and only because it saves you a small amount of time.
But once you're ready for distribution, images have a ton of drawbacks. For example:
* The running image is either particular to some physical machine, or it's constrained to a virtual machine, leaving you to pick one of portability or efficiency.
* I have to believe that there's some way to remove the development environment from the final image, but I didn't find a way to do that with Squeak when I tried it -- if there's really no way to do that, then suddenly your production image includes a full development environment in addition to your application, costing you and your customers unnecessary storage space, memory, and bandwidth.
* There's also a question of how well the environment within the image can communicate and interact with the host environment -- from the end user's point of view, it looks and behaves differently from everything else they use; how is it for the programmer?
The biggest problem with the image-based development style is reproducible builds. If your application has been created by incrementally tweaking a live environment here and there, how do you make that reproducible? How can you then save all the necessary code and data to recreate that state from a fresh image? Lisp solves the issue by supporting the file-based paradigm in addition to the image one, with constructs like LOAD, COMPILE, and COMPILE-FILE. At a higher level, Lisp also has a notion of "systems", which can be defined in a file and describe how to map a set of files to a final product (c.f. ASDF). Even in Lisp, however, you run the danger of forgetting about some change you made to the image and forgetting to include it in your source files. How would you do any of this in Squeak?
Along the same lines, how would you work with source control? Checking an image into git doesn't seem like an ideal solution.
In regard to code organization: files let developers organize the code however they feel is best, not the way some browser author decided is best. The idea of cohesion isn't just a sound engineering principle -- it's also a sound stylistic principle that can aid understanding of a system. Furthermore, a good text editor can help with navigating, exploring, querying, and processing text as well. Text editors aren't somehow limited to only enabling writing -- they have features to assist in reading and comprehending text, too.
I, for one, never felt more productive in any Smalltalk-type environment I've ever used, and such a development model seems to have quite a few drawbacks in exchange for only very few, very minor advantages.
> the ability to modify a live environment is fine, but it's only just barely better than coding in a file, and only because it saves you a small amount of time.
With experience programming complex applications both on C++ and Smalltalk, I have experienced coding in a live environment is all but a tiny advantage, it is a real productivity booster. The more complex your application the more productivity gain you have. In an interactive geometry application as Dr. Geo (http://drgeo.eu) , the combined use of in-situation inspector, debugger and live code editing on graphic geometry items, ease issues finding and fixing. Fixing issues is much more easier and pleasant thanks to the developer tooling.
This is not without mentioning other advantages as a better source code access and understanding thanks to the class browser. In C++ I was using Emacs.
> I have to believe that there's some way to remove the development environment from the final image,
It really depends on the Smalltalk implementation. I heard Dolphin Smalltalk (http://www.object-arts.com/) or Smalltalk X (https://www.exept.de/en/smalltalk-x.html) are really good at that. Pharo itself is doing progress in that specific direction.
What do you think about the proposition that a good chunk of the difference in productivity was due to the fact that you were no longer dealing with such a shitty language as C++? ;)
The way you explain the advantages, it seems like the live environment is much more beneficial when developing highly interactive applications, perhaps GUI applications especially, but the advantages of the live environment wouldn't come into play so much when developing non-interactive, "batch mode" applications. Do you think that's a fair assessment?
If so, then perhaps one reason I didn't find much value in the Smalltalk environment is that I wasn't developing interactive applications. With batch applications, I've come to find that even classical debuggers aren't quite as helpful as they are with interactive applications, because depending on how long it takes your program to run, it can often be faster to run a test case and inspect the log than to set a few breakpoints and step until you find your problem.
AFAIK, in Java or Python, I don't find this live environment either. Also I found these languages to be over-complex or inconsistent in their paradigm. I remember Java to be overequiped in its Object representation or Python to be inconsistent with its String object. In Smalltalk I don't need to question my self with the language itself: it is always consistent, rooted to a few set of rules. Only questioning is when dealing with the functionality of a class or method, but in that case I can look in the live environment itself use case of a class or method new to me.
In my experience live environment brings added values when you need to fix issues arising in the middle of a complex process of data and state computation or manipulation. In such situation, logging errors, fixing, rebuild, rerun, positioning the program states where the errors raised is very time consuming (and frustrating) than fixing in the live environment where you just need to recompile the faulty code (method granularity), adjust the data and resume the execution of the program from there.
In my experience it is true for GUI interactive application, fixing non interactive algorithm, processing data, web application.
By batch mode, I guess you mean processing data. If the process is complex, the live environment will help to get more quickly a proper and safer code. But may be in that case, you want a small script or executable you can move along easier than the Smalltalk environment. That's an area of use I don't know with Smalltalk and Smaltalk was not designed for that use case, although it seems people are using it too as a script tool. I will interested to read about that use cases too.
>I'm familiar and reasonably comfortable with the "image" concept from Lisp,
I'm primarily a Schemer, so correct me if I'm wrong, but lisp, at least since the death of the lisp machine, doesn't have an image: it has a live environment in RAM, and there's no easy way to dump that to disk. It's just a REPL.
>I have to believe that there's some way to remove the development environment from the final image, but I didn't find a way to do that with Squeak when I tried it
You certainly can, presumably just by stripping them out, but I'm not 100% sure, as I've never tried. MIT did it though, back in the days of squeak 2.X, leading to MIT Squeak, which is Squeak stripped down to just the bare necessities to develop Scratch. They didn't remove the class browser, workspace, transcript, or debugger, but I imagine it wouldn't be too hard, and besides, if there was a problem with your code in production, you'd want them there.
>There's also a question of how well the environment within the image can communicate and interact with the host environment -- from the end user's point of view, it looks and behaves differently from everything else they use; how is it for the programmer?
Squeak's got an FFI, and has binding for network access, etc., but one of smalltalk's greatest failings is its inability to play well with others. Scratch 1.X is probably the best example of a Smalltalk UI in action that you'll see, and you can see how foreign that looks.
>The biggest problem with the image-based development style is reproducible builds. If your application has been created by incrementally tweaking a live environment here and there, how do you make that reproducible? How can you then save all the necessary code and data to recreate that state from a fresh image?
And this is where the misunderstanding stems from: The image is a live environment, yes, but it is also your entire application, and your source code: When you hit 'save' in a smalltalk image, all of your code, as well as a snapshot of the state of every single object in the system, is saved to disk. There is no file to forget to add things to. If you added it live, it's in your system, same as if you'd typed it into a text file in lisp.
>Along the same lines, how would you work with source control? Checking an image into git doesn't seem like an ideal solution.
It's not. Which is why Smalltalk has its own version control system, and (I believe), a git bridge, allowing you to save only your classes, your projects, and what you've changed to a repo, and download them to other images.
>In regard to code organization: files let developers organize the code however they feel is best, not the way some browser author decided is best.
You're still thinking in terms of files: In a smalltalk vm, the browser isn't organizing files: it's organizing classes. And you can sort those classes into packages, and the methods into protocols. Not perfect, but pretty good.
>Furthermore, a good text editor can help with navigating, exploring, querying, and processing text as well. Text editors aren't somehow limited to only enabling writing -- they have features to assist in reading and comprehending text, too.
An ST environment can query, navigate, and explore the objects that text represents, and tell you far more about what your code is doing that any text editor.
> I'm primarily a Schemer, so correct me if I'm wrong, but lisp, at least since the death of the lisp machine, doesn't have an image: it has a live environment in RAM, and there's no easy way to dump that to disk. It's just a REPL.
This is true of many Scheme environments. Some Scheme environments do support the image-based development model, and at least Scheme48 uses it exclusively for compiled code.
However, it's more common to find image-based development in other Lisp dialects. In the case of Common Lisp, for example, have a look at this[0] paper on the SBCL bootstrap process.
> And this is where the misunderstanding stems from: The image is a live environment, yes, but it is also your entire application, and your source code: When you hit 'save' in a smalltalk image, all of your code, as well as a snapshot of the state of every single object in the system, is saved to disk. There is no file to forget to add things to. If you added it live, it's in your system, same as if you'd typed it into a text file in lisp.
Right. Perhaps an example would help clear up what I mean: Say you have an application in some Smalltalk environment, but you want to bring that application up in some other Smalltalk environment (on another platform, for example). All of your code is stored within image A for the original environment, and you have a fresh image B for the other environment. How do you reproduce image A for the new environment starting with image B? If your source code is stored in files, you can easily enough just load those files into the new environment.
On the other hand, I really don't understand what kind of benefits you gain by doing all of your programming in a live environment. I always felt the same way about Lisp's REPL: the interactive interpreter is handy for quickly testing out some code for sure, but I wouldn't want to write my entire application in an interactive interpreter. Why? Because if my sources are represented in plain text files, I can use any number of specialized tools to query and process them. This is the kind of thing people mean when they say things like "Unix is my IDE", and why I am the most productive with Vim open next to a shell prompt and a REPL.
> It's not. Which is why Smalltalk has its own version control system, and (I believe), a git bridge, allowing you to save only your classes, your projects, and what you've changed to a repo, and download them to other images.
It seems that this would solve some of the issues I raised, especially the ability to download into other images. The last time I played with Squeak, there wasn't any git bridge (in fact, there may not have been any git whatsoever... it was quite some time ago), and any builtin version control was pretty awkward and limited.
> You're still thinking in terms of files: In a smalltalk vm, the browser isn't organizing files: it's organizing classes. And you can sort those classes into packages, and the methods into protocols. Not perfect, but pretty good.
Yes, I am thinking in terms of files. I was trying to make the point that using files gives the programmer far more flexibility in organization, which I see as an advantage compared to using an image. Furthermore, most of the IDEs I've used offer package/class/method browsers on top of files, giving the best of both worlds. Take Eclipse for example: its navigation pane displays a hierarchy of packages, classes, and methods -- it's effectively the same as using the Smalltalk class browser, but the underlying storage is based on a file hierarchy which has been processed by the IDE.
> An ST environment can query, navigate, and explore the objects that text represents, and tell you far more about what your code is doing that any text editor.
I don't believe that one bit, especially considering that there is a variety of tools available for processing text files beyond just a text editor (and, of course, any text editor worth its weight in bits can interface with external programs).
One thing to understand regarding Smalltalk, it is the paradigm shift compared to file based environment:
- with the later, you deal with characters (ascii, utf8)
- with the former, you deal with object (an internal object representation).
So indeed the tooling is different. One deal with text processing, the other with object processing. The benefits you get are different. The browsers in Eclipse and Smalltalk are not processing the same thing, an Object is a far more abstracted representation of your source code, for example the browser can ask to an Object can you do 'that' kind of processing, or do you accept I send this message (method call in other language), etc.
When developing, the image is your sandbox environment with object representation of your code, but of course Smalltalk developers also save their code in text file representation, but it is only mean as a backup and transportation scheme from an image to another image. AFAIK, it is never uses for anything else than transporting or comparing source code version; not because we can't do it, but because we don't need to it.
The question regarding the source code file arises very often on Smalltalk. Not because Smalltalk is doing wrong there, but because it is a paradigm shift, and as you know we are all more or less conservative regarding changes or different point of view; some fellow free software activists disregard me to use such an awkward environment, but at least RMS did not get problem GNU DrGeo moved to the Pharo platform once I explain the underneath system, and that the access to the source code from the VM up to the Pharo environment was plain free software licensed as MIT licence.
To sum up:
- the image is the sandbox where you deal with object
- we save code in file (one monolithic file, or small granulated one file per method) for back up, versioning, transportation
- the developer may from time to time, decide to take a fresh image and reload his source code
- delivered Smalltalk application are built from a fresh image and source code installation from the source file of the code. For http://drgeo.eu I use a combination of Smalltalk script and Bash script to build the delivered application for GNU-Linux/MacOSX/Windows.
-
I'm not adverse to leaving my text editor, but I'd rather learn the language before learning a totally new and unfamilliar environment. Is that such a bad thing?
Yes, because you incorrectly presume those are different things that should be separated; in Smalltalk the language and environment are so deeply interwoven to create a live coding experience that what you want is simply the wrong approach, you can't get the correct experience doing what you want. This is a case of "what you already know" getting in the way of learning.
As a young Scratcher, Smalltalk was one of the first languages I tried. Before I even know emacs, or any of that stuff. It's not what I know that's getting in the way: It's what I don't know, and is never explained, because the Squeak docs are TERRIBLE. If somebody would explain how it works, I'd be willing to try. And I just got some new resources, so I'll give it a shot.
Well, that's true, the docs are terrible; you're way better off finding videos of people using the environment and eventually just learning to experiment with it. Largely what's different is that everything is live, all text is code and all code is text and you can highlight anything anywhere and execute it via either context menu or hotkeys. Pays to learn the hotkeys. Pays to learn to use hotkey for inspector and evaluator; inspectors are amazing, working with an object model without a database needing to be behind it is amazing, it lets you prototype extremely fast. And finally, the language itself is amazing as it's a programmable programming language, you can extend it to work to your will with very nice internal DSL's largely thanks to cascades and a clean anonymous function syntax.
> Maybe there's a reason Smalltalk never caught on...
There is, that wasn't it. The reason it didn't catch on was lack of a free version during the period of time it could have taken off. It cost a fortune and was competing with languages that were free to developers, Java took off instead.
I learn Smalltalk a few years ago to port a C++ interactive geometry software (http://drgeo.eu) to Squeak/Etoys then Pharo. I can testify documentation was never an issue, there are plenty of free books to learn from and a very helpful and talented community.
Smalltalk is still so revolutionary in its concepts, I am afraid you have to do your home work to get it and work on the text book.
The language and IDE are so simple that it takes very little effort to learn, at least, in my experience. But you're right about the class library. However, is this really any different for any OOP language that has a rich class library? Or any language that has a rich API (<cough> Java <cough> C# <cough>)?
I learned to program in Dolphin SmallTalk at a small business run out of barn next to a bunch of soybean farms. While probably not the best language to run a production application with (because of the tininess of the community), I agree that it's a great language to learn on.
I think the SmallTalk development environment is one of the closest things available to what Bret Victor was talking about in this article: http://worrydream.com/LearnableProgramming/. The IDE integration and live coding experience is fantastic. I really miss this feature in other languages/IDEs. It's also amazing how the refactoring engine in Dolphin is as good/better for a dynamically typed language than many IDEs for statically typed languages.
I remember learning smalltalk years ago and would have loved to use it commercially, it always had many problems though. Platform support, databases connectivity, performance, you couldn't make a shrink wrapped distributable. It was always stuck as an academic language imho, which is a shame. Even now lets say I wanted to use it to develop my mobile app, I don't think this is possible? Learn it by all means it has some great ideas.
Smalltalk is not stuck as an academic language. Cincom and GemTalk would be very surprised to hear that. It is, and has been, used all around the world for commercial purposes for over three decades: https://medium.com/smalltalk-talk/who-uses-smalltalk-c6fdaa6...
It is possible to create shrink-wrapped distributables, but these days there really isn't much call for it. Most of the action is in the web and mobile space and IoT and so on.
Regarding performance, it was an issue prior to circa 1995, but today's hardware is more than fast enough. That's why Python and Ruby and Perl and Erlang are so popular, being no faster than Smalltalk.
Do you know of a native version of smalltalk for mobile and desktop (produces native executables that is)? Not a web browser version - too slow for my purposes. I haven't been able to find one.
Article very briefly mentions Squeak[0], which I think would be worth looking into if you wish to pursue Smalltalk as a modern language instead of simply a historical footnote. Alan Kay, Smalltalk's creator, continues to contribute to Squeak, which he considers closer to his original ideal of what the language should be than Smalltalk-80.
Hmmm, I find this slightly misleading. It was a long time ago that the original Smalltalk creators were involved in Squeak (Dan Ingalls is the main developer, Alan Kay the visionary).
It should also be mentioned that Squeak (and Pharo too) was and still is VERY close to Smalltalk-80.
I think that's vacuously true in that learning any language that's dissimilar enough from the ones you already know can make you a better developer. (Smalltalk's nowhere close to the top of the "learn next" stack for me tho)
I almost can't read anything more than a page long without Print Friendly[1] or Readability[2]. Not because of ads, but getting rid of all the distraction makes it so much more pleasurable.
I used to have the same feeling, until I realized that the popups were actually prompting me to the next step. I now depend on the popups (I "live in the debugger" as it were), and I get concerned when they don't happen at all.
