My beef with Smalltalk is that it's far too much a world onto itself for my taste. Java is already a bad enough citizen of Unix but Smalltalk takes it to a new level. If Lisp and Scheme can integrate well into Unix, why can't Smalltalk?
Pharo, like GNU Smalltalk, has a command line mode so that you can use your favourite editor. However, without the live coding IDE, you lose the biggest benefit of the language: highly accelerated development and enormous programmer productivity.
Yes, Pharo (and Smalltalk) is a world unto itself but that's the price you pay for a highly productive, easy-to-program software development environment. How are you going to achieve this by retrofitting to an archaic methodology based on text files and over-engineered IDEs like Visual Studio and Eclipse? Java and C++ impose severe constraints and compromises in this respect.
At the end of the day, it's all about a programmer's ability to adapt to new methodologies. If they remain rigid and stick to old, familiar ways, there can be no great improvement in the way we create software.
> Pharo, like GNU Smalltalk, has a command line mode so that you can use your favourite editor.
That's good news that does not appear in official documentation (last time I checked).
> Yes, Pharo (and Smalltalk) is a world unto itself but that's the price you pay for a highly productive, easy-to-program software development environment.
Users want standalone software. They don't want to be forced to run programs in your highly productive IDE. If your IDE is marketed to programmers as "a shiny IDE you will never be able to escape from", programmers won't use it for fear of not being able to deploy software in a way that users would accept.
> remain rigid and stick to old, familiar ways
You know what has never ever worked for promoting programming languages? Insulting people who don't use your language.
I get what you mean about that for Lisp (although, if I'm not mistaken, early LISPs were more like SBCL than Allegro or Symbolics in turns of user environment), but what Scheme version ever offered such a rich environment as the Lisp or Smalltalk examples mentioned above?
For example, the Interlisp-D of Xerox PARC, ZetaLisp of Genera or even Alegro Common Lisp.
They provide a rich graphical developer experience, with many features that are the genesis of modern IDEs, and nothing on their standard library and runtime depends on anything POSIX related.
The Lisps that "integrate well" with UNIX, like SBCL, do so by providing a UNIX text based repl without that graphical power, while using Emacs, an editor based on Lisp Machines, that even with SLIME is not quite like the commercial Lisps.
Same applies to any other language with a rich runtime, that makes the underlying OS irrelevant.
As an example, Lisp has an amazingly full-featured condition system. It enables all sorts of stuff like detecting an error condition, changing arguments, rerunning code, replacing code while it's running &c. If it were plumbed all the way down into the OS, I could call lispy_mmap with the wrong arguments, detect that they're wrong, fix them and then return from lispy_mmap as though nothing had happened.
Instead, in a Lisp on Unix, I'll call mmap and either have to manually check for an error or use a wrapper which does that for me. If there is an error, I'll have to re-call mmap.
It's not terrible, and it's still a lot better than using e.g. C — but it's not as good as it could be in a Lisp-all-the-way-down system.
It can read files and talk to databases and make network connections etc... Are you just talking about using an editor on Unix files? iirc, the in IDE editor takes advantage of the meta-data in the compiled classes in order to provide a better editing experience that a file system approach could only replicate with a separate parser...
The default mode of interaction with Pharo and most other Smalltalk-based systems is not "launch an application which interacts on the console or opens some windows", but rather "launch Pharo, then inside the big Pharo window launch an application which interacts on the Pharo console or opens some windows inside the big Pharo window".
I think there are ways around this, but you may have to dig deep to find out how.
GNU Smalltalk is different: It doesn't have this traditional interaction mode. Many Smalltalk fans will probably find that that's a disadvantage.
> is not "launch an application which interacts on the console or opens some windows"
Actually, the standard end-user experience is to launch an application which interacts on the console or opens some windows.
(There'll be some system startup methods which define what happens when the image launches -- don't open the development environment windows, open the application windows).
I'm not really sure what you are claiming here. My experiences with Smalltalk ended 20 years ago with IBM Smalltalk and Digitalk Smalltalk/V. At that time, they both used the host operating system (Windows or OS/2) for UI widgets, windows, and such, and any applications you built in it could be packaged up to be launched as any other application. One could use such an application and have no particular sense of isolation beyond an application written in a more mainstream language (like C or C++). Have modern Smalltalks regressed in this regard?
The images on the current website look very similar, so I don't it's changed much in this regard. This has been my typical experience with Smalltalk languages, with the exception of GNU Smalltalk whose specific goal is to integrate with POSIX instead of creating a walled garden.
Do you want to perhaps point to a specific time in that video, and compare it to a non-Smalltalk environment in a way that makes this purported isolation apparent, because I don't see what you mean.
I don't recognize whatever operating system the demo was done on, so if the Pharo system is not using native widgets I would not know, you'll have to explicitly state if this is the case.
The presenter is in the host operating system (Mac OSX) until the Pharo image is "up and running" at the 0:40 mark. Everything until the presenter opens up debian at 5:00 is custom Pharo based desktop / window management / even the mouse cursor if you look closely.
Then this just means that Pharo is one of the Smalltalks that does its own window management. I think Squeak might be the same. It is not a general characteristic of Smalltalks though, and certainly is not part of their essential nature. As I said, IBM Smalltalk used native widgets and windows, and had good interaction with the rest of the operating system.
I don't think you can draw a general conclusion about Smalltalk from a specific example, especially like this one.
Smalltalk does not use text-based source files, with object source code saved as part of a binary vm image. Smalltalk is completely incomparable with unix editors, version control, and developer tools, relying instead on integrated dev tools inside the vm. Because all development and tools are inside a monolithic image, it's not very practical for writing shell scripts
>Smalltalk does not use text-based source files, with object source code saved as part of a binary vm image.
This is a misleading claim often made by the author of this Medium article. Smalltalk code does reside in text files and the IDE keeps them. This is apart of the "image" that is also kept by the environment to enable faster loading and store state.
What you mean is, why can't you take everything that makes Smalltalk great away, and make it work like every other file based language. The answer is, because then it would suck.
I'm a Smalltalk'er, and that's completely disingenuous and frankly intellectually dishonest.
What Smalltalk does is not remotely what you do in other languages and when we say file based we're referring to that difference, file oriented programming vs image oriented programming.
A Smalltalk program is not a collection of files one works with, it doesn't fit into the standard file based workflow, you cannot without jumping through many hoops, work on a Smalltalk program from your standard editor using your standard unix tools and file based workflow. So when we say file based, it's this we're referring to, do not lie to people and claim Smalltalk is file based, it is not. Smalltalk is image based, you work with its dev tools on a running object model in an image; having the option to export that to a file after the fact is not remotely the same as being file based; that the image stores source code in a changes file, or that we share code between each other with st exports does not a file based language make.
St files by the way are a serialization format, they are not meant to be hand editable and are not treated as such and contain all kinds of non-Smalltalk stuff related to the serialization format; we don't edit st files and compile them, we edit in the image and import/export st files to share code between images.
The IDE keeps the text files, and that's what your source code is made of. Go to any Smalltalk github project and you will find .st files, which are plain text files, and there's your code.
I'm a Lisper, i do know what Image-based development is, because that's what I use*
You're misunderstanding Smalltalk, probably because of hype mongers like the author of this article. Source is text files as usual. This is not the same as the image. Your environment, and the compiled classes, are contained in the image, but the IDE also keeps the source, text files.
>St files by the way are a serialization format, they are not meant to be hand editable and are not treated as such and contain all kinds
.st __source__ files are text files. You are confusing them with the image files.
No I'm not misunderstanding Smalltalk, that Smalltalk now has a git plugin to be able to expose itself in that manner is exactly the kind of jumping through hoops I was referring to, it's taken many years for that to become stable and most of us still don't use it, we use Monticello. And both of those are for sharing code, not for developing, we don't work on those st files, we export them.
Don't tell me what I'm thinking and because of who, I make my living with Smalltalk (Squeak and now Pharo) and have for well over a decade and have done hundreds of millions in revenue through my Smalltalk apps.
> .st source files are text files.
I didn't say they weren't, they're still a plain text serialization format that is not directly what Smalltalk looks like and we still don't work on code by editing those files.
> You are confusing them with the image files.
No I'm not, if you actually read what I wrote, you'd see that.
Lisp is not Smalltalk, do not confuse how Lisp does image based development with how Smalltalk does it; they are not the same. When you have a few years experience actually working with Smalltalk doing production level stuff, then come talk to me, right now you're repeating nonsense that you're inferring based on apparently some light reading and no actual experience in the culture of and use of an actual Smalltalk.
Smalltalk's image file(s) contain only the compiled code, not the original source code, which is on the changes and source files. You could decompile the image and get most of the source but not in its original, complete form.
If your image crashes it gets reconstructed from those two files.
It would be great if you Smalltalk fans would explain its source handling in these terms above, instead of promoting "image based" as some sort of magic where there aren't any text files, because in this forum some programmers are getting (needlessly) scared about the image-based system and (needlessly) fearing it.
I'm sorry but you are really completely missing the point. You are conflating how Smalltalk is implemented under the hood (using files) with how Smalltalk is used for programming (using the image). Under the hood, Smalltalk has to adapt to the host platform, whether that be Windows, macOS, or Linux. In the original Smalltalk implementation over four decades ago, Smalltalk was the host platform (or operating system), so there were no files for source code.
Correct - and the only time someone would directly interact with the .changes or .sources text files (as-text-files without using the IDE), is in the unlikely event that the image file had become corrupted in some way, and they were trying to recover work that had been done.
The .changes and .sources text files are maintained in-the-background by the IDE and kept in-sync with the image file.
You only threw attacks and condescending comments instead of explaining Smalltalk's IDE way of keeping files, which I did. You are doing a disservice to the Smalltalk community with such an attitude.
> You're misunderstanding Smalltalk, probably because of hype mongers like the author of this article.
With that comment, you lost any good will I had for you. Despite that, I tried to explain to you anyway what we mean by file based and you simply ignored it and chose to argue with me about st files being plain text which is entirely irrelevant to the conversation. What more do you want? You're wrong, Smalltalk isn't file based, but you don't seem to know what Smalltalk'ers mean by that term, and you refuse to admit you're wrong despite you not even being a Smalltalker. That's willful ignorance, I have no patience for willful ignorance nor do I have any duty to the Smalltalk community, something I know vastly more about than you as I've been a member of it for a very very long time.
Getting off topic you mentioned doing production work in Smalltalk for a decade and even said "hundreds of millions" in reveue. To me that is quite impressive. Any chance you can point to a project you've done or some prominent Smalltalk apps? Pharo has some minor ones on their site and the author of the article frequently mentions JWARS. I'd like to see more though.
The projects I'm talking about are closed source business apps. My app is listed on the Seaside.st success stories page, but I'd rather not talk about it here.
