A long, long time ago, before even the 8080, I could do this (on the SinclairSpectrum):

   10 PRINT "Hello World"         (* see footnote)

My reward:

  Hello World

A few years later, I got hold of a PC and a copy of KernighanAndRitchie, and armed with the knowledge it bestowed, I opened my TextEditorOfChoice, and entered:

  #include <stdio.h>
  
  int main()
  {
     printf("Hello world\n");
     return 0;
  }

Sometime later, in the early stages of trying to understand PerlLanguage (which is an ongoing task), I'm sure that at the CommandPrompt, I tried typing something like:

  perl -e "print qq{Hello World\n}" 

NB, I didn't type the following, as it doesn't work on a Windows command prompt:

  perl -e 'print "Hello World\n"'

I'm also sure that at some time, armed with my TextEditorOfChoice, I compiled the following abhorrence:

  #include <iostream>
  
  using namespace std;
  
  int main()
  {
     cout << "Hello World" << eol;
     return 0;
  }

Hell, one time I even booted a SchemeLanguage interpreter, and at the CommandPrompt, I typed:

  (display "Hello World\n")

(And I believe I even persuaded a CommonLisp variant to play ball with a similar invokation).
By the time I got to Ruby, I was in the swing of things:

  puts "Hello World"

didn't phase me at all. I was feeling pretty happy with myself. Hell, there's no programming language which I can't convince to emit a hackneyed greeting aimed at no one in particular. 

So, maybe I'm getting blase, I thought I'd have a go at doing the same in Smalltalk, how hard could that be? So, according to my understanding the correct incantation is:

  Transcript show: 'Hello World'.

Seems fair enough.

However, at this stage I run into metaphorical difficulties (by which I mean I run into difficulties involving metaphors, not that the difficulties I run into are metaphorical). So far I've tried two versions of Smalltalk (Squeak and VisualWorks), and I've yet to find anything approximating a CommandPrompt. Sure, there's windows you can type text into, but when hitting the enter key, nothing in particular seems to happen. I can't even get a Syntax Error, or any kind of acknowledgement that I'm even typing. Now don't get me wrong here, there's no shortage of windows, and there ''seems'' to be a programming language in there somewhere? However, this is most confusing.

As a postscript, I've found that if I enter the following into VisualWorks:

  Transcript show: 'Hello World' printString.

''and then highlight it and right-click and select "Do it",'' the following text appears (albeit with no carriage return):

  'Hello World'

Which seems ''close'' to my intent, but I've no way of knowing if that message actually appeared on STDOUT, and I have a suspicion that it didn't. Anyways, I'll keep bashing at my keyboard, I'm sure one millionth of a Shakespeare play will eventually emerge...

[or you could learn the basic command keys, cmd d|i|p, do it, inspect it, and print it, then simply typing Transcript show: 'Hello World' cmd+P would print the result you were looking for. Cmd + I would pull up an inspector on the hello world string. In essence, the entire Smalltalk environment is a single permanent long term command shell environment, every text box anywhere in the image is executable part of that shell, far more advanced than a simple dos like command shell that doesn't maintain state between sessions. You can highlight any text anywhere and use those hotkeys to invoke it, do it, print it, inspect it, whatever. If you create a test object, it just lives on until there are no more references to it, even if you change it's class, there is no compile/run/debug/recreate state cycle, it's always runtime. ]

* ''This is really stretching the analogy between command shell and Smalltalk environment. Not only is it stretching the analogy past the breaking point, but making this analogy on a page whose point is to question such analogies is very disrespectful.''

''The following,''

   Transcript show: 'Hello World'; cr
''prints''

   Hello World

''to the Transcript with a carriage return. Adding a printString causes the Transcript to show a representation of the string 'Hello World' which representation includes quotes. IOW, not the same thing. Also, you should consider selecting and evaluating a piece of code (with ctrl-d in VW) to be the equivalent of Perl's''

   perl -q "<code>"
''And a damn sight less verbose it is too.''

* But if I was in a perl (or ruby, or ...) shell, I would just type <code> and hit carriage return. But if it's highlight & ctrl-D, that's not a paradigm I'm familiar with, but OK, I guess that's just how it is.

* ''Some STs, I think GST, have a command shell that behaves this way. Or if they don't then they used to. It's a real turn off frankly.''

''Sometimes there's a way to access stdin and stdout, there's a package for VW 7.3 called Standard IO Streams that allows it. The Smalltalk (and especially VW's) philosophy is that the language is self-contained and can't rely on OS-specific junk, let alone obsolete crap like stdin and stdout. That's why you have the Transcript instead. Consider that if you use Standard IO Streams except where it is desperately needed, you are breaking your code.''

* Wow, I didn't even know that stdout ''was'' obsolete, so I guess I've already learnt something. But, the question that I find myself now asking is this: Suppose I wanted to distribute my smalltalk hello world application to my friend, who wants to capture its output into a text file.  Lets say my friend is running Windows 2000 (and let's also assume that neither my friend or I have anything better to do with our time). Would that be the kind of situation in which I would want to use Standard IO Streams? Or is there a smalltalk abstraction of a bog-standard console app which I might be better off using?

* ''Glad you mentioned it because I made an error earlier. In the Smalltalk world, console apps are called 'headless images' (images without GUIs). And there have been packages for headless images for a long time. StandardHeadlessStdio for VW 3.0 is one of those.''

** This won't answer your question (because I don't know the answer) but it might be helpful in grokking the essence of Smalltalk and how it differs from, say, Ruby or Perl:  Smalltalk is generally intended to be an ''environment'', not just a language.  Therefore, it reflects a certain self-contained, somewhat isolated, operating system-like approach, which means it doesn't always play well with others -- at least not the way general purpose scripting languages or systems programming languages do.  This is not necessarily a bad thing.

** ''LanguagesAreOperatingSystems. Smalltalk is quite literally an operating system, just with crappier security than DOS. But if you want a Smalltalk that integrates well with its host OS, then Dolphin does this with Windows. So it's doable, just that most Smalltalks don't bother.''

* This package browser thingy looks pretty rockin', mind. I guess this lists all the classes in the standard library, plus source and documentation? ''Yes.''

* This looks like an interesting avenue of pursuit... I guess most things in ST will respond to inspect by showing me their innards? (However, I'm straying from my original purpose of 'hello world'...)

* ''The only thing that won't are faulting proxies or something else that transforms itself once it gets a message. But there aren't any in VW. There's also no way to inspect remote objects ....''

** ''Most things respond to #basicInspect, though faulting proxies and similar things can be really tedious. I haven't been inside VW recently, and I'm not sure what, specically, you mean by "remote objects". Various delegators and proxies '''can''' be looked at -- carefully -- with #basicInspect.''

** By remote objects I didn't mean instances of RemoteObject, I meant the objects behind the proxies. Though I was probably wrong above. I've got the excuse that I almost never used non-faulting proxies though. :)

** ''I should have been clear about what I meant by "carefully" when looking at such things. I am loath to mention it, because it leads to terrible abuse -- but judicious use of #instVarAt: and #instVarAt:put: can usually let you see those objects behind the proxies. You have to see what triggers the proxy, then find a way to step around it. For example, they'll often be instances of a class that has UndefinedObject, instead of Object, as its parent. If so, you can reach into the method that expands them and modify it so that you get what you want. It's all deep magic, though. When you need it, you REALLY need it, but thankfully it's usually not necessary. -- TomStambaugh''

----
OctoberZeroFive

CategorySmalltalk