Language Is An Os
Language Is An OsFrom OperatingSystem
The LanguageIsAnOs -- for languages that were designed to run without benefit of an independent OperatingSystem.
The development environment of the language is the entire OperatingSystem.
Also known as "PinkyAndTheBrainLanguages".
The main difference I see in the above 2 groups is: Most of the first group allow you to
There's another view though. ALL languages, whether or not they were designed to run on bare hardware, should be considered and evaluated as operating systems. A language that makes up a bad operating system is simply a bad language. See LanguagesAreOperatingSystems
This metric for language quality seems to focus mostly on the scope of the language's API/features, rather than on the inherent qualities of the language itself. Simply abstracting everything under the sun doesn't necessarily make a language good--IMHO JavaLanguage has gotten a bit too big simply because SunMicrosystems has been trying to do exactly that. Does a programming language need (as part of the language standard itself) such things as multimedia rendering libraries, system administration/user management libraries, etc. to qualify as a "good" language? I think not. It certainly should be possible to build such things in any language; however SeparationOfConcerns suggests that many such things should be left for other DomainExperts to build--rather than stuffing them in the language itself.
You will notice C/C++ added to the list above. This is not to suggest that these are necessarily good languages; the limitations and weaknesses of both are well-chronicled and I don't wish to repeat that FlameWar here. However--entire production-quality operating systems are implemented in these. It is true that users of such operating systems are not presented with a console (or a BrowserWindow?) where they can start entering C/C++ code (as the preferred method of accessing and mutating the underlying OS). But I say BigDeal?. One can certainly access all of the features of the OS through these languages (of course, additional APIs beyond the language standard library are needed--which makes portable C/C++ code more difficult to write) should one choose to do so. Most EndUsers aren't interested in programming anyway; and aren't likely to care what language(s) an OS is written in.
There seems to be a large amount of confusion between the needs of the EndUser (who wants to get work done; work which for most users involves no writing of code) and the needs of the developer (who wants to be able to write, test, and debug code as fast as possible). The LanguageAsAnOs? theory seems to be oriented towards developers
Finally, to round out my point, the list above also contains such things as Forth and various BASICs for 8-bit micros. While BASIC might well have been the default "shell" for your AppleTwo or CommodoreSixtyFour--all such dialects of BASIC were truly horrible languages, which I wouldn't want to inflict on anybody.
"Getting work done" almost always involves programming of some generality, or at least tasks which are highly programmable.
"Almost always" is far too strong. Many user tasks; such as playing games, writing letters, balancing a checkbook, producing presentations, downloading pictures off of the digital camera and publishing them on the Web, etc. involve little or no programming at all. At least not programming in the way I think of it.
But there is almost never any gentle introduction to programming. Emacs might be the exception that proves the rule.
Lots of other exceptions. Spreadsheets are a common one, it is often said that MicrosoftExcel is the world's most widely used FunctionalProgrammingLanguage (I will neither agree or disagree with that statement here). Production of document templates might also be considered programming of a sort--no knowledge of a programming language is needed here, either.
Instead of providing an environment with a gentle immersion to programming, you provide contempt for any mere "user" who demands to be able to perform those tasks without immersing themselves in a foreign programming language.
Not at all. I have the utmost respect, not contempt, for a user who wishes to learn programming. Many users, do not. A well-designed OperatingSystem should allow laypersons to effectively use the computer without knowing the guts of how it works.
Folks who drive cars would do well to know how to perform basic maintenance tasks, such as filling the gas tank, replacing a flat tire, or changing the oil. However, most drivers need not know how to rebuild an engine.
Imagine the nerve; a foreigner, a tourist, who demands us he be able to get around a French city without learning the native language, history, and architectural principles! Why, if we allowed mere users to program, pretty soon we'd have casual programmers!
Whoever said anything about prohibiting users from programming (or about erecting knowledge BarriersToEntry?, to keep users away). I never did.
In many people's minds, there is a sharp dichotomy between "users" and "developers" but in reality there is only a continuum. I speak as a user since I am not a developer. -- RichardKulisz
Agree about the continuum. I am a competent developer (at least I, and my boss, thinks so); however when I'm in UserMode? I can be just as lazy as the next guy.
An ordinary driver can learn to maintain their car on an incremental basis. First they learn to replace tyres, then the oil, then the spark plugs, and so on. Everything in the car is Object-Oriented. And this isn't due to cars being made of physical objects since "organic" systems like biological cells, houses and cities are not at all OO. Moreover, the car presents a continuum of complexity to its users. There exists a legitimate and good reason to learn about cars at every step of the learning curve. Additionally, the slope of the learning curve is not steep initially, and only as you get into more complicated repairs do you start needing to know more and more about advanced shop techniques. The ultimate constraints to home auto repair are financial and not intellectual. Most people don't have the money to install a complete machine shop at home.
This is not the case with either Unix or C/C++. One either understands the system internals or one doesn't. Yes, you are able to "do many things" in Unix but that means nothing. To paraphrase: Ordinary people are amazed at how far computer science has come. People in the know are amazed how far it hasn't.
For instance, it isn't possible to inspect and toy with Unix system internals like you can with Smalltalk, even if you have sufficiently high privileges. (Don't lecture me about OS security.)
Similarly, one either understands C++ or one doesn't, I sure as hell don't.
Inserting text in the middle of an argument actually seems to be a common WikiParadigm?. Or at least that's been my experience.
(Unless you have someone who's as good a systems analyst as I am, and as confident in their own abilities as I am, none of the participants ever integrates the thread successfully as it evolves and nobody ever wants to integrate it after it's evolved into a huge daunting ThreadMess. So unless you have me on the scene, it's pretty much an antipattern.)
See "Quote and respond" in HowToWriteAndEditThreadMode.
Things to think about, though not exactly relevant:
[T]here is much to learn from Linux (and Linus), and I'm not referring to the technology which makes up Linux (which contains little that is new, after all).
Self was abandoned in favour of Java due to its lack of a C style syntax. WorseIsBetter and compatibility all over again.
Making a system that replaces the entire OS is *much* simpler now that the GrandUnifiedBootloader exists. But what about the hardware? Isn't it a major headache to have to be compatible with the bewildering array of PC hardware combinations? I hear that something called OsKit can help, but personally I'm designing my own hardware in my CopiousFreeTime ? madness!
This issue became obvious to me when a software tool based on top of Java had a daylight-savings bug in it (due to changes legislation). The time was right on the OS (Windows or Unix), but wrong in the Java engine. But the software tool that used Java was not tested on the Java version that had the fix, so I had to put in a fudge factor. Hopefully next year I can install the newer Java engine, or else someone will have to add another fudge factor.
This is something that occurred to me when I was using RubyLanguage irb, too. In my brief fling with RubyLanguage, my reflex was to install Ruby via Debian's package management system. Silly me! It turns out that Rubyists like to be on the cutting edge, while Debianistas (and package maintainers in general, to a lesser extent) like stable systems. If you want the latest, it's utter madness to try to install Ruby via package manager. Ruby not only has a package manager, but it can handle multiple versions of Ruby as well (in case you're stuck maintaining an old project, but you want to start a new one using the latest in cutting-edge technology).
This got me to thinking about how Ruby isn't the only system that has package management: PythonLanguage, PerlLanguage, CommonLisp, and HaskellLanguage (I think) also have this, as well as many others. And it isn't a stretch to think about how, even when each of these languages reach out to the OS to do things, it's no different than the OS reaching out to the BIOS (or to the computer directly) to do its magic. And if you *really* think about it, each and every bit of code written to do something, is an extension of that language--so Unix is as much an extension of C as C may be a language running on Unix.
While it would be difficult to do, conceptually, there's nothing stopping us from taking a given language, creating a run-time prompt of some sort for it, and then putting it on a computer to run all by its lonesome. Thus, the line between OS and language is indeed a blurry one--at least, it's as blurry as you want (or need) it to be! --Alpheus
There's also the case of AppleScript on classic Mac OS. In addition to being a language in which to script GUI apps, it and Script Editor could also be used as a CLI on this otherwise CLI-less operating system (not to mention MPW and Commando). There was also an app that provided a hotkey popup window thing that let you type in lines of AppleScript.
EditText of this page
(last edited December 7, 2012)
or FindPage with title or text search