OSDev.org

This thread brought warmth to a cold day.

Although C was made to write unix, unix had already been written in asm. I don't think that C excludes all OSs other than unix, because it is a very general language that can be used for other things.

Do we really have to argue over languages though? Is a textbook written in german any better than a textbook written in english? The answer could be yes, but it wouldn't be a result of the language, it would be the way the author(s) wrote it, the way it presents the information and the overall effectiveness of the writing style.

-JL

Noooo don't give them a new topic to argue about!

Rusky wrote:"to an extent," guys, "to an extent." AmigaOS, RISC OS, and Mac OS all had varying degrees of problems...

ACK.

...caused by C's design.

NAK.

That's all I was pointing out.

Yep, and people disagree with what you pointed out. Either you bring in new arguments, or you agree to disagree. "I am right" is not an argument.

AmigaOS had exactly two problems - the first being the absence of memory protection, which was an ultimately ill-adviced design decision against a MMU for cost / performance reasons. The second was the inability to effectively port the OS to a different architecture once the M68k fell behind. Neither had anything to do with C or not.

How is that a conspiracy theory? [...] ...the obvious trail of inspiration from C -> C++ -> Java -> C# that neatly left out any alternatives to compiler-unchecked null pointers.

You make a wild statement that these languages are "stuck with, for example, NullPointerExceptions over explicit optional types", and that they "neatly left out any alternatives to compiler-unchecked null pointers." You blame this on inherent "limitations" of the language C. You leave your statement dangling, unsourced, unfocussed, so it's hard to even argue against it because it's not quite clear what you are trying to say.

There are parallels to conspiracy theorists.

You ignore the possibility of it having been a conscious design decision. You ignore the existence of mechanics for "optional types" in these languages (at least if I understood correctly what you mean with that). You ignore that NullPointerExceptions are nothing you are "stuck with", but a perfectly feasible way to catch the condition, report it, and carry on regardless (as opposed to crash & burn, which is the time-honored way for C or ASM apps to "handle" the condition).

Anyway, this is way OT. Let's bury this, I don't feel like another holy war.

Solar wrote:AmigaOS had exactly two problems - the first being the absence of memory protection, which was an ultimately ill-adviced design decision against a MMU for cost / performance reasons. The second was the inability to effectively port the OS to a different architecture once the M68k fell behind. Neither had anything to do with C or not.

Not quite true, it's descendant ports run on PPC with MMU too.
As for C: we have a saying, "if you have a hammer, you want to solve everything with a hammer". There's truth in using C's thinking not always good, but it's not exactly C problem, rather programmer's. VFS is a really good example of that, if you want to implement it with C in mind, you'll have troubles. And vice-versa if you have only C++ in mind, you'll have problems elsewhere.
(To make myself clear, this is language independent, C (as structural) and C++ (as object oriented) where only examples. Everything has it's right place to use)

piranha wrote:Is a textbook written in german any better than a textbook written in english? The answer could be yes, but it wouldn't be a result of the language, it would be the way the author(s) wrote it, the way it presents the information and the overall effectiveness of the writing style.

Actually, I think the language does influence this. For example, German has a more featureful grammar that makes the language probably quite a bit harder to learn, but on the other hand gives you more freedom in the word order (and different word order means different stress, so it's additional expressiveness). It also has modal particles that are often difficult to translate into English - in many cases you would just leave them out, but of course you lose some connotation. The same thing may be realised in spoken English by stressing some words, but this is hard to write down. So yes, I think the language influences what you can easily express.

On the other hand, a native speaker of other languages would probably find some great grammatical features that his native language has, but German lacks. Maybe you could even say that for technical descriptions some given language is better suited, and for novels it's a different one. But of course, even though objectively some other language may be better suited for the job, when choosing a language there is this big bias of German being my native language.

I'll leave drawing the parallels to programming languages to someone else.

turdus wrote:VFS is a really good example of that, if you want to implement it with C in mind, you'll have troubles. And vice-versa if you have only C++ in mind, you'll have problems elsewhere.

There's a 1:1 mapping between C and C++ code possible, so I have to call BS on that.

As for Amiga, the point was that it ended up in a coma after the transition to PPC. A lot to learn you have, young padawan.

Kevin wrote:

piranha wrote:Is a textbook written in german any better than a textbook written in english? The answer could be yes, but it wouldn't be a result of the language, it would be the way the author(s) wrote it, the way it presents the information and the overall effectiveness of the writing style.

Actually, I think the language does influence this. For example, German has a more featureful grammar that makes the language probably quite a bit harder to learn, but on the other hand gives you more freedom in the word order (and different word order means different stress, so it's additional expressiveness). It also has modal particles that are often difficult to translate into English - in many cases you would just leave them out, but of course you lose some connotation. The same thing may be realised in spoken English by stressing some words, but this is hard to write down. So yes, I think the language influences what you can easily express.

On the other hand, a native speaker of other languages would probably find some great grammatical features that his native language has, but German lacks. Maybe you could even say that for technical descriptions some given language is better suited, and for novels it's a different one. But of course, even though objectively some other language may be better suited for the job, when choosing a language there is this big bias of German being my native language.

I'll leave drawing the parallels to programming languages to someone else.

Thats true, but I was hoping that the metaphor wasn't going to be taken that far

Although it can be seen there that the author clearly needs to have a good command of the language. Much like in programming languages, if the programmer sucks, theres not much the language can do. Well written C code can be better than poorly written ASM code, and vice-versa.

-JL

piranha wrote:Well written C code can be better than poorly written ASM code, and vice-versa.

s/can be/is/, for any given combination of (non-pathological)(*) languages.

(*): BF, INTERCAL et al.

NPE probably was a conscious design decision. But- it was influenced by C, which was influenced by assembly. My contrast was with languages whose default pointer/reference type does not include null, whose values cannot be used uninitialized, etc.

These decisions, which were influenced by C, conscious or not, lead to programs that can crash and burn because of compiler-preventable problems, and those programs exist on Amiga, RISC, Mac OS, Linux, Windows, OS X, etc. A systems programming language with different defaults would go a long way toward making that different.

I apologize if I sound like a conspiracy theorist.

Rusky wrote:These decisions, which were influenced by C, conscious or not, lead to programs that can crash and burn because of compiler-preventable problems, and those programs exist on Amiga, RISC, Mac OS, Linux, Windows, OS X, etc. A systems programming language with different defaults would go a long way toward making that different.

Well, build one, and get it accepted by the marketplace.

Until then...

Combuster wrote:There's a 1:1 mapping between C and C++ code possible, so I have to call BS on that.

Learn to read. Right the next sentence, which you kindly cut off:

To make myself clear, this is language independent, C (as structural) and C++ (as object oriented) where only examples

I was talking about the methodology (structural, object oriented, aspect oriented etc.), not the implementation. It's about the way programmers think, not the language itself. There's a 1:1 mapping between C and Pascal too, so what? It hardly tells anything about the model and it's limits at all.

Besides if your agrument would be valid, it would also mean ASM is superior to any language, since their product can be 1:1 mapped to assembly.

You'll always have a reason to complain about interpretation when you post two contradicting sentences

Thinking in code is the style of a noob. Real programmers think in algorithms. VFS implementations do not fundamentally differ between C and C++ just because they disagree on class being either a name or a keyword. You apparently have never realized that linux kernel developers do classes even though they have sworn off c++.

Combuster wrote:You'll always have a reason to complain about interpretation when you post two contradicting sentences

Thinking in code is the style of a noob. Real programmers think in algorithms. VFS implementations do not fundamentally differ between C and C++ just because they disagree on class being either a name or a keyword. You apparently have never realized that linux kernel developers do classes even though they have sworn off c++.

I was talking about it's not trivial to find out how to store functions in dynamically pointed structs if you are the first programmer doing such a thing, and object orientation is not invented yet (as of rewriting UNIX in C for the first time). C did influence OS' in this manner. Not for it's syntax or coding style, but for being structural. It's easy to say nowdays linux vfs C implementation is similar to a C++ class.

You totally does not understand the concept of paradigms and the difference between theory and implementation. You cite pragmatical examples when talking about theoretical questions. Bad for you.

Solar wrote:

Rusky wrote:These decisions, which were influenced by C, conscious or not, lead to programs that can crash and burn because of compiler-preventable problems, and those programs exist on Amiga, RISC, Mac OS, Linux, Windows, OS X, etc. A systems programming language with different defaults would go a long way toward making that different.

Well, build one, and get it accepted by the marketplace.

Until then...

Until then... what? I'm not allowed to discuss problems with existing mainstream languages?

Rusky wrote:Until then... what? I'm not allowed to discuss problems with existing mainstream languages?

Of course you are allowed to discuss problems. I just have a slight problem with unsubstantiated... let's call it "finger-pointing".

I don't see much of a problem with C as a system programming language (certainly none that C++ didn't fix, of course not without introducing a couple of issues of its own - most importantly the next-to-impossibility of automated refactoring tools due to its butt-ugly syntax and semantics).

I certainly disagree that using C somehow, automagically, makes you drift towards "Unix-likeness" the way *I* understand the term. (You didn't make very clear how *you* understand it.)

I also don't see how C heritage somehow "taints" languages into being "suspectible" to NullPointerExceptions, especially in the light of stuff like Boost.Optional or other, perfectly feasible ways to completely avoid the issue, to the extend that you made clear what you're talking about.

Hence, I have a slight feeling of some finger-pointing going on - although a re-reading of the thread showed me that you entered from a language-agnostic angle...?!?

So, since you are arguing that a "better" system programming language would (somehow) solve certain unnamed problems existing in virtually every operating system in existence, I was trying to:

1) get you to name which language that would be, or (if not yet existent) what you would consider its distinguishing features, and

2) point out that the ubiquity of C, the massive support in tools, teaching material, support etc. etc., the amount of knowledge found in a large percentage of available programmer manpower, is a "pro" argument in and of itself.

Many a language has stepped to the plate, several of them with undoubtedly advanced features, and tried to replace C (/C++) as the #1 system language. But if you can't get to the point where others write tools and books and libraries and websites for your language, that's a big red cross-mark in your presentation file.

So yeah, go ahead and discuss (albeit perhaps not here, as this site is not really about language development); but expect most people to turn a cold shoulder until it gets some acceptance in the marketplace. It's easy to point at weaknesses in other people's designs, especially 40-year-old designs. It's much harder to come up with something "better", since "better" also means acceptance, and it's hard to beat 40 years in the field.

That's what I wanted to say.