8 ms·

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

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?

islanderfun 9y ago
Coming from a place of ignorance, how does Smalltalk not integrate?
- tom_mellior 9y ago
  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.
  - igouy 9y ago
    > 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).
- naasking 9y ago
  A Smalltalk environment is practically its own operating system, complete with its own isolated UI/window manager, shells and desktop environment.
  - EdwardCoffin 9y ago
    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?
    - naasking 9y ago
      Take a look at the Pharo intro on youtube, you'll see what I mean: https://www.youtube.com/watch?v=WLoXXFxU8lw 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.
      - EdwardCoffin 9y ago
        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.
        ihumanable 9y ago
        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.
        9y ago
- dangerbird2 9y ago
  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
  - flavio81 9y ago
    >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.
steveeq1 9y ago
Try GNU smalltalk if you want it "integrated" into linux: http://smalltalk.gnu.org/ http://smalltalk.gnu.org/ However, you completely miss the point of smalltalk by doing this.
pjmlp 9y ago
Lisp and Scheme don't actually integrate with UNIX. Their UNIX versions are handicapped versions of themselves. Languages with rich runtimes and developer tooling are always shoehorned into POSIX model to "feel UNIX".
- bad_login 9y ago
  Could you explain?
  - pjmlp 9y ago
    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.
  - zeveb 9y ago
    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.
- jdboyd 9y ago
  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?
louiscyphre 9y ago
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.
- tom_mellior 9y ago
  > 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.
  - louiscyphre 9y ago
    > remain rigid and stick to old, familiar ways > Insulting people who don't use your language. How am I insulting people??? I'm making a factual assertion, completely devoid of judgment.
igouy 9y ago
To suit your tastes, not Pharo, but: "GNU Smalltalk -- The Smalltalk for those who can type" http://smalltalk.gnu.org/
methehack 9y ago
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...
gnaritas 9y ago
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.
- flavio81 9y ago
  >like every other file based language 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.
  - gnaritas 9y ago
    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.
    - flavio81 9y ago
      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.

islanderfun 9y ago

Coming from a place of ignorance, how does Smalltalk not integrate?

tom_mellior 9y ago
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.
- igouy 9y ago
  > 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).
naasking 9y ago
A Smalltalk environment is practically its own operating system, complete with its own isolated UI/window manager, shells and desktop environment.
- EdwardCoffin 9y ago
  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?
  - naasking 9y ago
    Take a look at the Pharo intro on youtube, you'll see what I mean: https://www.youtube.com/watch?v=WLoXXFxU8lw 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.
    - EdwardCoffin 9y ago
      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.
      - ihumanable 9y ago
        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.
        9y ago
dangerbird2 9y ago
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
- flavio81 9y ago
  >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.

steveeq1 9y ago

Try GNU smalltalk if you want it "integrated" into linux: http://smalltalk.gnu.org/ http://smalltalk.gnu.org/ However, you completely miss the point of smalltalk by doing this.

pjmlp 9y ago

Lisp and Scheme don't actually integrate with UNIX. Their UNIX versions are handicapped versions of themselves. Languages with rich runtimes and developer tooling are always shoehorned into POSIX model to "feel UNIX".

bad_login 9y ago
Could you explain?
- pjmlp 9y ago
  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.
- zeveb 9y ago
  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.
jdboyd 9y ago
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?

louiscyphre 9y ago

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.

tom_mellior 9y ago
> 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.
- louiscyphre 9y ago
  > remain rigid and stick to old, familiar ways > Insulting people who don't use your language. How am I insulting people??? I'm making a factual assertion, completely devoid of judgment.

igouy 9y ago

To suit your tastes, not Pharo, but: "GNU Smalltalk -- The Smalltalk for those who can type" http://smalltalk.gnu.org/

methehack 9y ago

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...

gnaritas 9y ago

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.

flavio81 9y ago
>like every other file based language 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.
- gnaritas 9y ago
  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.
  - flavio81 9y ago
    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.