Slashdot Mirror
Programming Languages Will Become OSes
Anonymous Coward writes "A couple of months ago, at the Lightweight Languages Workshop 2002, Matthew Flat made a premise in his talk: Operating systems and programming languages are the same thing (at least 'mathematically speaking'). I find this interesting and has a lot of truth in it. Both OS and PL are platforms on which other programs run. Both are virtualizing machines. Both make it easier for people to write applications (by providing API, abstractions, frameworks, etc.)"
A couple of months ago, at the Lightweight Languages Workshop 2002 [http://ll2.ai.mit.edu/], Matthew Flat made a premise in his talk: Operating system and programming language are the same thing (at least "mathematically speaking"). I find this interesting and has a lot of truth in it. Both OS and PL are platforms on which other programs run. Both are virtualizing machines. Both make it easier for people to write applications (by providing API, abtractions, frameworks, etc.)
/ Opcode/Opcode.pm].
/tmp).
Intro, Isolation, Perl
The difference between the two, Matthew continued, is that OS focuses more on non-interference--or isolation between OS processes. The main task of a multiuser OS is to let several users use the computer simultaneously. Thus, it is important that no user can take over the machine or use up its resources permanently. Also, no processes shall be able to terminate other processes, peek into their resources, or do any other things that violate privacy unless it is permitted by the OS security policy.
On the other hand, PL focuses on expressiveness and cooperation. PL provides high level constructs and facilities so that one can write programs in less time and with less amount of effort. 10 lines of higher level PL code might be equivalent to 100 to 1000 lines of machine/lower level language code. Additionally, PL provides means for people to share reusable code through the concepts of modules, shared libraries, components, etc.
As time progresses, OS'es are becoming more like PL. And vice versa. OS now provides more and more ways for cooperation/sharing: IPC, threads, COM, etc. PL now provides ways to do isolation: sandboxing, processes, etc.
However, in all programming languages that I am currently using (Perl, Python, Ruby), none of them had been designed from the ground up to do isolation. Thus, none of the isolation mechanisms really work well.
This article will focus on above three languages. It would certainly be interesting to also discuss Scheme, Smalltalk, Java, and Erlang--however since I'm not adequately familiar with any of them I'll leave the readers to give feedback on these.
Why Isolation In PL?
As people construct more and more complex systems, the need for isolation becomes apparent. Complex systems usually untrusted user-level code that need to be restricted. Several examples follow.
Database systems usually provide some sort of stored procedure. A remote client can connect to the database and triggers stored procedure to be executed. It is important that if the stored procedure crashes or loops, other clients can continue to use the database.
Business applications usually allow users to specify business rules or constraints. Both are basically some simplified high level code. Users might specify these rules incorrectly and the application must ensure that those errors have any unwanted impact.
Web application servers usually allow pages/templates to contain code. Since generally the interpreter itself (e.g. Perl or PHP) is exposed to do the execution of the code, the application must somehow ensure that no templates can crash the application.
Other applications might allow users to specify regular expressions. Regular expressions is actually a language, though a mini one. Overly complex regexes--either specified accidentally or on purpose--can cause the regex engine to loop endlessly doing backtracking.
So, in essence, complex applications are usually a platform by itself, running subprocesses/subprograms (in a single OS process). Thus, this requires that the PL has isolation mechanisms beyond those provided by the OS: like restricting a piece of code from accessing a certain part of the filesystem, from using more than a specified amount of memory/CPU time, from accessing certain functions/modules/variables. Unfortunately, most PL don't have enough of them.
Perl
The two main security models in Perl are tainting and safe compartments. Tainting are mainly for tracing data, so I will not discuss it here.
In Perl 5.6/5.8 there are about 400 bytecode-level instructions, called opcodes. All Perl code will eventually be compiled to these opcodes. print is actually a single opcode. So are open, sysopen, mkdir, rmdir, fork, gethostbyname, etc. To see the complete list of Perl opcodes, see theOpcode documentation [http://search.cpan.org/author/JHI/perl-5.8.0/ext
Two things are apparent. One, Perl opcodes are higher level than machine level instructions or even Java bytecode instructions. Two, Perl is a monolithic beast. Many facilities (like directory manipulation and even DNS-related stuffs) are built into the language. Perl5 is monolithic because of historical reasons. Perl6 will also be monolithic--so I heard--because of speed reasons.
Every single opcode can be enabled or disabled. This is done in the compilation step. If there is a forbidden opcode encountered by the compiler, the compiler will refuse it and compilation will fail. This has the advantage of speed: the cleansed code will absolutely have no run-time speed impact. The disadvantage: one must be careful to compile code at run-time--otherwise untrusted code can be compiled with dangerous opcodes in it.
The Safe.pm is a standard Perl module that allows a piece code to be compiled with a specified opcode mask (a list of opcodes that are to be forbidden). In addition to that, Safe.pm will do a "namespace chroot". It will make Safe::Root0 (or Safe::Root1 for the second compartment, and so on) as the code's main:: namespace. This means that the code in the compartment cannot access variables in the original main:: namespace, so global variables like $/ is not shared with code outside the compartment (Some variables like $_ or the _ filehandle is shared, though).
That's basically what Perl offers us for security. In practice, Safe.pm is not practical. Choosing a reasonable set of "safe" opcodes is not always straightforward. An opcode like open can range from "rather safe" to "extremely dangerous". Perl's open is so powerful and has many functions: it can open a file for reading, for writing, it can execute programs, open a pipe, duplicate a filehandle, etc. You can't, for instance, make Perl allow only read in open. Overriding open() doesn't make it safe, because the code in compartment can always refer to the builtin version using CORE::open(). Moreover, Perl can be told to read/write files without using any opcode at all (for example, using $^I). Thus it is not possible to restrict an unstrusted Perl code from accessing filesystem. To do this, one must resort to using OS facility (like Unix's chroot or BSD's jail).
The show-stopper for Safe.pm: most modules don't work under Safe.pm. DBI, for example. Embperl 1.x uses Safe.pm but drops it in the 2.x versions. Virtually no other web application servers uses Safe.pm these days. Even Perl experts say that Safe.pm is too broken.
Conclusion: Perl has some sort of sandbox, but it works at the compilation step only. It's not very flexible and it's not very useful. Perl is also monolithic and many functions are built into the interpreter. Thus, it is harder to isolate functionalities.
Python, Ruby, Conclusion
Python
The Python language design is very simple and clean. Amongst the security models of the three languages, Python's is the one I like the most. Python security model is capability-based, meaning that: if you don't want a certain code to be able to do stuff, you don't give a reference to the module/function that provide that stuff. Python is also much more modular: the core functionality is much less than that of Perl. For example, OS specific services--like unlink or rmdir--are located in the sys and os module. This means we can more easily restrict access to those services by depriving the code from importing the appropriate modules.
Here's Python's execution model: each code runs in a frame ("a context"). In a frame, there are two namespaces: the local and the global namespace. A namespace is a mapping between names and objects. You get reference (=capability) to objects from a namespace. Every time a variable/function/object/module name is mentioned, Python will look for it in the namespaces. The local namespace will be searched first, then the global. If the name is not found in either, Python will give a NameError exception.
We can manipulate a namespace easily, since it is available as a dictionary. We can even execute a code and give it our custom dictionaries to be used as the code's local and global namespaces. This way, we can limit what objects are available to the code. That's basically how the security model works in Python.
Actually, there's a third namespace that will be searched when a name is not found in a local and global namespace: the builtin namespace. The builtin namespace contains basic functions like open, exit, execfile. Most of the Python's builtin capabilities are provided through this builtin namespace. The rest is creatures like print or exec which are statements, not functions/objects.
rexec is the standard Python module to do sandboxing. It basically does what is explained above: run the sanboxed code with a custom local and global namespace. Additionally, rexec creates a custom builtin namespace and provides a safer substitutes for functions like open or __import__. This way, we can tell rexec to forbid the untrusted code from opening a file in write mode. Or from importing dangerous modules.
rexec is pretty flexible and indeed has been used successfully in several applications. Guido's web browser Grail, for instance, allows running Python applets. However, rexec seems to be not flexible or fine-grained enough, because Zope chooses not to use rexec. Instead, it uses its own home-growned module to do restricted execution.
There are several things that rexec can't do. Resource limiting, for example. To do that you need to resort to the OS (like using Unix's setrlimit). Also, since Python does not have private attributes, you can't give an object to an untrusted code without the fear that the code will use the Python reflection mechanism to "peek into the guts" of your object (and from there gain references to other objects). There are two separate solutions to the last problem: the Bastion and mxProxy C extension modules, which essentially provide private attributes.
Conclusion: Python has a nice and simple security model. However, rexec cannot do all kinds of isolation that one might need, like resource limiting. Guido once also said that rexec is not tested enough and it might contain security holes.
Ruby
One of the main goals of Ruby seems to be "to replace Perl". In that respect, it has copied many Perl features. Tainting is one of them. In Perl there are two running modes: tainting mode on (-T, setuid) and off (no -T). Ruby extends this concept a bit by providing four different "safe levels" (indicated by the global variable $SAFE). The different safe levels is as follows.
Safe level 0 (default mode): no tainting is performed.
Safe level 1: tainted data cannot be used to do potentially dangerous.
Safe level 2: in addition to level 1 restriction, program files cannot be loaded from a globally writable locations (e.g. from
Safe level 3: in addition to level 2 restriction, all newly created objects are considered tainted.
Safe level 4: in addition to level 3 restriction, the running program is effectively partitioned in two. Nontainted objects may not be modified. Typically, this will be used to create a sandbox: the program sets up an environment using a lower $SAFE level, then resets $SAFE to 4 to prevent subsequent changes to that environment.
It's evident that, as with tainting, the safe levels are primarily concerned with data security and are not very sandbox-like (in the sense of "isolating subprocesses from another" sandbox). Matz confirmed this in the ruby-talk mailing list by saying that Ruby currently does not have any sandbox yet. Running a code in safe level 4 is usually too restrictive to be practical, plus it does not provide enough isolation.
The problem with isolation in Ruby is that all objects are accessible from any code through the ObjectSpace facility (including the code running in safe level 4). This is of course in direct conflict with the capability concept, in that you don't give a reference/capability unless necessary. However, Ruby does protect an object's attributes and has a #freeze method to make an object becomes read-only.
Conclusion: Ruby doesn't have a sandbox (yet).
Other PL's
Java has a sandbox security model and a bytecode verifier. Tcl basically has the same. Erlang is evolutionary more advanced in providing isolation, in that it has a notion of "PL-level processes" (a process is isolated in all ways from another).
Conclusion
As people construct more and more complex applications in PL, PL's are required to have adequate security/isolation mechanisms. Current PL's in mainstream usage do not have adequate security mechanisms, so programmers are often forced to fall back to using facilities provided by the OS. This has drawbacks such as lack of portability and reduced efficiency. There will perhaps be new PL's designed with isolation as one of their main goals--or current PL's might be improved/redesigned--so hopefully this requirement of having a "multiuser PL" will be fulfilled in the future.
About the Author:
Steven is a software developer residing in Bandung, Indonesia.
Seems to me that this is old hat. Lisp has been an OS since the 60's. We just don't feel the need (often) to call it that.
Already happened: Microsoft BASIC ==> Microsoft Windows
Emacs is Emacs Lisp.
Emacs is an Operating System.
Emacs Lisp is an Operating System.
QED
Just remember the past. Oberon was an OS an a PL at the same time and I think most of the readers didn't ever heard about it...
my TRS-80 had BASIC as the OS
mozilla has proved how sucessful that approach is.
If you use Emacs, you have a programming language, OS, and editor all in one happy package.
I can't say that I don't give a fuck. I've just run out of fuck to give.
... the home computers of the early '80s didn't really have OSes, they had programming languages. You'd boot a BBC Micro and it would fire up into BBC Basic - with a few * commands for file system manipulation. Or you'd boot a Spectrum and you'd get the same: the name of the system and a prompt to begin typing your program.
Real Daleks don't climb stairs - they level the building.
Whoever gave this talk needs to go back to CS 101.
A single machine could have multiple languages co-existing for different tasks. Some of these tasks require quick and dirty scripting, some require high performance and some other application programs might concentrate on object oriented features and such.
The operating system, on the other hand, is typically only one per machine and performance and stability might be the major considerations (other than compatibility with the popular applications around!)
All your favorite sites in one place!
And you have a Lisp Machine.
All mathematically the same!
Hmmmmm.
This is funny. This exact thing appeared on OSNews earlier this week... and was promptly followed by an unrelated article entitled "Future of Operating Systems: Simplicity". So which is it, simplicity or programming?
Bill Gates and company figured this out when Java was released. This article is much more interesting that that simple observation, though.
Glad I didn't throw out my C64!
"Ceilean Súil an ní ná feiceann..."
I want an OS that will write apps for me. Until then I don't think there will be any more than incremental improvements to any software.
I guess Mr. Flat (what a name!) hasn't ever heard of the LISP Machine..
Programming Languages become one and the same as Operating Systems. Then Microsoft will come out with "FrontPane," the WYSIWYG OS editor that allows everybody and their brother to create shitty OS interfaces inside of an editor, while writing autrocious code "behing the scenes."
Shittier than Luna, that is...
How are you going to keep them down on the farm once they've seen Karl Hungus?
Historicaly, which come first ? Operating system or PL ?
But this idea has been around a long time. Remember the plethora of 8-bit computers back in the 80's that "booted" to BASIC?
Can you say C-64 redux?
I though web browsers and OSes were the same thing.
-Peter
OSes and programming languages have some superficial features in common, but they are totally different concepts. This is so manifestly obvious that I'm not even sure how to argue the point.
However, Mr. Flat's suggestion that languages need better isolation capabilities is a good one. It all goes back to Fred Brooks' point that one in ten programmers is a superstar. I think isolation facilities in a programming language allow the superstar to set the rules that the other nine programmers must follow, making the system more coherent by the guidance of one mind.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
FORTH was and still is such a combination. It's compact, easy to implement and incredibly fast and felxible.
Stick Men
Microsoft is always pretty quick to recognize new products that could threaten windows dominance. In some ways platform independent languages (most scripting languages, Smalltalk, Java) already implement their own OS on top of the OS they're already running on.
This astute piece of observation has made me become far more transcendental. Now I realize that we're all just connected.
Yet I shall take this wisdom even further: the digital universe is based upon everything being opposite, where you have everything and nothing.
That's deep, man.
-- We live in a world where lemonade is artificial and soap has real lemon.
For one the wall between OS space and user space is there for a good reason (security) and second different people like to use different languages, and you'll lose a good part of your developers by forcing them into the straightjacket of a single language for a certain os.
it's been tried before (smalltalk, java) and failed, for these and a whole bunch of other reasons.
MP3 Search Engine
...chroot should do the job for all you evil buffer-overflow script kiddies out there
"Simon Says, Fuck You" - George Carlin
Actually you see this reflected in modern systems designs such as Cocoa/OC or Java. They are in themselves virtualized operating systems. Adding classes in these adds reusable functionality to the overall system, much like adding functions in Lisp adds functionality to the system.
Like java... I think a likely evolution will be towards a single VM that runs all your programs instead of the one VM per app generally used now. More and more of the process switching and memory management will be built into the VM's probably to the point one day where java VM's become operating systems in their own right and only need the underlying OS for drivers to talk to the hardware.
C OS - Every single task you want to achieve has to be split into fifty bite size actions.
COBOL OS - The literati's dream OS! No longer must you click and drag, but instead type bizarrely syntaxed English to do your work! PROGRAM OPEN CALCULATOR AS NEW PROGRAM
Perl OS - An open source OS worked on by a bunch of extremely crazy (but clever) bearded anoraks. You can do EVERYTHING in one click or one line of code. Oh, face it, it's just the future of Linux.
PHP OS - This OS was originally the shell for Perl OS, but some wimps who couldn't work out the Perl way of doing things decided to turn it into their own 'paint by numbers' OS. Unfortunately you can only access the Internet with PHP OS, no off-line facilities are available.
C++ OS - A simple upgrade to C OS. Still just as complicated, but the ++ makes it cooler to use and adds a host of useless features that are non standard across all implementations. Besides, C OS is for old fogeys.
Python OS - Supposedly this exists, but since no-one cares, we won't go into it.
Ruby OS - EVERYTHING is an object. Want to open your calculator app? calculator.open; please. Need to enter some numbers? calculator.buttons[8].press; It's long, tedious, but at least it makes logical sense.
BASIC OS - Joe six pack's answer to operating systems. This is Microsoft XP in the future. Anything can be done with point and click, but it's slow, crashes a lot, and is totally lame. Oh, I'm already talking about XP here aren't I?
mogorific carpentry experiments
If any programming language/framework has a chance it will become an OS it is .NET.
And Java is half an OS already, it has its own threading moodel, has memory management etc. Though frankly I believe this paradigm of PLs becoming OSes will be first be seen on handhelds etc. Note that many Cellphones run Java etc. (though now sybian is more commoon).
.ACMD setaloiv siht gnidaeR
Maybe it has already happened, but I haven't heard of it.
Yep. The bare truth!
Plot: In the year 2003, the technologically-starved masses depend upon the United States government-manufactured item Microsoft Windows to exist and manage their day to day activities. But in the midst of an investigation, a hacker uncovers the chilling source of the product...
Microsoft Basic is Microsoft Windows!
*louder*
Microsoft Basic is Microsoft Windows!
*shouting at top of lungs*
Microsoft Basic is Microsoft Windows!
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
What are you talking about? The Slashodot crew any you only wish you guys were gay. Gay people are so much cooler. ;)
When it was ENIAC, somebody wires. Then somebody even wiser put that 'wiring part' into solid-state, electronic controlled one. That's the 'machine code'.
Then, it is the punch card era, and then somebody think it is better to write words other than bunches of 1 and 0's, hence, we have assembly language, and it comes with the operating system.
After that, somebody thinks that writing assembly language is too cumblesome and too hard to learn for some people, for example, your workmate and me, then, higher-level languages like C and FORTRAN arrives, and it comes with the operating system, yet, machine-code level tools no longer comes with the majority of the machines.
Then, when it is the year that most of the users isn't programmer, the programmer make the computer comes with programs that let you select task rather than instructions to do things, and results in 'shells' or 'command.com' (for win'ies.), it comes with the OS at that point, and programming tools are disappearing from the original package.
When it was the year that too many computer illiteracies want to learn and use computer, yet some wise men write programs that allow a user to use a mouse to click on somewhere to do some job, and hence it comes to the GUI era, and it is shipped with computer, computer no longer comes with command-line tools.
Now that the people are way too lazy to do the job even with assistance with the computer, they actually want the comptuer to do it for themselves, some eventually somebody wise enough will develop a system that allows the user to key-in the objective and the computer will automagically do it.
Don't see the analogy?
Every operating system is just some sort of translator that translate your use of language (e.g. BASH command) into machine readable thing. however, note that the above sequence need not be step-by-step completed, i.e. it may go something like this:
User command --> C program --> Machine code instruction.
In general, though:
MACHINE CODE <-- computer level
ASSEMBLY LANGUAGE <-- (e.g. AT&T assembly)
STRUCTURAL PROCEDURAL LANGUAGE (e.g. Pascal)
SCRIPTING LANGUAGE (e.g. PERL)
COMMAND-TYPE LANGUAGE (e.g. SQL)
POINT AND CLICK (e.g. X, MacOS, etc.)
DESCRIPTIVE (Natural human language, e.g. English)
Correct me if I'm wrong, follow-ups welcome.
Read the previous message people.. LISP/EMACS has been mentioned over 300 times.
How can you NOT see that someone else already posted some shit already..
This is supposed to be a fucken discussion not "blalblab LISP.. blalbla EMACS"
talk about USEFUL things... I dunno like if an OS was built around perl and discuss how easy it would be to setup yer various unix jobs. Or if every form of data on your computer was saved to XML instead of all the propietary file formats nowadays.
or if every program on yer computer was all written in one language including the OS itself.. I dunno wahtever...
but make it a fucken interesting discussion instead of Lisp or EMACs does this.
if you wish to talk about LISP or EMACS... whip out the technical docs and fucken tell me all the system hooks that LISP or EMACS uses in it's VMs to qualify it as an OS.
...the partitioning of computer environments into applications, OS, "drivers," "libraries," etc. etc. is arbitrary, cultural, traditional, etc. To some extent it's also based on modularity considerations, and to some extent on marketing/commercial considerations. There's no fundamental logic to "the way things are."
A few decades ago, MANY environments blurred the distinction between OS and language: FORTH, MUMPS, SMALLTALK, and, indeed, most early versions of BASIC, to name four.
The traditional textbook discussion of an OS ("provides four interfaces, to the filesystem, to devices, to applications, and to users") is just a discussion of what IBM evolved in the sixties or thereabouts.
Incidentally, the very name "operating system" indicates the original rationale and function of these pieces of software. They were intended to automate the functions that previously required the manual services of an "operator," thus increasing utilization and decreasing payroll.
Another example of the arbitrariness of the term "OS" is the way in which various applications programs are now considered to somehow be part of the OS. In Digital's glory days, these were sometimes referred to as "CUSPS"--Commonly Used System Programs. Is grep "part" of UNIX? Is Windows Explorer (not Internet Explorer, but Windows Explorer--the application that displays directory contents and that "start" button at the bottom of your screen--Windows' graphical "shell") part of Windows?
At one point Apple said Hypercard was "systems software." Perhaps iTunes is "part of" OS X?
"How to Do Nothing," kids activities, back in print!
That is why my dream is a funcional, relational OS -- something built around a Scheme or Lisp D, as in Date and Darwen's The Third Manifesto.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Obviously, I think most of us with a reasonable schooling in software would agree that applications written in C++ are the biggest security threat for PCs today. This is why you've been seeing more and more Java based applications on the PC lately. Most of the C++ vulnerability comes from a single, well known, and often exploited bug in the Windows C++ virtual machine. This bug allows C++ programmers to access protected and private data that is SUPPOSED to be secured by the C++ virtual machine. Here's a simple example of a crack that would allow a C++ programmer to access improperly secured data:
// Forge a pointer to peek inside the class
.Net framework as a new standard and make big cash off of its widespread adoption. Another way that MS will profit from this security hole is by pushing their dreaded Palladium scheme on us. Palladium, put simply, is just a hardware solution for this exact sort of security issue. Meanwhile, we consumers sacrifice our privacy through insecure software so Microsoft, Intel, and AMD can reap big profits sometime in the future.
Let's say we have this class called PersonalFinances:
Class PersonalFinances
{
private:
char creditCardNumber[16];
};
To bypass the Windows C++ security manager, all we need to do is write some code like this:
Main( )
{
PersonalFinances finances;
char *cardno = (char*)
printf("Stolen credit card number = %s\n", cardno);
}
Simple as that... we have stolen "secure" data. Curiously enough, this code sample came from O'Reilly's "Learning Java" book. This book was first printed in 2000, which means that this critical security bug has been known for over 3 years! I find it quite unbelievable that this lack of response (from Microsoft) is tolerated in the software community. Why haven't they responded? Simple... MONEY. Rather than maintain old code, Microsoft would rather push their new
If you are fed up with these monopolistic profit schemes, this is what you do. Start or support an open source Windows C++ virtual machine project. A port from the Linux VM should be possible.
We DEMAND better protection of our privacy!!!
color flashing, thunder crashing, dynamite machines.
Etlinux takes a tiny kernel, then adds radically stripped-down versions of the standard demons, rewritten in TCL!
This might in fact be your daddy's Linux: 2.0 kernel, and the TCL is a very-stripped-down one. Why? Reduced resource requirements: it'll run on a 386sx with 2M ram and 2M disk/flash!
More features:
- embedded cgi-capable WEB server
- a telnet server
- an email server, with the ability to execute commands sent by email from a remote site
- CORBA support
- easy-to-use remote file management
- a flexible package selection scheme, allowing an easy customization of the system
- source code available for every component
Saying that OSes and PLs are the same thing is a silly semantic argument, and it strikes me as an example of black and white thinking. The fact is, there is some overlap between what OSes and PLs typically do, so sometimes there is a bit of a grey area where a PL is doing an OS-like thing or vice-versa. But to say that "I cannot draw a hard and fast line between the definition of a PL and the definition of an OS therefore they are the same thing" would be wrong. OSes and PLs are different abstractions that serve different purposes, and it seems likely that there will continue to be a conceptual distinction between the two.
-a
He with the most distinctions at their death WINS!
So now I'm suppose to erase favored distinctions rehashing it all.. again.. and again.. and again... BULOCKS! Its C/C++ and no more updates...
It so happens that I know a bit about Smalltalk so perhaps I can help a little.
Smalltalk was originally the entire system on the original hardware. Indeed, Dan Ingalls said back then (paraphrasing, I don't have the exact quote handy) "An operating system is a collection of things that don't fit into a programming language. There shouldn't be one".
The reality of commercial machines caused those of us interested in using Smalltalk to accept the limitations (and it must be said, benefits) of OSs. Even so, there have been several occasions where an attempt has be made to use Smalltalk as the entire system: the Active Book and the Momenta machines for example and more recently the Interval Research MediaPad (where the RTOS was written in Smalltalk).
These days I'd be inclined to 'soften' Dan's statement to something like "An OS is a collection of things underneath the language. There shouldn't be any way to tell the difference". That is to say, the language ought to be able to make full use of anything available without having to burden the programmer with wierd crap.
Does Common Lisp handle security? No.
Does Common Lisp handle network connections? No.
Please tell me how Lisp is an OS.
I note that the languages he mentions as the ones in which me most often works are substantially scripting languages and so their deep roots into the OS are to be expected.
This is not what I thought I would find before I read the article. I thought I would be reading about a Smalltalk environment which really IS an OS abstracted on top of an OS. Or a Java IDE perhaps
I would say that old languages like FORTRAN, PL/1, C are all quite separate from the OS that supports them. Indeed C was abstracted by design with its run-time libraries holding the only knowledge about the environment in which they work.
More modern languages are seeming to migrate closer to the OS that holds them. But I would argue this is not a Good Thing because it binds a language too close to a given OS designer's viewpoint of what is important and how to look at the mechanisms under which data are displayed.
For the continued health of human-interface design, and of operating system design, I would hope that languages continue to hold the environment at bay and deal with abstractions, letting interface libraries or processes take care of display and human interaction.
The way people use computers is determined by the whole of the environment they are confronted with... and generally no matter what kinds of interfaces people are presented with they will start gluing them together to get various tasks done. This is a pretty universal thing, but unfortunately the history of computing has ended up producing a rigid user/programmer distinction (although the *nix community has been doing a lot to blur the line)
No matter if you are using a GUI or a traditional programming language, the end result is that you are instructing the computer to do something. The thing is tho is that "programming" is so time consuming and difficult (compared to the GUI) that generally people only switch into that mode when they want to do something over and over again. Yet looking at the way people use GUI's, they do the same actions over and over again. Why? Because its impossible to script most GUI's in anything like an quick-and-easy fashion, or to combine elements of different programs into "meta" applications.
People have been talking about more holistic environments for years, but inevitably these projects fail. IMO its because people keep trying to use languages that are too low level and are too unstructured - causing enormous efforts to be expended on simply converting data formats or wrapping APIs and such, or chasing down buffer overflows, and not enough time developing programming environments that can program and extend themselves.
Currently I'm working on such a project based on the mathematica programming language.. stay tuned...
I'm still waiting...
Dont eat yellow snow
Once I worked for ICL, a British computer company.
One of the operating systems we had, VME/B, had strong support for several programming languages, including what today the nuxi world would term its shell language.
These languages all used the same architectural calling conventions, so one could call shell language as a function from S3 (the main implementation language for the system, based on Algol 68)
And call Fortran from shell.
There was no concept as limited as "main". A program was just a library, once loaded any of its functions could be called.
As a former colleague said in the early 80s, "the best that can be said about unix is that it only put operating system development back by 20 years".
Steering wheels and tires are the same thing.
Both are required for the succesful opperation of a car. Each require steel in their construction for structural reinforcement. In a pinch, and with a little engineering, theoretically one could be used to replace the other.
But most striking in their simularities: Both are round.
The Internet is generally stupid
"The network is the computer" -- Sun Microsystems
"The programming language is the computer" -- Matthew Flat
Am I the only one who thinks this is funny?
In the long run, we're all dead.
Only on Slashdot.
And still they wonder why Linux isn't a desktop platform...
Argh, this paper starts with an interesting idea, that PLs are more like OSes then we realize it, provides some genesis for the idea, but FAILS to back it up..
All of his examples, the bulk of the paper, are examples of how the RUNTIME system restricts the PL. He talks about the runtime system security model and somehow this is supposed to extend to the definition of the programming language? No, this is not how it works. The runtime system, the sandbox or whatever you call it, is a restriction defined seperatly from the language itself. The JVM is defined seperatly from the Java language. That's why products like JET exist that can compile Java code to something other then bytecode. Because the runtime enviroment is not defined in the language. You don't have to have a security manager, like in perl, you don't have to support a trusted mode in your perl runtime. It's a feature of the runtime, not the language.
The runtime, by definition is like a mini-OS. Usually, a vm runtime (for perl, java, python, etc...) takes non-native instructions, parses them and translates them into some sort of binary instruction. Since there is no processor that can execute perl natively, this is how it works.
Neat idea, bad paper.
To paraphrase "the tao of programming":
"I don't know whether I am an operating system dreaming that I am a programming language,
or a programming language dreaming that I am an operating system!"
Did you know that there were parts of the Lisp Machine kernel that were not written in Lisp? Small sections were written in assembly.
Systems architecture (and to a certain extent application architecture) revolves around creating "environments" where other applications operate, (note emphasis). Architectures provide services to these applications, which in turn may provide different services to yet more applications (components, web-based solutions, etc.). Thus you can argue that by sitting down and designing and implementing a specific or generic purpose architecture, you're creating a "mini-OS". That much is true. But the OS is simply a lower-level architecture than, say, Java or COM or .NET. It's a more complicated and extensive one, but one nonetheless. The stuff you do with a programming language (or as they like to be called these days - platforms) is essentially a higher-level abstraction than the real OS happens to be.
So we can argue then that we're moving towards the platform concept where things are interconnected via well-defined interfaces and entry points (that's your APIs) where the OS itself is just another component.
Hmmm. Well, harking back to days of yore, I recall that punchcards were the basic in/out system of computers.
I suppose that one could look at the article at hand in terms of whether or not punch cards contain linguistical features (language support) or systemic features (operations support).
As such, I'm not all that sure that the method of transfering information from a punch card was/is the same as decision making operations utilized by the machine itself.
Call me crazy, if you will, but it seems to be a text/context dichotomy to me, where one cannot have a PL without an OS, and vice versa. That is, they go hand-in-hand, and each are somewhat inherrent in the definition of the other.
But I'm no computer scientist... =)
Was your intent to sound crazy or stupid?
So what Mr Flat is really saying is that he hasn't looked at Eiffel, Ada, OCL or any design by contract work.
This really is a bizarre article that most first year students would get marked down for.
An Eye for an Eye will make the whole world blind - Gandhi
Take a look at SavaJe. It is a JVM that is also an OS.
The truly wise path to go is to define an OS/bytecode combination, so that (in a very LISP-like way) security is accomplished by "thought-controlling" programs rather than action-controlling (the MS/Linux model).
What I want to know is this: Is the LISP bytecode the best, or should a more modern one be used? JavaVM?
You mean that programming languages are going to get even more bloated and overly complex!?
Bleah. Count me out.
What happened to the idea of modularity? Programming languages shouldn't be OSes. They should have access to a modular interface to different OS elements. But now, "modern" languages include all kinds of crap, like GUI code, that should be kept in nice, modular libraries. You know, so that you, the coder have choice.
The cake is a pie
Anybody who's been programming long enough should have already come to this conclusion.
If you ignore enough details, interpreted languages like perl and gawk are similar to OSes. Those that are integrated with a programming environment, even more so; the RSTS/E Basic environment was a language that worked as an OS. VAX/VMS included interpreted DCL, and thus was an OS that worked as a language.
However, compiled languages are fundamentally dissimilar to OSes, because the compiler is not needed to run the program once it's compiled. Your OS is not as easily dispensed with!
The best attempt at isolation at the language level is probably Java. The internal security architecture is rather complicated. And even after half a dozen years, Java still does not provide anything like "ulimit" and I wouldn't trust it to isolate arbitrary code within the same VM.
Ironic this post comes at the same time of Cringely's comments on the subject. Now, not only am I a solaris admin, I guess I'm also a Forth admin!
Democrats and Republicans only disagree about how to enslave you
Very ridiculus indeed.
Did anyone in here bought a programing language and install them lately because he/she is upset at M$?
Come on. Wake up.
Go back to gramma school maybe more appropriate.
Something has some parallel features/goal does not means they are the "same".
Like a chair to put *me* on, and the table to put *computer* on. Since they're both support objects against gravity, they're the same.
I see more in common between DBMS's and OS's than languages. OS's must keep track of a bunch of stuff. User lists, process lists, memory allocation areas, disk section limits, etc, etc.
This is more database territory than language territory it seems to me. I see too many applications that reinvent the database from scratch or using wimpy, tangled array thingies. If you don't like database API's or features, and that is why so many of you reinvent your own, then lets look at DB API's and languages (includind SQL) and fix them.
IBM's AS/400 allegedly uses a RDBMS for many of its OS functionality, I would note. I have not used it extensively, but it usually gets high praises from techies who have.
Perhaps these "OS's are really X" arguments are ridiculous, but a database is as good a candidate as anything.
Table-ized A.I.
Closures are traditionally OS-level services?
Multiple dispatch is traditionally an OS-level service?
Please explain how Lisp (compiled to native code, compiled to a byte code or interpreted) is an OS.
Bah. It's an interesting concept but the fact is we evolved OSs and programming languages as *layers*, one on top of the other, to increase efficiency. The point is that everyone on some platform (say NT-based) has a common set of interfaces. However, to program NT I don't need to know all of the windows API calls unless I really need to delve into them. I can use C++, or run IDL, or maybe even code some assembly. If each was its own OS, I'd have to reboot into that OS rather than switching applications, so having a single entity would be very ineffective for any real engineer.
A Programming Language Runtime environment might be the equivalent of an operating system, but not a Programming Language itself.
I see alot of people getting upset at Mathhew without having read the article. For them, and for those who are reading in diagonal, I'll summarise the important point here.
At LL2 Matthew Flat posed that, while OS's and programming languages both support application development, by providing libraries of function calls, their difference in focus fundamentaly sets them appart. OS's focus on isolation of code, for security and for stability. Programming languages focus on cooperation, and try to maximize code reuse and efficiency.
Basicaly, OS hacker and the PL hacker have alot to learn from each each other. They would win at from cross-pollination between the two fields. Matthew then proceeded to show his implementation of what operating system concepts would look like in a programming language, by demoing DrScheme, a programming environment which can run (and debug) itself recursively.
This post was compiled with `% gec -O`. email me if you need the sources
it is not funny, it's old and played out, i wish i could mod... i would mod you down to -10billion, STUPID.
How about a processor's native language? Thanks to the advent of Instruction Set Architecture, the ISA exposes all the functions and programming environment of a particular architecture. Could this be considered an "operating system". I don't believe so.
An operating system does more than just memory and process managemnt. An OS must also manage things that make computers useful...like user accounts and permissions, driver interaction/abstraction, auditing...etc.
Applications are just that. They are developed using a language as a tool, but what application developer wants to handle traditional OS functions like user account maintenance, driver interaction...etc? That seems like alot of work to dump on an app developer.
While languages COULD be an operating system eventually, currently they are not...and won't be for some time to come.
-ted
Java OS - True object orientation meets platform-independent code. Boot once, run it on anything. However, it takes 10 seconds alone to start each application's virtual machine. Early benchmarks indicate cold program starts of the Mozilla browser approaching the 60 minute mark on a dual Pentium system. Future benchmarks are planned and will be measured using a sun dial.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
Sorry, an OS provides access to hardware. It schedules every task on the computer. It provides IRQs, schedules memory access, etc. A programming language only provides librarys to make system calls to the kernal. An oS is also not equal to an environment (such as perl or Lisp).
Lisp Machines are not the Lisp language as it is known today or for over a decade.
Lisp Machines have security (better than Unix or Windows). Common Lisp does not offer this security as part of the language spec.
Your logic is similar to saying C is a OS because of Unix.
You should take your advise.
In my eyes, an OS is more like a huge dynamic library than a programming language.
Sorry to be a little sarcastic, but the notion of programming languages as OSes is old and familiar to everyone who used (especially micro-) computers in the 80's. Basic, Forth, Smalltalk, Lisp, mainframe assembler,... even Unix was conceived as a set of language as much as an OS.
The remarkable thing is how people have accepted OSes that do not work like programming languages: MS-DOS and its Windows brood being the most common examples, though many other firms have produced non-programmable (and non-abstractable) OSes in the past: IBM OS/400 being one wonderful example that still gets the Pavlovian juices flowing. Brrrrr.
The question is not about "mathematical identity". If that's all that matters, I can say that people will eventually become sweet corn. We are, after all, mathematically identical at many levels: consider the structure of living cells or organic molecules.
The question is how we build and use tools to hide and digest complexity. We program by creating models. Models encapsulate complexity. Can the OS do the same? If so, it's a programming language. Does it impose a single static designer model? If so, it's a crippled OS.
Sig for sale or rent. One previous user. Inquire within.
All fine and dandy, I'm waiting on Quake, the O/S
Talk about realtime fun with objects!
Bah.
"Skill shows through where genius wears thin." -Wittgenstein || Religion: uniting aviation and architecture.
Yes, be we want OSs to get LESS bloated, not more.
My beliefs do not require that you agree with them.
Pick systems were a database, an OS, and a programming language, all in one. It was a very cool system to work in.
I mean, minivans and SUVs are practically the same thing given how most people use them, but that doesn't mean that all SUV drivers are going to switch to Minivans.
.NET, the stuff in CPAN are equivalent to OSs, then that makes sense. But the language itself is not an OS.
Besides a programming language does something that an OS is never supposed to do, make things human writable (and hopefully readable). Back in the days of DOS you could say people coded to the OS as much as the PL (especially if you were talking about writing ASM) but today they are vastly different.
Another difference is that the OS does it's job in real time, while a PL doesn't need to.
If you want to say that programming 'environments' like the Standard Template Lib, the JVM,
autopr0n is like, down and stuff.
Modern programming languages can perform some of the safety features that operating systems provide. Many functional languages "can't go wrong". (meaning the compiler can prove a program does not access memory outside of its own space). Some languags like value Microsoft's Vault programming language can make sure an API is used properly. Check out Kernel Mode Linux for an example of how a "safe" scheme program can be speed up by executing in kernel space.
A programming language is essentially an abstract way of generating machine code. Machine code, in and of itself, is not a on OS. An OS is essentially machine code that abstracts the hardware.
A programming language does not abstract the hardware, it abstracts the machine code
Now if you use a programming lanuage to write an operating system, then use that same programming language to write programs for that operating system, it may *appear* that the programming language is the operating system.
But only until someone comes along and uses your programming language to write their programming language to run on your operating system.
Linux is written mostly in C. C is not an OS
Cube On! (http://stores.ebay.com/PuzzleProz)
Linux PL - You can specify only the specific functions, objects, etc needed and thus makes programs very small and compact. Several "flavors" exist, only a few of those are taught in schools. However, the language is highly customizable...even to the point of completely changing what every built-in function does. This will result in several local dialects of Linux PL, some of which are only known to one person: the geek that made it.
Mac PL - Very easy drag and drop interface...and has lately actually just added a Mac PL GUI to a version of the Linux PL...so basically, see Linux PL.
Windows PL - Easy to use, save the random crashing of the compiler. Also, very slow. Some things, whether used in a program or not, have to be included to compile (one of these is a web browser). Essentially, just drag and drop what you want and add a small bit of code to each object for a fully functional program. People that only know how to program in Windows PL have the nerve to call themselves programmers, even though they do not understand many programming concepts. To sum it up in two words: Visual Basic.
Microsoft was threatened by the java api. You only have to use the Java VM and on that platform your software doesn't have to use the windows api anymore. Takes away the advantage of developing on a operating system with a rubust api.
Ok. So the dude thinks that Perl should now be built to operate as an OS?
Seems silly to me. I agree that there could be an interesting use for a high-level language that is completly independent upon the underlying OS or be the OS, but I don't think the languages he discusses are going to work.
Perl is a scripting language that is a bastardized version of every other language. I love perl, so don't think I am bashing Perl. It does a great job at what it does, but making it secure enough to run a multi-user OS is crazy. Look at how strange it does object-oriented stuff, it's ugly. I just think retrofiting a language to do something that it was not ever designed to do is wrong.
If you want a high-level language that is the OS and also the language you write user applications in, you better create a new language. Java is the closest I have come across that could run as an OS.
Start from the ground up and build a high-level language that handles, printing, DNS, user authentication, the file system, and every other thing the current OSes handle now as well as provide a kick ass development environment for application programmers.
Some day we probably will have a language that can do everything but it won't be Perl, or will it?
LoRider
This is EXACTLY why RMS demands the nomenclature "GNU/LINUX". Linux is a kernel, but GNU is what people actually use.
... text editors will also become operating systems.
Oh.
Wait.
Emacs already *is* an operating system.
Eloi, Eloi, lema sabachtani?
www.fogbound.net
1. Boot computer
2. Hit 'shift' at lilo prompt
3. type 'init=/bin/bash'
Wait, am I missing something? Aren't OSs already a subset language of full "programming languages" (that is, lambda calculus)? And all these languages, imo, are just using what has been available in lisp for now near 40 years. Programming languages haven't _improved_ worth a jack since then, though maybe they have become more _efficient_ (corporate whores!). lol
More than languages becoming OSes, what it seems to be happening is that application servers (specially J2EE ones) are starting to offer facilities that were traditionally part of an OS, therefore creating an OS-independent layer that contributes to commoditize the traditional OS even more (at least for server-side biz apps).
Just take a look at the internals of some of them (ie. http://www.jboss.org), providing component life-cycle mgmt, pooling, transactional services, messaging, directory services...
The "language as platform" is a nice academic idea, but it is not about to become reality any time soon.
The problem is that the people who build such things are usually evangelists for their One True Language. PARC's version of Smalltalk, Symbolics's version of LISP, and Wirth's Oberon are classic examples. Nobody uses them any more. Sun started down this road, but, fortunately, was forced by the success of Java as a language to back off from Java as an operating system. (Remember all those JINI/JXTI/Java machine announcements?)
Interestingly, the big win for programming systems tied closely to the OS is in the non-textual components of programming. "Resource editors" and screen design tools are more closely tied to the underlying environment than textual languages. Such tools have achieved more acceptability than the closely tied languages and operating systems.
I wasn't aware that C++ or Java automatically handled a disk's file structure. Cool
A similarly baseless comparison would be "Novels and dictionaries are the same thing, mathematically speaking, since they both have words."
A programming language is something used to build (read: design & write) a coherent body of logical statements (read: code) that could be set in motion (read: executed) usually with the goal of reacting to its environment (read: use input & generate output). On the other had, an operating system, however it came to be, is something previously written and ready to execute and perform input and output functionality. The fact that it has API's that other executing code can use is analogous to a book having page numbers that can be referred to by other books.
Of course, that distinction can get muddled when looking at script languages. Script languages seem to be used more for queueing commands to programs than for being individual persistant programs, since they aren't often directly interactive. (By that I mean they are passed or read certain attributes at the start of execution, and quit when their goals are accomplished.) In this way, they are more of a to-do list for instructing other, whether against an operating system or some other program like a web or database server.
And yes, the line between clear-cut programming languages and clear-cut scripting languages is getting blurrier. However, the results of both can be split along behavior between 'script-like' and 'interactive', regardless of how they were created.
Too make a long reply short (too late), operating systems are created using programming languages, but they are specific things that actually accomplish specific objectives. Programming languages are merely constructs for creating a variety of things to accomplish various objectives.
R: That voice. Where have I heard that voice before? B: In about 365 other episodes. But I don't know who it is either.
well, the 1 does fit through the 0, even though it is larger.
Both Apples and Oranges are platforms for seed distribution. Both are fruits. Both make it easier for people to live (by providing vitamins, minerals, etc.)
See JSR-121 http://jcp.org/en/jsr/detail?id=121. (Note this JSR is in public review -- please provide feedback.)
Operating systems that virtualize hardware and allow different binaries to run will always exist. However, that doesn't preclude programming langugages from providing some of the same OS-like features to their programs.
Isolation is a powerful concept, and one that hasn't really been taken advantage of in the past. (Pilot/Mesa and Oberon, and a few others have done it, but no one seems to have noticed). Putting it in Java will make a few more waves...
Regular expressions is actually a language, though a mini one
That's just horrible, and wrong. I'm assuming the author used such generic language for simplification, but come on. I also have trouble taking someone who is talking about language theory seriously when his only apparent experience is with Ruby, Perl, and Python.
Oh well back to the article, maybe I can make it past that line this time. I'm sure there's got to be some good stuff in there somewhere
I'm the big fish in the big pond bitch.
I remember when stuffed shirts would say that the micro-computer OSs weren't really OSs since the didn't have some specific text editor, as if these bundled programs WERE the operating system! But they all were OSs, just not as complex as the Unix - VMS types were.
A lot of what is done on an actual machine is in hardware, integrated with an OS. So with an emulator you actually have:
an OS (win/linux/etc)...
which communicates existing hardware to act like another piece of hardware through software intervention... another OS
And the rest of the program, which would handle the actual code behind the console/etc being emulated: another OS
You could say they're just programs too... but really you have a system mounted on another with the purpose of loading varying forms of data. I guess it depends on your definition of an OS.
When you get down to heart of the matter, all computers use just one kind of language: the processor's binary instruction set. So you could make an argument that all (Von Neuman architecture) computers are just interpreters for a particular instruction set. Operating systems and programming languages just provide abstractions which make the programmer's job easier. Making a division between operating system and programming language is an engineering decision on where you want to position your layers of abstraction to achieve a good balance between ease of use and speed. It is all just a matter of where you decide to put your abstractions.
Physicists do it with a big bang!
My ass is really the same thing as a hole in the ground.
Democracy Now! - your daily, uncensored, corporate-free
If C becomes an OS then how would we code the Linux kernel?
now we need to go OSS in diesel cars
That was both OS and language long long ago,,,
Nothing new here to see. move alone..
---- Booth was a patriot ----
No, it's because the term "OS" is commonly used to mean "OE" or "Operating Environment". Linux, being the kernel, is an OS. sh, and all the other shell tools are the OE. You don't have to use sh for your shell or init or any other shell tools, replacing them with other valid executables. A real world example of this is the FreeVMS project. In making a free/libre version of VMS, they don't want to duplicate the work of writing drivers and developing a kernel -- they want to focus on developing analogs of DCL, TPU, the Queue manager, etc. So they're using Linux or FreeBSD for their kernel and writing their own userland.
Same with Windows Explorer. The "My Computer" icon is part of Windows' operating environment. You can, believe it or not, use Windows without using Explorer (using the command line or a replacement shell like LiteStep). Windows just isn't designed or intended to have its core components replaced so easily. I think there was a court case about it... Anyhow, I used to run Windows NT with just cmd.exe as the shell, which was fun for a few weeks, figuring out how to set control panels from the shell. With cywin & GINA installed, you could put a nearly complete UNIX face on NT and still be able to run Win32 apps.
Sun is one the only companies I've seen distinguish between an OS and OE. They used to (still?) call it the Solaris Operating Environment, with the SunOS kernel as the underlying OS. The truth is nobody cares. _My_ eyes are glazing over just writing about this. My sincerest condolences to your disintigrating brain. But on the bright side, without the ambiguous use of technical terms, slashdot readers would have a lot less to argue about, and this site would degrade into a competitive festival of increasingly embarrassing personal confessions on sex, drug use, music, government secrets, scams, circumventing the law, satire, and other boring stuff like they have kuro5hin. If we should be so lucky.
Democracy. Whiskey. Sexy. Pick any two.
Let's draw some analogies.
An operating system is a collection of specifically ordered instructions from a programming language defined by arbitrary symbols (low-level assembler, high-level C, for example)
A structural blueprint is a collection of specifically ordered instructions from a language defined by arbitrary symbols (low-level lines and letters, high-level beams, studs, poles, etc).
A novel is a collection of specifically ordered instructions from a language defined by arbitrary symbols (low-level language defined by the 26 letters of the alphabet, and a high-level language defined as English.)
To say the programming language (letters and numbers) is the same as the operating system is like saying structural blueprints are the same as shapes and lines and novels are the same as English.
The dangers of knowledge trigger emotional distress in human beings.
Athlons will become G5s!
Cats will become dogs!
Ach! Where will it all end, I ask you?
It's the end times. The END TIMES!
--- Ban humanity.
Languages: Set of rules for expression and Communication
Programming Languages: Computer-Human or Computer-Computer Languages
OS: One or more set of programs compiled via a plularity of programming languages to provide a basic set of services necessary for computing functions
Hacker: A programmer who uses a keyboard, mouse and terminal to write programs in a particular language. And, oh -- they are usually convinced that they are right.
Computer Scientist: A person who understands computers -- no computer understands these though.
Software engineer: A highly paid hacker
Perl, Python: A hacker's language
LISP: A Computer Scientist's language -- good for the high priests, but of little use elsewhere because it needs human intelligence.
C: A software engineer's language -- practical yet imperfect
C++, C# and Java: bad languages
Evolution: A branching process that may end up in progressive as well as regressive solutions in reaction to a problem or stimulus.
My Computer Organization professor went over this on the second day of class.
Indeed, in some distant future your incredibly useful 3D-transformation algorithms, fast fourier transforms, and Bresenham procedures will all be absorbed into the Hardware, and some will become part of the main processor, and still others will be inherent to the graphics cards.
Which leads to OS->Software->Hardware. I put OS at the top because the OS is an abstraction derived from all the combined software elements, libraries, executables, and data formats. For Apple, the OS is also the look and feel and style that ties it all together. The graphical interface lives on the same plane as the available frameworks and interfaces.
From a developer perspective, I see the manipulation of interactive applications as a form of programming. The contortion of data by an agent, the user, to achieve some communicable form. The programmer who types C all day makes it possible for the end-user to liberate himself from those details and focus on his interaction.
Magic mirrors, these computing machines are.
-- thinkyhead software and media
... everything you didn't write to get your program to run?
That makes me, CmdrTaco.
Yes!! everything running on a computer is a state machine. You have state machines running on top of state machines and yet more state machines running on top of those state machines. Its called abstraction, the downside is loss of efficiency the upside is the ability to handle more complex tasks. So the moral of the story is that programming languges are like operating system as well as browsers as well as the machine it runs on.
...by someone who obviously never used UNIX..
Quote from RMS in The GNU Project:
"An operating system does not mean just a kernel, barely enough to run other programs. In the 1970s, every operating system worthy of the name included command processors, assemblers, compilers, interpreters, debuggers, text editors, mailers, and much more. ITS had them, Multics had them, VMS had them, and Unix had them. The GNU operating system would include them too."
He seems to feel that an OS includes CUSPS. If not, we may have had a complete GNU OS back in '89 or so.
[tangent] What would have happened to the Linux kernel if GNU had been fully functional in the early 90's? Would it have become the illegitimate child of the GNU Project that it is today? Would RMS be so bipolar in his reaction to it? Just a thought to ponder...[/tangent]
Inferno's not an OS/Language hybrid but it is a virtualised unix like OS that will run with identical interfaces, including GUI, on differing hardware & software combinations. It will run natively on some hardware [such as my IPAQ] and hosted elsewhere - such as Windows & Linux.
It was a project started before Java and shares many of it's aims but went that one step futher by retaining the concept of an OS where you can read and write files etc.
Dennis Ritchie talks about Inferno and other things
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
so therefore, if she weighs the same as a duck...
The article is an act of mental masturbation, and typically for such acts it takes one property of the unfortunate subject of such "research" and builds a whole theory based on it, regardless of its relevance and applicability.
Languages are supposed to be designed to allow a programmer to express the implementation of his design. The OS design is supposed to give the program implemented by a programmer means to perform various actions that the programs may need. Between those two things there are libraries that include implementations of various procedures that programs perform.
This clearly separates what is the environment common for all programs and carries no application programmer's ideas at all, what is designed specifically to be used by a programmer for his specific purpose, and what lies in between, and may be close to the specifics of application (say, SDL) or to be an interface to the OS (libc).
In this way VMs are OS-like components that run over the OS, and the fact that many VMs are tied to their languages does not mean that this is a good design. In my opinion the fact that there are ties between OS and language beyond straightforward "OS is written in a language" and "language operates within an OS" are what I call "noosphere pollution". It's true that many people when they develop a new OS or language want to make "The Grestest Program Ever" and spill their ideas into areas where they do not belong. This is at best misguided attempt to coerce others into their model of thinking, at worst an attempt to create a system so closed and convoluted inside that no one ever will be able to affect it, leaving the initial developer the only "true expert" in the area. And unless that developer has influence of Microsoft or at least Sun, usually the response is "Screw you, and your giant blob of code!" because it's not possible that developers will happen to agree with every single idea developed by a single person, or a small group of them, even if most of those ideas are sane (do you hear me, Pike?).
Good (or semi-good) operating systems are designed with a very clear separation between themselves and languages that are used. Nothing required Unix to be separate from C, yet if one looks at the system calls interface and libc he will see nothing that can tie the two together like siamese twins -- there is no builtin type in C that corresponds to any Unix internal structure -- no directories, files, sockets, inodes, etc, all those things are represented by language-neutral and OS-neutral integers, and only libc makes actual OS-specific primitives visible for the programmer. This is why Unix is used with many languages, and C is used with many OS, or without any OS at all.
This demonstrates the strength of the C and Unix designs, authors were confident enough that their ideas can stand on their own so they didn't add any hidden (and not-so-hidden) strings to trap the user in a messy OS-language symbiotic monster.
Later people started making giant libraries that LOOK like OS libraries but are tied to some environment that has nothing to do with OS, and tied to a language that they can't be separated from. This was a step back -- it wouldn't if those libraries were more modular, but one glance at monstrosity like MFC gives an idea how much Microsoft wanted "to rule them all". But no, that wasn't enough -- languages with ridiculously large and complex VMs, totally inaccessible from anything but themselves appeared, imitating the behavior of interpreted languages. Java, now C#, I am sure there will be more of this. But there is a difference -- perl has to have a complex interface inside because it is an interpreter and can't just call OS. Java chosen to have an interface deliberately different from anything else, and to build VM and libraries that implement the ideas of its creators and nothing else. And of course, control freak Microsoft didn't make anyone wait before it made its own version -- with some lip service about "multiple languages" that looks like "multiple languages as long as they have Microsoft object model rammed into the middle of them, or it will be a pure hell to use".
So IMO the "siamese twins" designs are inferior to clearly defined and well-designed interfaces, and are the realm of hacks and control freaks -- with some exceptions for interpreters and things like Forth that are specifically designed not to scale beyond systems where any full-blown OS is too much (Forth developers may take it as an insult, but I believe that it's a good thing that such a closed system stops scaling where its applicability ends).
Contrary to the popular belief, there indeed is no God.
No, it wasn't. Otherwise, where is it now?
Where are all those cool systems, like BeOS, Amiga and others?
LISP was the cool language and interpreter since 1957 and stays cool here. TCL, Perl, Python, Ruby, Scheme, Haskell and OCAML are cools languages and interpreters. Linux and BSD are cool systems. PostgreSQL is a cool database. And they stay cool without any commercial support.
But all those "cool" languages and systems, which are failed and forgottent immidiately after dropping of their commercial support, they are not cool. And never been.
What will happen to Java if Sun will drop its support? Same questions about Erlang, MySQL and MacOSX. Noone will remember them.
Less is more !
when a tiger becomes a carnivore... when blabla becomes bullshit..
OS's and programming languages are both building blocks of a computer system but at different levels of abstraction. PL's are more of a mathematical abstraction while OS's are the implementation of that mathematical model. Obviously they have the same mathematical properties, but they are not the same.
Comment removed based on user account deletion
Back in the mid-90's, I worked for Computer Sciences Corp. (CSC) on a project that used the very-cool Rational R1000 platform for development and source-code control. In summary, the R1000 was a custom Ada-oriented development platform (even the hardware was custom-made, I believe). The operating system was fully implemented in Ada and featured a "command prompt" that required you to write snippets of Ada code (expressed as anonymous blocks) instead of shell commands. All errors were thrown as Ada exceptions. The "command prompt" editor even featured code completion and had a built-in debugger. It was even possible to auto-generate custom DOD-STD-2167A design documents (SDDs, IDDs, etc.) by embedding specialized comments in your Ada code (ala Javadoc) and using the built-in document generation modules. It was definitely cool for its time!
Uhhh, so this guy just figured this out? Maybe my university was the only one to cover that. Not that it took me until then to figure it out...
Yes, I am an agent of Satan, but my duties are largely ceremonial.
Imagine this: Visual Basic, the OS! Yeah, I know VB's not entirely platform independent. But imagine what a beastly trainwreck of an OS that would be! [shudder]
"But you've already got a DVD. It lasts forever....In the digital world, we don't need back-ups..."
-- Jack Valenti
savaje OS is a Java operating system for the ipaq and mobile phones. It is not a virtual machine for an OS, the virtual machine is the OS. If you've got an old ipaq you can download the installer and give it a whirl. Impressive things about it are:
its fast
its small for full j2SE (the whole OS is about 20mb)
its complete - the same java as on your desktop (not just the mobile version)
the os API is the full J2SE Java API with swing and Java 2D, so Java programmers don't need to learn anything new
existing java programs don't need to be recompiled or ported
it plays mp3s!
unfortunately the company developing/marketing have proven themselves to be untrustworthy and foolish. What was once a promising little developer community around the OS has recently been deserting in droves.
Still it was interesting to play with, and definate proof of concept that Java 2 standard edition makes a rich and compact OS all on its own
'Be the change you want to see in the world' - Al Gore
Forth.
While many modern implementations delegate much of that responsibility to some other OS they cooperate with, all imbedded Forths still provide them entierly (mostly due to there being no OS to delegate to on such platforms).
Java is, of course, the modern example.
But when you really think about it, most "real" general purpose languages do exactly that. What is the standard C library except an API specification to an OS? In most cases I know of, the actual work is delegated to the host OS but there is no requirement that this be the case.
Back in 1980, I developed a small computer which included FigForth. Forth was indeed a very nice example of merging the o/s and the language.
Around that time, the IBM PC was released. It came with a choice of three different operating systems -- PC-DOS, CP/M-86 and UCSD-p System. The last was a very nice development environment for Pascal, based on its own pseudo machine, with an operating system as well.
Now an unrelated question -- does anyone know of a standalone Embedded Linux system with a Java Swing toolkit, that doesn't rely on X? Perhaps Qt....
Paul Gillingwater
MBA, CISSP, CISM
XML OS - Not really a PL or an OS, but if you install it on your manager's box, and tell him its XML, he won't know the difference, and you'll get promoted and published in a trade journal! SCHEME OS - The user is given as documentation a BNF grammer and a tutorial on finite state machines written in math jargon and is told that in theory he/she has everything they need to use the computer, except that it hasn't been built yet. EMACS - The user is told that the OS documents itself, that it does anything, and that all your tasks can be accomplished through it. Unfortunately, after poring over the miles of "documentation" that tells the user nothing about how to use it, the user takes his/her monitor, scoops out the contents and uses it as a cereal bowl. OCAML OS - A great little OS that has lots of features and actually runs fast, but got banned by a bunch of parents' groups hwo decided it promotes smoking. Haskell OS - EVERYTHING is a function. Want to open your calculator app? Just remember that it's not actually a calculator app, but a series of stateless functions that appear to your eyes like they are a caclulator app. Want to enter some numbers. You have to understand the concept of MONADS first! It's long, tedious, but at least it makes mathematical sense.
because I am writing off of the .NET platform, usually using a combination of VB.Net and C#. It's easier to explain as just ".NET", because that's really all that matters.
Just like I used to say my web apps were written in "ASP" instead of saying "HTML, JavaScript, VBScript, T-SQL, and Visual Basic"
The truth doesn't care what I think.
performance and stability might be the major considerations
Then what does MS make?
CitrusTV (http://www.citrustv.net): the Nation's Oldest & Largest Entirely Student-Run Television Station
This is a very old concept. Every machine, concrete or abstract, has an interface whereby you access and control it. The interface that's presented to you by an old 386 is one that has things like real and protected mode, a few registers, memory, etc. The interface that ISO C assumes is one that features variables, floating point arithmetic, etc. It's up to your C runtime to ensure that floating point arithmetic is emulated properly when you compile a program for a 386 processor (no FPU, remember?), that the values of variables are kept in registers or in memory etc. In that sense, the C spec defines an abstract machine and some of its properties.
Anybody remember Java OS, by the way? Did that every move beyond vaporware?
The "meta-language" in OSes like Unix and Windows is actually C - it's primarily C conventions and architecture that defined the basics of APIs, program linking, etc. The fact that the meta-language is higher-level than assembler is important - it imposes rules and minimum conditions about how functions can be invoked between languages, etc., without which, it would be much more difficult for programs to communicate with the OS or with each other.
One of the consequences of what Flatt is saying would be to raise the bar of the lowest common denominator language in an OS. If this were done in such a way as not to limit the applications that could be developed on the OS, it could only be a good thing.
I'm prepared to call that bullshit until he presents some evidence. I don't see it happening, who wants to code on a machine that can only use one language?
We already do - if your language is not C, it better have good ability to integrate with C, or you'll be limited by that lack. In fact, most languages on current OSes are implemented in C, either directly or indirectly, for exactly these kinds of reasons. As long as the meta-language is sufficiently efficient and powerful to be used to implement other languages, there really shouldn't be any problem, theoretically. The barriers to getting commercially viable implementations of such systems developed and accepted, though, are quite large. That doesn't make the concept bullshit, it just means Flatt may be forecasting fairly far ahead.
10 A$="Who ever heard of that? It'll never work"
20 PRINT A$
30 GOTO 20
But if you use VIM, you won't need psychiatric help, whereas with Emacs, of course you do, so of course it provides it. ;-)
Professional Wild-Eyed Visionary
Actually, it's the same point. Whether it's an OS, a programming language, a scripting language, a web browser (that interprets markup and scripting languages) or some other application, it's all just a series of 0's and 1's that serve to translate human intent to machine output. There may be several layers of indirection involved - mechanical interfaces like keyboards, mice, displays, touchpads, etc. included - but that's what it comes down to. Get the user input and implement it.
Of course, the indirection does serve a number of purposes. For instance, the web browser differentiates what parts of your instructions should be run locally and which should be sent to the web server for processing.
Karma:insignificant
... in this business you'll eventually hear everything twice (or more). If you look back to (eg) Parnas, et al, and the A-7 project, you'll discover that back in the late 70's and early 80's a key notion was that both the OS and the language were part of the "hardware hiding" layer.
On the IBM System/3 in the later 60's and early 70's, the RPG/II compiler generted a binary that was booted onto bare iron to run. (If you were really down-scale, like I was, the compiler was a bootable 4-foot deck of punch cards and the result was a freshly punched deck of cards that was itself bootable.) This included the code for both the "program" -- the business logic -- and the "operating system" that allowed the program to control card reader, printer, and disk drive.
On the IBM 1401, people had decks of program cards that did specialized things, like control the printer; you added them to your program. I'm sure Goldstein and von Neumann had something similar.
What I wonder sometimes, though, is whether this repetition of the same old idea, generation by generation, proves that "computer science" is essentially a dead topic?
You are in a directory, there are many files here. A path leads to the the south and down labeled Mydocuments.
> look
There are files here labeled read.me, config.sys and autoexec.bat. A path leads to the the south labeled Mydocuments.
> take read.me
taken.
> kill read.me
You smite the file labeled read.me and it crunbles to dust.
There are files here labeled config.sys and autoexec.bat. A path leads to the the south labeled Mydocuments.
> South
You move through the passage and reach the grand chamber of Mydocuments. There are many files here. Passages lead further south and down labeled Mymusic and Mypr0n. To the north is a passage leading up......
I'm an American. I love this country and the freedoms that we used to have.
A number of years ago when I decided I would finally buckle down and start learning languages one of my main motivations was that I was naive enough at the time to believe that right behind the wheels, gears and pulleys (which is how I thought of the OS) was the guts of the machine.
Of course, once I became acquainted with C and C++ what did I find? More gears and pulleys- in other words yet another layer of abstraction. I am comfortable enough in C++ and Java to think of them as OSes.
I never found a need on a personal level to become profficient in Assembly language, but after a while I finally became acuanted with that as well- at least enough to learn that this was the final destination- what I had been after as my initial motivation to learn how to program.
Quod scripsi, scripsi.
Basic interpreter right out of the box. You could do "hello world" from the command prompt.
I've heard it said before that an operating system is there to hide the deficiencies of a programming language. Seems now they're just there to make up for wonky and disparate platforms.
vk.
click if you want, though..
they will build translators from whatever made up language they like to the language the machine does understand (i.e. compilers and virtual machines).
But the more translation layers there are between the source code and the hardware, the slower the code will run. Look at the difference in performance between C++ code, which is compiled directly to machine code, and Java code, which is compiled to JVM bytecodes and recompiled at runtime to machine code.
Do you really think you would want to write a GCC backend that emitted Ada source code?
Will I retire or break 10K?
I'm disappointed :-)
If you look at the UNIX kernel and (g)libc. It is obvious that these were written in C. The system and library calls use arguments in a C style fashion.
Windows code contains alot of object orientation and C++ was used. Its system/library calls reflect this. You pass objects and handles.
Of course you can use any language for any OS, but the OS API will define what most applications will be written in.
So does this mean we are returning to the days where my Radio Shack TRS80 booted into basic? Maybe we can find a great way to store data on audio tapes next.
"Information wants to be expensive" - Stewart Brand, the same guy who said "Information wants to be free"
The Programming Language as Operating System is old news. Remember Smalltalk out of Xerox? How about APL\360 which is a language and an OS.
Other posters have remarked on Java and the possibilities there. Then there is Forth which is also a language and an operating system rolled into one.
The prediction of the lanaguge rolled into operating system talking over has been made before, The thing that inevitably happens is that somebody, some day will have a need for a computer to do something new and unique and then have to throw out all the existing computing constructs.
The magic of Unix is the fact that the operating system itself was designed to allow programmers to do new and interesting things using the tools they need -- or create -- to do the job.
In the end, I predict that it is Unix that will take over and not any single language. It is Unix that will be used to create the next latest and greatest, and Linux will become the Unix of choice.
All those languages that works almost like OS:
Lisp machines
Smalltalk-80
Forth
UCSP-Pascal
Java
.Net languages
have one thing in common, in addition to the language itself/themselves, they all rely on the language runtime. The more the dependence on the language runtime, the more they look like OS. If you look at the most fancy runtimes, they manage memory, processes/threads, lots of similarity!
So Mr. Flat does have his point. But it probably can be stated more clearly as: language runtime (not language itself) and OS are merging. We went thru the phase of building better machines to support optimized compiler, now we are trying to build better support to the running of computer languages.
I agree about the problem of single-language for an OS (but this is essentially what we have now for Unix/Windows - C is the OS language. Other languages have to be able to make C-style calls in order to use the OS features.)
.Net framework? It provides the same base OS features to any number of programming languages. Microsoft has stated that they're going to publish all future functionality in Windows through .Net (i.e., NO more C apis - no .Net wrappers around C APIs; the OS will be exposed as objects).
BUT What about the
The VM for Perl called Parrot so far supports: Perl 6, Quick Basic, GW Basic, Python, Ruby, Java. :Perl 6 was the target language;
Python, Ruby were considered important add ons
Java allows the Parrot VM to be the main VM
The Basics were ported as a test of porting a language that Parrot was not designed to support (i.e. a test of how good a generic VM it is)
Well you had C which was written for Unix which was written for C. You can't understand one without the other.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
As a matter of fact, it's how Smalltalk started out (well, alright, Smalltalk wasn't used as a systems language on those machines, but it was used a lot for the interfaces and other stuff).
In the great CONS chain of life, you can either be the CAR or be in the CDR.
The premise gives is really pretty bad.
The operating system is the piece of software that manages all the resources and all user processes on a single computer.
An OS is written in a programming language, usually (be it VB, C, Assembler or anything else.)
A programming language can be used to request the OS of the machine to perform the functionality the coder has written.
Java Virtual Machines are operating systems, in a sense. However, they also make requests to the OS proper of the machine. The VMs are simply pieces of software intended to facilitate other software to be run over an intermediary layer. However, even given these considerable accommodations, the VM isn't a programming language, it is software, written in some programming language.
If an operating system is written in LISP, it's an operating system -but LISP isn't. The operating sytem just is written in it.
If one must try to prove their intelligence in some manner, the proper way would be to relate the abundant virtual machines to operating systems, but this, this is just a waste of time.
E
Marxist evolution is just N generations away!
At last someone who understands! And I don't mod :(
The idea of a programming language and an OS being even conceptually similar is absurd. Sure, parallels may be drawn in that they both allow people to access the system, but in fundamentally different ways.
A program language is just that, a language. It is a method for a programmer to instruct the system to perform tasks. This is then converted into something the operating system can understand by the compiler/linker, or the interpreter. The OS then has the responsibility of loading the executable, assigning memory, timeslicing, virtual memory management, and ultimately allowing it access to the real hardware underneath.
Always there are 4 levels:
hardware -> OS -> compiler/interpreter -> language
There are those who point out that old IBMs loaded ROM BASIC if there was no other OS. This does _not_ mean that BASIC is an OS! It means that a very small OS with only enough nouse to access the BIOS functions (which in this case is acting as th e barrier between user and hardware, the OS) via the interpreter built into the ROM. There are the 4 levels again.
A similar argument is made for the various 8 bit home computers, which apparently had BASIC for an OS. But take the BBC B. What happened if you remove the BASIC ROM? Can it now not boot due to having no OS? Of course it can, because of the OS built into the ROM. It was roughly equivalent to a modern BIOS, with a simple commandline interface (the * commands) but it knew enough to be able to load and execute binary files from disk or other ROMs. The same 4 levels existed, the interpreter being the BASIC ROM, and the language being the files on disk.
I'm rambling a bit now, but to bring it to a modern perspective, there are folk who say that JAVA is (or can be) an OS, because of the virtual machine. However, there are still three levels (language->bytecode compiler->VM) which still needs the OS and hardware underneath. The Java VM concept actually needs more levels of abstraction than a conventional language!
A very cool instance of the duality has been under research at Stanford, in Dawson Engler's group. They look at kernel "rules" as a programming language, and then they run a compiler checker on it to catch semantic bugs.
...; relase(x);" as a language construct, and then looking for device drivers or modules that didn't abide by it.
For example, lots of cases where locks where aquired but never released, or aquired twice in sequence in the Linux kernel were identified by considering the sequence "lock(x);
I believe there was a Linux kernel subversion named after these guys, for finding a gazillion deadlocks and such bugs in an automatic fashion.
Take a look at their first paper on this.
They have a whole slew of updates to this at
Engler's web page. I believe there's a similar project at Berkeley as well.
Cheers,
bauzeau
I'm really surpsied no comments on FORTH have been moded up. pbForth was one of the 1st language/OS combos i ever heard about. i guess Forth's just not as popular as Smalltalk...
and here i thought i was in the geek land of obscure is cool...
I've always said that software patents steal from those who made the hardware and the compiler, I find this similar in concept.
I don't RMS is actually bipolar with regard to the Linux kernel. In everything from changing the scope and priority of Hurd to Debian to even his contributions he is very supportive of the software as part of the GNU project.
I think he doesn't personally like Linus very much and he hates the fact that massive number of people are being exposed to the GNU project without understanding the underlying idealogy. This btw is quite true. I bring up basic FSF 101 stuff here like the notion that software but not hardware constitutes an artifical economy and many people act as if they are hearing this for the first time.
So no I don't think he is bipolar at all. The battle has changed from creating a free system to getting the people using the free system to understand how and why the ground was laid. When RMS is dealing with Linus he is dealing with a guy considerably younger than himself who wasn't there when a great deal of the important battles of the 70's were fought and therefore doesn't understand the context that he is working in.
But I don't think RMS is at all unhappy that the FSF operating system is about to become the #2 operating system in the world. That is a major victory by any standard.
Let us not forget the mighty Squeak:
http://www.squeak.org
Nachos for Life!
k.h.
This article describes a universal characteristic of most seminal languages that most of us had to learn. The fact that the author just figured this out tells me something about his age.
now people have heard of that supposedly GUI based OS called MacOS right?
as the story goes (according to me), Xerox PARC develops a language called Smalltalk. this OO language has this funny little feature that a user interacts with it via Graphics. They also develop the computer to go along w/ the language that's based on the same idea. the user interacts w/ objects on the computer via graphics.
Apple likes the idea, and adopts it for a new computer named Lisa. The Lisa becomes the Macintosh and gets popular...
I'm going to go with a pragmatic definition that the OS is all the software that is included free with the "operating system" box. So for example it's not even unreasonable to consider Office small business edition part of Windows, to consider MYSQL part of GNU/Linux, to consider iTunes part of MacOSX. Certainly these are all meant to be extreme examples but really they are what hold the OS together.
What is Windows apart from the Productivity Suite? What is Linux apart from the thousands of GNU apps? Is Darwin anything more than a naked component of OSX?
So what will happen is that the clueless masses will merely become *aware* of the possibility that there need not necessary be a sharp boundary between the programming system and the operating system kernel. Well, that's progress too, I suppose. ;)
If the programming language is safe, and special privileges are required to load arbitrary machine code, you can do away with the kernel/user boundary that is enforced by the hardware, and the parameter validation overheads that entails. If a disk-writing function receives a byte array from the application, it can just trust the integrity of that object---that it doesn't contain unmapped pages, etc.
Security credentials can just be an ordinary object that you inspect using an ordinary accessor. The language-level mechanisms ensure that you can't fake credentials, simply because you have no write-accessor to do it, and no way to fake one, not having access to writing raw machine language.
GCC already compiles Ada, if this [gnu.org] is accurate.
I wasn't talking about GNAT, a GNU program that turns Ada code into machine code. That would be an Ada frontend for GCC, not a backend. I was talking about a program that would take C source code and output Ada, allowing a program written in C to be used on a system that allows only Ada.
Will I retire or break 10K?
That will be cool. Hopefully, "Larry" does better in the marketplace than "Bob".
Seriously, we speak of information systems, and the discussion amounts to "Where shall we choose to draw lines in the abstraction hierarchy?"
I submit that a similar discussion could be had on the similarities/differences between TCP/IP stacks and the OSI stack. Which is more pedantically pure? Who cares? Differences that make little difference, say I.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
What is the real instruction set? The processor's user-visible instruction set may be implemented in random logic, FPGAs, microcode, traps to machine code or some combination of the above. There can be more than one level of microcode. Some processors have a writable-control-store, allowing the manufacturer and/or user to change/enlarge the processor's microcode and instruction set. Western Digital used to make a multi-chip CPU that could be a DEC LSI-11 or an UCSD Pascal p-Machine by changing the control ROMs. On an IBM mainframe, an operating system call may be implemented in machine code, microcode or hardware, depending on which model you have.
Mea navis aericumbens anguillis abundat
Load "$",8,1
Apples and oranges are the same thing too. They have at least these things in common:
1) Grow on trees.
2) Round.
3) Taste good.
4) Good for you.
5) Make great juice.
6) Same size.
7) Used as an analogy for things that do not compare well.
See? Apples will become oranges.
Quoting from --someone/somewhere-- "who wants to code on a machine that can only use one language?"
You don't have to use only one language, since you can write any language you like by building a --compiler-- in the 'Single OS/PL language' proposed. This compiler takes code from your invented language(s) and translates it into the 'native' language of the machine. Hey wait a darn minute, that's exactly what we're already doing!
And of course, by definition computers (read: Turing Machines) can simulate a Turing machine which can simulate a Turing machine, which can... which is really just a rewording of the above paragraph. So yes, the distinction made between PLs and OSs is artificial, a cultural artifact, when speaking in the strictest sense.
of a programming language. They are in fact completely different things. Programming languages define the constructs for describing a process the computer needs to do.
.Net. .Net is NOT a programming language, but merely a platform. There are a variety of languages (C#, VB, VC++, etc) that can compile against the .Net platform.
The platform OTOH defines APIs, memory models, etc. "C" is NOT an OS.. its a programming language. The POSIX APIs, Stdlib.h, etc. compose a platform you can compile C code against.
Esentially the platform is a foundation upon which you use a programing language as a tool, in order to build the program on top of the foundation.
Java is considered both an language and a platform. But that is incorrect. There is a Java language, and a Java platform. They are two different things. The platform defines the JVM and the standard APIs, the language defines a set of constructs used for describing programs.
Evidence that this is the case can be found in the fact that other languages are available to compile against the Java platform.
The same can be said of
Well RMS seems to think so, at least about grep. Otherwise we wouldn't have to tiptoe on eggshells about that whole "Do you name your OS after your kernel?" ... but do we name our OS after our applications?
People who quote themselves bug the crap out of me -- Me.
You could just call the ROM BASIC interrupt.
:)
:)
That was my first assembler program, too.
If you do it in SoftWindows, a window will pop up that says "SoftWindows does not support ROM BASIC".
pb Reply or e-mail; don't vaguely moderate.
We still have those today, although people have taken to calling them "byte code"...
I want my computa to run a language/os based on intercal.
Do you mind if I fuck your sister's ass while I wait for it? I'm sure she will enjoy the ftp process (get/put) running or her slot. Thank you for your cooperation.
w007!
Language/VM/OS is a useful abstraction. So far, we have lots of Languages and lots of OS's, but relatively few VM's. For example, if one could compile Java to run on the JVM and Parrot, well - I'm not quite sure what you'd do.
And that's my point.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
This reminds me of my old Atari 800xl. Had BasicOS - a simple (yet fairly robust for the time) basic interpreter. Had to know a thing or two to be able to do anything with it though.
I was always hoping games would replace my OS. Well, better keep trying.
..to anyone who has ever used a Lisp Machine, Forth Machine, Smalltalk system, or any one of the other dynamic, interactive programming language environments.
Here's a useful link:
No-Kernel systems.
Those who do not know the past are doomed to reimplement it, poorly.
Who ever worked in a PICK environment?
It IS the OS, and IT IS the Database...
and it runs very nice on intel 8080, or Z80 processor...
(Man, I must be oooooolllllddd!)
An operating system is a resource manager and an abstract interface(Andresen 2002). A programming language is more nebulous, but if it can manage resources and present an abstract interface then I can't see how modern programming languages couldn't be considered Operating Systems in some respect. Most langauges offer memory management, mutlithreading support, etc, and many have a solid API for things like hardware interface (SDL...). Java borders closely on this, although it takes the JVM (which has probably been argued before to be an OS in its own right).
Isn't Forth just as prone to buffer overflows as C?
It's great for drivers/firmware but once you go to the other layers, it seems to become as error prone as C.
I don't see that many complex apps written in Forth. I've personally crashed a Forth webserver on practically my first test. It died and didn't come back up (the author has fixed the problem).
As a general purpose language there doesn't seem to be as much going for Forth as say LISP.
Mod parent up.
Seems too many people forget that "rooms, walls and controlled openings" are a good idea. The bigger the building the more important they become. Sure you can have one huge room and put everything in it, but you'll end up partitioning it anyway. And even then either you resort to separate rooms or accept that the furnishings and decorations will be inconsistent within a room.
Me: One man's impedance mismatch is another man's layer of abstraction.
It's more likely that someone will add yet another type of "room" than for things to merge together.
Anybody remembers Burroughs and Algol ( Espol ). What about DataSaab and Algol - way back - and just for fun.
see title
The way I see it, an OS is just a program. Applications compiled to run on an OS are basically just "plugins."
Programming languages are used to make programs, but programming languages are not, in themselves, programs. There are strong relations, to be sure, but they aren't the same thing.
I am not convinced by the original article, but I do believe that we will move towards running multiple machines, operating systems or whatever they may be, at the same time.
:)
For example, one of my machines boots up with win2k. I can play games, my wife can run outlook etc. Then I have one or sometimes two vmware sessions running Linux. There I can do my programming, play around, and connect to work and run X against their servers. And my wife doesn't have to log out from her windows while I'm doing it. I can also access the linux subsystem from a Windows X terminal, and the filesystem as well, which in practice gives me an embedded linux kernel within my windows.
There are a lot of fun and practical things you can do with a setup like this, especially if you are a geek.
And it's not arbitrary, traditional or cultural.
Simply, it's complexity management.
By partitioning things into multiple layers you can mange the complexity of your computing environment.
e.g.
You have 5 different graphics card to support? You create a driver and write to it's API.
Want to schedule the execution of multiple applications, you create a service and write to it's API.
Operating systems are tools for managing complexity.
*That's* the fundamental logic of the way things are.
If you integrate these kinds of features into a single language, you still have an operating system underneath managing the complexity, it's just a language specific operating system, and *that* doesn't make any fundamental sense.
Government of the people, by corporate executives, for corporate profits.
subject sez all.
The BBC Micro is actually a fairly good example of separating the language from the OS. They were on two different ROM chips. If you unplugged the BASIC ROM, it booted to a shell prompt. If you plugged in a Wordwise ROM instead, it booted into a WP. Or you could put in a FORTH ROM... BBC BASIC was an application like any other.
Virtually serving coffee
Erlang is built on the OS model to abstract the hardware and act as a multiplateform development environment.
His threading mechanism is very efficient and do not use the OS one.
You can have a look at: http://www.erlang.org/
this guy is confused, sorry.
I wouldn't mind having a third as many articles per day if they had more clues and less cheerleading.
Or is this a mutual masturbation and crawling into our navels society? Feh.
I'm currently working on a project that needs to run on a Windows network, and when I started I didn't have a Windows machine. I've done the whole thing in Perl/Tk, and, apart from a couple of small routines that switch slashes to backslashes in filenames, the whole thing, back end plus interface plus data files, is transparently portable.
Of course I could tie myself to a particular platform by using specific system commands or whatever, but sticking to the generic bit of perl (ie most of it) means that, for all intents and purposes, I can forget about OSs entirely.
Virtually serving coffee
It is Nybble. It's a pun on "byte".
Forth programming language was often used as a stand alone system on 6502 hardware.
Many late 1970's early 1980's computers based on the 6502 used basic for the operating system.
Commodore Pet/CBM,Vic20,64,128,B series
Apple II series
Atari XL 8 bits
Cray 6502 pocket supper computer for mad scientists (Top secret) Oh wait you can't know about that one..
Ummm Oh yeah and the latest one RIAA's recomended specs thow instead of a 6502 they use a Z8.
I don't actually exist.
Seems to me that this is old hat.
Contrary what others replied to your post you are damn right. This is a really old hat. Another example for an ancient programming language that was used and designed as an OS is Forth -- the language for "4th generation computers".
He saw some dirty arabs and fired. Too bad it was just some friendly kurds, BBC reporters and his fellow cowboys.
I thought AOL was my computer and OS... =P
sex, drug use, music, government secrets, scams, circumventing the law, satire, and other boring stuff like they have kuro5hin"
Karma: Bored. (Thinking about resurrecting the "Anyone else is an imposter" joke.)
I meant to say, before I accidentally hit return, that sounds exactly like everything2.com
or has it been done already?...MU-WHA-HA-HA....
Programming languages have been operating systems for decades, e.g. FORTH etc.