Is Smalltalk Without Graphics Any Good

Since the 1970s, Smalltalk has been famous for being a great OO language in a great visual environment that introduced the world to WIMP (bitmap Windows Icon Mouse); is it great even as a purely textual programming language? (Moved from WhyIsSmalltalkDead)

(At one point in history, bitmap screens with enough horsepower to do bitmap graphics were rare)

does that mean no one has ever done a purely textual Smalltalk system? I know that would sacrifice a cool environment, but at least the core language could be available, no?

There was BuddsLittleSmalltalk... I don't know how far that went, though. Plus, it came straight from academia, which made it politically unfeasible anyway.
GnuSmalltalk hasn't had a graphics system for most of its existence (though my impression is that virtually no one uses GST).

It's hard to remove the Smalltalk environment from the Smalltalk language and still have something useful for developing programs. Smalltalk is a graphical environment for building objects. The language isn't designed for building objects from text files. In fact, there isn't really any syntax for it. GST has some syntax extensions to enable building programs from text files.

I don't see this. My experience with the language is limited, but the Smalltalk 80 books describe a textual programming language with a visual environment, not a visual programming language, and similarly with everything else I've seen on the subject. Or are you just talking about the process of applying the language implementation to a Smalltalk source code object, analogous to "cc file.c"? But that would be a minor issue, surely.

This may be a case of someone thinking Squeak is the only Smalltalk.

I'm the guy who wrote that about "building objects from text files" &c.. I have used VisualWorks and GST in addition to Squeak. I can't imagine actually writing a program in GST, but maybe one can adjust. (That is, (a) I've read the GST manual, read a bunch of its source code, and written the kinds of little programs one writes when playing with a new language.)

At any rate, much of the advantage to Smalltalk's dynamism and simplicity comes from the wonderful tools that enables, including the graphical inspectors, the fantastic debugger, and, of course, the browser. Without them, I'd rather use Ruby, which is a language designed to load programs from files.

Why am I more comfortable using Ruby this way than GST? I'm not sure. I'm being vague, and I don't know how to be more specific, so I offer to retract. DeleteWhenCooked, perhaps. Give it more time, maybe you'll come up with further insight into why you feel like that; it seems like a further answer could be illuminating.

The very conceptualization of the Smalltalk environment as "a textual programming language with a visual environment" is itself mistaken. Try to imagine "porting" a batch-oriented compiled output-only Lisp environment by removing EvalQuote? from the user environment of a Symbolics machine.

Intimate access to the display and input devices permeated the Smalltalk-80 image. In order to accomplish the task you describe, the developer would first have to create a "headless" image and then build a set of text-based utilities to interact with it. The first step is at least challenging for seasoned Smalltalk veterans to accomplish. The second step presumes an understanding of patterns and architectures that is only beginning to emerge today, two decades later.

One of the challenges in getting early Smalltalk images into circulation was, for example, getting them to run under X-Windows. The entire environment assumes that anybody anywhere can move bitmaps between memory and the display. All of the tools required to accomplish this feat themselves use the graphics routines.

As an illustration, consider that the Smalltalk group asked the first non-Xerox implementors to supply hard-copy of a screenshot of the desktop to demonstrate that they had successfully accomplished the port. In the case of Digital, this was accomplished -- literally -- by printing each display pixel to the corresponding position of a fan-fold page printout. This was required because the custom-built bitmap display wasn't finished when the Smalltalk port came up (in late 1981).

-- TomStambaugh

A light begins to dawn. All serious Smalltalk ports were a matter of porting the standard precious image, not on starting from scratch based on language documentation, as is common with many other languages. So creating a purely textual Smalltalk by trying to remove every trace of reference to the graphical environment would have been madness, on top of losing a lot of what made Smalltalk great to use.

Conversely, had someone created a purely textual Smalltalk back in the 1980s, it would not have been an attractive environment for existing Smalltalk programmers and businesses.

Yup, that's about it. Bear in mind that many significant instances of various classes were impossible to create from source code -- they had been hand-munged from earlier development images, during initial bootstrap. The root of the process tree, for example, was an instance of Process that lived for more than a decade. I am under the impression that a ceremony of sorts was held when it finally died.

I hadn't heard that, but had always assumed so, because such things always seem to happen to non-static binary images that are not continually regenerated from source, no matter what kind of image it is. (This should be somebody's law. TheLawOfMutatingBinaryImages, perhaps.)

Thanks for the extra explanation. -- DougMerritt

You're quite welcome. -- TomStambaugh

The build-from-scratch limitations of Smalltalk were only in there for historical reasons and were all removed by AllenWirfsBrock and his team when they built ModularSmalltalk?. ModularSmalltalk? did everything right, by the way, but wasn't important because the industry had already moved on by the time that it was finished. -- WardCunningham

Ward, do you have any intuition about what would be required to build a headless image from scratch using ModularSmalltalk?? -- TomStambaugh

How does EnfinSmalltalk fit into this? From what I understand, they didn't port the standard precious image

EnfinSmalltalk was sort of an import from an alien planet. In its original incarnation, it had no virtual machine and made no effort at bytecode compatibility. Instead, it was a C code-generation environment that used Smalltalk source code to drive C-language routines that emitted other C-language routines that were then compiled and linked.

Did it have graphics? Was it any good?

Its graphics were, well, different. When compared against real Smalltalk, I feel that it suffered from the comparison. On the other hand, when compared against other screen-scrapers or similar two-tier "solution generators", it was perfectly reasonable.

On the other hand, it might have been an attractive environment for enterprise data processing departments, looking for something better to write enterprise software in. Assuming it could be done and still be at all usable... given the experience we have today with Smalltalk-inspired ScriptingLanguages like PythonLanguage and RubyLanguage, where one can edit program text with vi and pass it to the interpreter for execution, yet still have DynamicTyping and other programmer-friendly features not found in Pascal, Cobol, or C/C++, I would have to believe a text-based Smalltalk or Smalltalk-like-thing would have been useful back then. Maybe not as developer-friendly as a full image-based Smalltalk; but imagine such a beast in the hands of a) hordes of hackers with PCs running MsDos, or b) a smaller horde of hackers running Unix on some university time-share system. Had Smalltalk gotten mindshare in these environments, we might never have heard of JavaLanguage.

JavaLanguage exists precisely because Smalltalk got mindshare, specifically in comparison to CeePlusPlus. Had Xerox or ParcPlace intentionally seeded free Smalltalk-80 environments to the academic community and even the commercial world, the outcome might have been different. Alas, ParcPlace instead had a very aggressive pricing scheme -- and had the same success in dominating the market with it that SteveJobs had in dominating the personal computer hardware market by refusing to license the Mac toolbox. An innovative system such as Smalltalk-80 was in 1982 can only find acceptance when it the base system is free.

Perhaps we can thank ParcPlace, in an indirect way, for the fact that Java, JavaScript, perl, the DotNet runtime and compilers, and virtually ALL similar technology is, today, free of charge.

In the early '80s I was playing with Smalltalk on a 16-bit IBM PC. I put some serious thought into converting Smalltalk to be text based instead of graphical. It would be a lot of work, but I'm sure it could be done. And with computer speeds at that time, it would have been a good thing to do.

Yes, I'm convinced that browser, debugger, pop-up menus and such could be done on character accessible text screens. Several MS-DOS compatible systems and products did it, why couldn't Smalltalk do it?

But I got distracted with other things, in college, and never did it. -- JeffGrigg

It could certainly be done. I think you'd end up having to build an entire ascii-based window system to support it, complete with clipping, obscuring, damage regions, pick correlation, and so on. But first let me ask a few questions:

How would you simulate multiple windows on a DOS-compatible green screen?
Would you define rectangular row/column areas and write within them, like some of the early attempts at ASCII-based GUI systems?
What width and height would you assume for the display itself, and how many of these could you fit in?
How many characters wide would an ascii-based popup menu be?
What do you do about the mouse? Cursor keys are REALLY slow when you depend on them ala Smalltalk.

The reason I ask these is that the Smalltalk-style user interface burns up display real estate at a prodigious clip, and the assumptions about user interaction, the mouse, and the display are deeply wired into the user interface. It isn't that it couldn't be done, it's more that I don't think you'd want to use the result. Besides, the interface itself would be basically unusable on typical 14" DOS-style ASCII-only monitor, and by the time you got enough (character based) screen real estate to solve the problem, you'd also have SVGA or better graphics capability -- mooting the whole exercise.

To quote an American ex-president "We could do that, but it would be wrong".

[Windowed text-mode DOS 'GUI's were quite common. One of many was TurboVision, used by some of Borland's tools such as TurboPascal and friends and bundled with it for developers' use. (It's since been OpenSourced: http://tvision.sourceforge.net/) A standard VGA will run in 80x50 text mode (even EGA ran at 80x43), and many cards could run in wider modes with more columns.]

Sure, sure. I did a (simple) window system with pop-up menus on text-based micros in 1979, nor was I even close to being one of the first. (In fact my college roommate did a more general such facility a year or so before: curses)

[See SimulatingWindowsWithTextGraphics for technical details.]

VisualWorks has a facility to save a headless image.

SuperCollider is a smalltalk like language for audio synthesis which is built around a textual environment. It's also very nice to use