What you have said there is that Smalltalk does not have human readable source code! I don't get the comparison to an MP3 file. That is a totally different thing. For a long time music was composed, written down, in human readable form. As were the lyrics that went with it.
For thousands of years we did not a "converter" to read written or printed text. Of course it's a bit different with text files on a computer. But even there a text file is not married to a "renderer". We can use any editor we like. Or just view it with a pager like "less" or print it out. Or even get it read to use by a text to voice system. Not to mention searching and other processing with whatever other programs we like.
Oh, come on now, are you really going to try to assert that a fairly complex bit of software that takes a large collection of bytes, works out whether they are to be interpreted as ascii or UTF-8, or UTF-16, or UTF-32, or indeed many other encodings, then processes them via those encodings, arranges the results in chunks of some type, passes it to another complex of software that renders the 'characters' into bitmaps on a screen - *that* is not a renderer? That's just daft. Just because we're used to some variety of that lot of work getting done all the time and it has become almost invisible (unless you try to write one!), that doesn't obviate the fact that it does get done. Hell, the text editor I use a lot on my Mac - TextWrangler - is like a lot of other text editors in that it parses the data to make list of markers to interesting bits, depending on the kind of data it works out is being rendered. So C files get a nice collection of markers for functions and stuff, for example. I daresay one could write an input parse to handle Smalltalk code files.
Smalltalk systems simply use a different way of rendering the equivalent of a honking' great text file; instead of it being a long blob you have to scroll up and down all the time, it presents a nicely structured view that makes it easy to see each unit of code, to find the related code and users of each chunk and to find usages of any variables etc.
Sure, if you really wanted you could dump text versions of every bit of code into a single file. You can load that file into a plain old text editor. Good luck with making any real sense of it. I can even point you to such a file - http://files.squeak.org/5.1/Squeak5.1-1 ... -32bit.zip
There y'go, unzip that and read away.
To look at Smalltalk you need to see it in the context of the system, by running the system and using the proper tool;
That would be a show stopper for me. I'm sure it's not totally true though, as far as I can tell I can write Smalltalk with any editor and run it with GNU Smalltalk.
Why? What do you have against using a proper tool? You can't argue that it costs you money, it takes next to no effort to download and install. It takes very little space and if you don't like it it can be deleted without trace. You can try it out inside a web browser if even that is too much - take a look at http://try.squeak.org/#url=http://files ... /5.0/&zip=
[Squeak5.0-15113.zip,SqueakV50.sources.zip] but be warned that it is much slower than a 'real' Squeak install because it is running on JS.
In my view GNU Smalltalk is a very limited system, but if that approach makes you happy, give it a go. It's also possible to run a WebDAV interface in Squeak so that a text editor sees the system as a fake filing system; in my view it very nicely demonstrates why the proper tools are better.
You won't find a lot of Smalltalk on github because it's not a common tool for sharing Smalltalk code....Judging Smalltalk by it's prevalence on github is like judging Ducati's by their prevalence on Antarctica.
With that Ducati analogy are you say that Smalltalk is not suitable for the environment I work in?
Err, no. Try the other way around; if I look for C code on SqueakSource, I won't find a lot. Does that mean it has no use?
I did. It's very hard to find any source code there. Maybe it's easier if one registers but I'm not about to do that. Oddly you do find repositories, commit logs, contributor lists, diff comparisons etc.
Looks to me like everything you find on github or bitbucket. So why not just use github or bitbucket? At least use git anyway.
At least in part because we've been doing Smalltalk for a *lot* longer that git has been around. We already had tools that work pretty well for sharing code. Why bother moving to a new system that offered nothing interesting other than perhaps being 'new cool kid on the block'? It isn't a high priority for most of us.
Having said that, some people have done work on trying it out - obviously, or there wouldn't be any Smalltalk code at all on github. The Cuis branch of Squeak is working on using git as it's sharing mechanism, and seems to be having some success.