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?
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.
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.
> Insulting people who don't use your language.
How am I insulting people??? I'm making a factual assertion, completely devoid of judgment.
Their UNIX versions are handicapped versions of themselves.
Languages with rich runtimes and developer tooling are always shoehorned into POSIX model to "feel UNIX".
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.
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.
PLT Scheme (language) → Racket
DrScheme (environment) → DrRacket
However, you completely miss the point of smalltalk by doing this.
"GNU Smalltalk -- The Smalltalk for those who can type"
http://smalltalk.gnu.org/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.
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).
https://www.youtube.com/watch?v=WLoXXFxU8lw
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.
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.
I don't think you can draw a general conclusion about Smalltalk from a specific example, especially like this one.
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.
As I mentioned above, Smalltalk is also file-based; when you distribute a smalltalk program source, you distribute a set of source text files.
Just like any other typical programming language.
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.
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.
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.
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.
The .changes and .sources text files are maintained in-the-background by the IDE and kept in-sync with the image file.
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.