OSDev.org

Well, I learned (in that order) BASIC, Assembler, ARexx, C, Java, C++, and Perl, and I have to say that, out of all of those, C++ wins in just about every department hands down, with Java getting the leftovers and Assembler scoring two measly points (code size, code efficiency) in the hands of a pro.

I haven't found the combination of core C++ features in any other language yet:

* compiled language with close-to-C performance;
* availability of compilers for virtually any platform;
* can create custom datatypes (classes) that behave like inbuild ones (including e.g. x == y);
* generic programming (templates);
* exception handling;
* can interface C code without major hassles;
* availability of source-level debuggers.

I grant you that C++ isn't a beauty. Like Stroustrup said, "somewhere within C++, there is a better, cleaner language struggling to get out". But that language isn't C, and it isn't Java either.



It's the adaptability of C++ I like so much. You can take plain C code or code using namespaces and classes; you can add multiple inheritance (or rather not ), you can use templates (or not). You can write code that calls by value, or code that calls by reference.

Except for first-level objects (modifying a class definition by runtime), C++ just owns everything there is in OO or procedural programming. You can do.

That is, of course, also its greatest weakness.



It sure as hell won't be Java. If there's one feature in C++ that inspires those working on its successor, it's "templates".

imho, the two features that lacks the most in C++ are
[*] the concept of "package" (? la Java -- which makes package-viewable fields and classes much more clear than c++ ' "friendship", imho)
[*] some kind of "foreach" operator ... Too bad we have constructs that allow String x = "Hello"+" "+"World"; but nothing like


At least, if we do have it, i didn't found it so far.

namespace?



Like the for_each template in the STL?

Not quite ... namespace just allow me to have shorter identifier without symbol clash, while java package also allow a default protection status: "field/method is accessible to any other class in the same package", which is very handy in a lot of case where you don't want to bother with complex protection mechanisms but still don't want component from other package to access your private parts.

My personal favourite is Lazy K. Who needs any side-effects, anyway?

Huh? Perhaps I'm missing something, but I can't see the real advantage. Templates as they exist in C++ are a workaround due to the lack of a singly rooted object hierarchy, or such as my understanding. In a language where all variables are objects off of a single root, they are completely unnecessary; you'd simply declare the method as class Object (or whatever the root class is) and apply to whatever classes you wish. While parameterized classes do have some important advantages, if it is to be included it would be better to have it as part of the general class declaration mechanism rather than have a completely separate syntax for it, IMAO. In any case, to get the biggest advantages of parameterized classes, you'd need the ability to work with higher-order functions, mix-in methods, and/or arounds (in effect, the ability to generate, add or modify functions on the fly), which aren't practical in a statically compiled language like C++ (possible, yes, and people have done such things in the past - I've even seen programs that support lexical closures in C++ - but it's more trouble than it's worth).

Is there some other advantage of templates that I've overlooked? I'd be interested in seeing what I've missed.

Perhaps we need to add a corollary to Greenspun's Tenth Rule of Programming to the effect that any sufficiently complicated C++ or Java program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Smalltalk (or three-quarters of it, if it has a GUI interface).

I apologize if this is drifting towards a language war. I have no problem with using C++, really; many of the features I love so much in LISP are, quite frankly, not very practical in real-world programming, no matter how elegant they may be in principle. I just think that the advantages and disadvantages of any programming language should be thoroughly understood and recognized, and that different alternatives should be considered when choosing how to implement something.

@ java & templates:

For using Java daily, i must admit that i feel a real lack of 'Vector<component>" in my code. Not especially for the features, but for the clarity of declarations.

Having to cast every nextElement() to the expected type is boring to do, but it achieves the expected goal.

However, when i read "Vector children;" in a class declaration, it really doesn't help guessing what type "children" are, which means i need to dive into methods implementation (hoping that children is actually private and that only this class is to be inspected) and look for who adds stuff to the vector in order to know what type they are ...

That's a design flaw, imho. Being able to force a vector to accept only objects from a class X and being able to specify it at declaration would help ...

okay, now maybe i should

... nice discussion ...

what I like about BASIC is: easy syntax & easy to read (and write).
I'm searching for a language that ?s close to the machine AND easy to read & write.

I dont like C because its not easy ro read (in my opinion)
(ok that depends. but in general I like the BASIC way of writing apps more)

... I looked at the posted links but the only thing I found were syntax examples?! (which doesnt say if the language is powerful enough to develop an os with)

ps: the idea of writing a language is nice....
what would you like in your own language?
* i'd like it to be easy to read (no {[#%]} ...) and write
* small (load needed things via librarys
* close to the machine (for osedev)
... something like this.

@ october:



Many mainline languages depend on the developer to care for readability. And I am sure BASIC code written by a careless coder can be as incomprehensible as C code written by a careless coder.

The thing that makes bad C/C++/Java/Perl code so unintelligible is that these languages can do so much. Now, usually you want such a powerful language.

Well-written C/C++/Java/Perl code can be read and understood single-pass, top-down. If you cannot, that's a problem of the code, not necessarily the language.

And, consider that your ability to read BASIC so easily might be because you are used to read BASIC. I am used to reading C++, and if I have problems making sense out of some piece of code, that's usually because my co-workers didn't care for maintainability when writing it.



Classes are the building block of one concept, namely "object oriented programming".

Templates are the building block of a different concept, namely "generic programming".

The two are distinct, but quite usually a "generic" language is also "object oriented" because the two concepts go well together.



There is, and I am lucky in that a coworker of mine is in the C++ Standards Committee, with templates being his speciality - I can use them quite well, but he's the language lawyer knowing the "Why". He's on vacation right now, so I will open up a "Templates Explained" thread once he gets back.



Two factors often overlooked:

* do you really believe you can design a better mousetrap?

Sure you can go ahead and design your own language. But advancing that language to production level will take years in itself, requires quite some expertise, and in the end there will be some bolted-on expansions because you won't get it right the first time. Do you really believe it's worth the effort?

* how many developers looking at the project will have to learn a new language just to participate?

Usually you won't find developers that are good / experienced and have lots of time. The good ones almost always are notoriuously short on time. They won't bother learning a new language (donating time) just so they can donate time to your project - they could advance their knowledge in a field that actually earns their money instead...

Basically, by designing your own language first, you delay your project by at least two years, increase your chance of failure, and limit your potential co-developers to those who have lots of time - thus being either students or fanatics.

Get me right, I'm not saying that students and/or fanatics cannot do a good job. But, so I found, the most valuable input comes from the pro's, and they seldom are in a mind of learning a new language they cannot put to use anywhere else.

(That's why I, even while being interested, haven't had a closer look at e.g. FORTH, Smalltalk, or Oberon: I can't apply them on my job.)

For sure, C has many 'special' characters that may make it look ugly at first sight, but once you go in deeper details, you'll notice that each of those special symbols are used for a single purpose, so with little habbit (a few weeks of programming), you'll no longer need to wonder "should i put a [ a ( or a { here ?".

In this sense, language like basic and pascal are easier to use for they use *words* instead of special characters ... But which one is *effectively* easiest to read when you start concentrating on what code *do* rather than how to write it ? begin ... end or { ... }

On the opposite side, you have lisp-derivated languages that use parentheses for all purpose: indexing, creating lists, grouping instructions, etc. which makes the code sometimes pretty hard to read ... while at first sight it might look easier.

Also think about one thing: the 'special characters' of C are reused in a large amount of "pro" languages like Perl, Java, etc. (not mentionning C++ nor C#, of course). So learning them is not a time loss, especially if you plan to become a CS professionnal in the future.

Otherwise, maybe pascal is the language that might best fit you, though i would not really recommend it for OS development (the runtime library may be more complex to support, and i can't really help for i haven't tried or read about pascal OSDEV myself, but there are a lot of running projects like this).

I have to concede this point, at least from the perspective of conventional programming. Language design is indeed difficult, and writing a full language for a single project is likely to be more effort that is justifiable.

However, for me, that's not even a question; building a better mousetrap is my stated, and sole, purpose, and practicality be damned. I am a researcher, even if not a professional one just yet; being impractical is an occupational hazard.

Besides, one of my favored paradigms is Notational Design, which holds that every program is also a programming language, though most are quite limited and only very few are Turing-complete. From this perspective, both the code and the user interface define a language, whether explicitly or implicitly, and the more explicitly it does so, the better.

However, you've just highlighted the largest problem I've had in my career, such as it is: I am far too academically inclined to make a good practical programmer. While I've been programming for over a decade and a half, most of that time has been spent studying programming (informally, for the most part) rather than actually coding; I have less than 6 years of professional coding under my belt, most of which was HTML markup rather than programming per se. The result is that while I know quite a bit of the more esoteric aspects of the field - including some mind-blowing stuff that most programmers are hardly aware of - my coding skills have barely improved beyond the most basic levels (though my coding style is quite punctillious).

Even including all of the Web page development and the various failed projects, I've probably written less actual running code than many programmers half my age have. I could defend myself on the grounds that the field needs its theorists and its cranks just as much as it needs its professional developers and its grunt coders, but the truth is, I've failed as an academic just as badly as I have as a coder, for reasons that have little to do with programming at all and a lot to do with my own personality flaws. If I could get my act together, I might make a suitable teacher (as in "those who can't do..."), but I doubt I'll ever have what it takes to be a professional developer.



Ouch. Despite what I just said, I am saddened to hear you say this; I think it is as shortsighted as my own obsessive knowledge-gathering is. It is a common observation that experienced programers are usually quite fast at learning new languages, at least the basics of them, and that the more languages you know, the faster and easier it is to learn new ones. I am not exaggerating (much) when I claim that a skilled programmer should be able to understand the fundemental ideas of a language like Scheme over a couple of weekends; the hard part is the change in perspective, rather than the language itself. Smalltalk may take a bit more time if you don't know OO already, but if you do, then it too should be trivial to pick up (most of the hard work is in learning how to use the Smalltalk programming tools, rather than the language itself). Given that understanding them is likely to help your coding in the languages that you do use professionally (C++, Perl, et. al.), this is hardly a large effort to commit to, I would say.

The Wirth languages would also require little effort, being quite close to C in many respects; a decent C coder should be able to understand a well-written Pascal, Modula-2 or Oberon program with few difficulties (though some of the constructs, such as Pascal sets, may be a bit confusing) even without any background in the language in question. Learning enough to program in them effectively would be trivial, probably easier than learning, say, Visual Basic (which, despite it's initially shallow learning curve, is actually a quite complex language full of bewildering inconsistencies and odd quirks; VB.NET fixes many but not all of these problems, but adds several new ones).

Besides, learning languages can be a pleasant diversion for it's own sake (though you probably don't want to get quite as 'diverted' as I did).

ada really looks nice to me.

does anybody know if its usable for osdev?

Yes, but not easily. Ada was designed from the start as a language for complex embedded programming projects and systems programming; the US Dept. of Defense meant it as the only language for all military programming projects, which naturally included a lot of real-time embedded control software (e.g., artillery fire control, Command and Control information update, etc.). Thus, it has a lot of tools for low-level hardware programming, as well as built-in exception handling and multitasking. The GNU Ada compiler should have no problem generating stand-alone code for you.

That's the good news. The bad news is, Ada is huge: even with most of the language facilities factored out into standard libraries, the core language is still an order of magnitude larger than C, and dwarfs even such massive languages as C++, PL/1 and Common LISP (VB 6 is probably about as large or larger, but it's size comes mostly from legacy issues; Ada was designed large from the start). The runtime and compile-time requirements are enormous, and will force a would-be OS developer's hands on several key factors.

Also, the exception handling and task-management facilities have been widely criticized for their clumsiness and inefficiency, glaring problems for a language meant for systems programming. In addition, using the low-level programming functions often requires the programmer to jump through several security hoops which add complexity to the code while doing very little to prevent buggy or malicious code from being written.

Beyond that, it is generally agreed that, while the more verbose languages may initially seem easier to code and to read, the sheer volume of code becomes wearying very quickly. A concise language like C may seem harder to read, but it quickly becomes very easy, provided that the code is well-written; whereas Ada or VB code quickly becomes tedious to wade through, and the 'clarity' of the language does nothing to prevent programmers from writing obscure, poorly-thought out code that is impossible to understand. The balance between concisiveness and readibility is serious issue with all languages, and generally speaking, it is up to the programmer to make their code understandable regardless of the language used.

Finally, the fact that the DoD themselves have largely abandoned the language has left it an orphan, and has basically ended whatever acceptance it has gotten. Ironically, the language has been most widely used in European university programs unrelated to the US military, from what I have heard. Ironically, the end of the strict standardization may be a boon for Ada fans in the long run, as the rule forbidding subset implementations is no longer in force; it is possible, though unlikely, that a smaller, Ada-like language might have a niche which the original language was too large to fit.


This isn't to say you can't use it for OS design, but it would certainlypresent some unique problems that may prove very difficult to solve. It is an interesting language in many ways - and it really shines in projects above about 50,000 lines of code, they say - but it is not, by any means, a beginner's language.

If you are still interested, see The Ada Home Page for more information.

If you like Ada, you may want to consider Modula-2, which has many of it's advantages, but runs much lighter and has fewer complications. It's still quite verbose - extremely so - but it is probably closer to what you want overall. Modula-2 compilers are quite good, often producing code comparable to the best C compiilers. It isn't a particularly popular language, though it had a substantial following in the 1980s and early 1990s. Check out pages like this one, or browse through the Modula-2 Web Ring, for more details.

Hey modula-2 is really cool!!! Nice language.
clean syntax and the modules are a good idea. I really like it. thanks. Are there any os projects around using in modula-2? I found spin which uses modula-3.

Just need some time to take a real close look at it. To see if its possible to write my own corelibs ... and if it uses things that need to be rewritten for osdev (like internal procedures. (free(), malloc(),...) But since its not OO it should work?!

Thanks a lot

coding experience... well, I do coding since I've been eleven or twelve. I've started with c64 Basic and c64 assembler then. Not that it went good with assembly for no one helped me but smiled and said Nope, you won't get it. I've always been good friend with computers and electronics.

learning languages: Hm, I speak german, english, french (to some extent), croatian (a few words, I understand and can read more than one will hear from me), and since past june, also swedish... the knack is, that I like languages.

Learning computer languages: is like learning languages, but not THAT huge. Once you get syntax right, you just have to worry about a few rules and to keep semantics in mind. what you tell the computer it does it and it it's told crap it does crap.

I after all do not agree with arguments like 'c++ is the holy grail of languages' or 'smalltalk is superduper' ... each language has a purpose. Take COBOL as an example: It is an efficient language for handling huuuuge data while being a crap thing to consider for gui programming (COBOL 2000 is aimed exactly at this...). It is hard to learn due to some fuzzy compiler things (indentations) but after this learning, you can easily create working programs. what I want to say is: don't condemn a programming language for its flaws ... each one has it's special flaws and its very special goodies.

The other thing ... this argument about the pro's that solar has brought in: I canna say that I disagree, but I don't agree fully. It's a bit stubborn minded to say: No, I don't want to learn 'coz it doesn't gain me mo'money. Learning trains the brain. And a real good pro should always keep in mind: sometimes the one or other goodie hidden in the depths of his brain can be of use.

... hehe, and it already proves it's value to practise programming with my os project: solutions for professional needs are found quickly, be it in cobol be it in power builder: It is the algorithm that counts, not the language itself.

... so I come to the end of my sooo long sermon (soit qu'il soit...):

Programming is about finding/forming proper algorithms to accomplish goals (solve problems). Not the language shall be put in the front but the algorithm - the way to go. In which language it is carried out, depends on the special needs.

.... et avec ces mots je ferme le sermon et vous prie d'accepter mes sentiments les plus distinctes. *ggg* ah mon grand dieu, 'y-a-t'il des ans longes que j'ai parle le francais la derniere fois...