Languages Vs Environments

Most people view a ProgrammingLanguage as something that sits on an OperatingSystem. VisualBasic, CeePlusPlus, and PythonLanguage are all examples of this. However the SmugLispWeenies will tell you that having a whole environment dedicated to that language is better. Think SymbolicsMachine and DynaBook.

So, the question is, just use a language on an OS, or hold out for an operating environment for your language. For CeeHackers?, either every OS, or no OSs fit this description, depending how you look at it.

An IntegratedDevelopmentEnvironment, especially as used for 'live' systems like SmalltalkLanguage or MozartProgrammingSystem, also fuzzy up the borderline between OperatingSystem and language. Many OS developers think this is the right way to go; providing NakedObjects and supporting NoApplication systems and so on. But to really have languages take over for the OS, we'll need both type-safety (even if dynamic) and a SecurityModel integrated into the language from the ground up, and probably some ProcessAccounting and effective resource management, all integrated into the language. ObjectCapabilityModel is an especially promising basis for security and much work has been done to achieve market-based, cooperative, and competitive resource management atop it.

From ColorForth:

Would it be possible to have only the language, without the operating system. I have some kind of bad experience when languages are combined with operating systems. Why not only make the language?

Because you lose most of the advantages of the environment when you use a separate OS.

What advantages do you lose? Stand-alone is not really an advantage, if you ask me. It can still be compact, simple, fast, innovative and unique, if you need this. What else?

I don't see how a system can be "compact" if it's strapped to a 2-megabyte OS kernel and megabytes upon megabytes of supplementary material. I don't see how a system can be "simple" if it has things like a user->supervisor transition for most/all basic operations. I don't see how a system can be "fast" if it's wasting most of its time copying buffers to and from user space to preserve POSIX semantics. I'm not going to touch "innovative" or "unique", those can easily be argued either way. On the other paw, I don't see myself switching to ColorForth as my main system. I, too, have too much invested in my current (FreeBsd) setup to make such a drastic change.

While I too have much invested in my current Linux machine, I'm working on setting up a JavaStation to host different environments. One will be SqueakSmalltalk on Linux. Another might be Squeak running on bare hardware. A 3rd might be something lisp related, and a fourth might be forth, again running bare. Plus, it will have a normal linux image for guest users.

A complete environment as opposed to a stand-alone language ties you to only those platforms for which the environment has been ported, and only those systems for which support has been added, while a stand-alone language does not(should not?) have those restrictions.

If I wanted to use, for example ColorForth on a Macintosh or over a network or with an external library or ..., I'd be out of luck, until the environment had these things added, while a stand-alone language would (hopefully) allow for just typing 'make'... -- MartinRudat

Well, a stand-alone language ties you to only those platforms for which the language has been ported. It's just (presumably) easier to port a stand-alone language than a full environment. If I want to use GwydionDylan on a non-CygWin Windows box, or RubyLanguage on a LispMachine, or CormanLisp? or MalbolgeLanguage on my Linux laptop, I'm out of luck. Not every platform has 'make' either; didn't that not exist for Macs until MacOsx? -- JonathanTang