OSDev.org

bzt wrote:- C works. It is here, and have been for decades, and going to be many more. Why trying to fix something that's not broken?

That's what I say .

In which case, why bother with C? We might as well still use PL/I.

Nothing is so good that it can't be improved upon.

I think the low level nature of C (close to Assembler) with its high level features (like loops and all the stuff that you know) is unique.

There is always room for personal preference and coding style, so some might write low level OS code in Forth, some in C++, some in Pascal etc.

Did I mention I don't like C++, too? Still I use it for some code.

Greetings
Peter

bzt wrote:- Pascal, there's nothing I can say about it other than a bit different than C (no run-time needed, works pretty well for kernels. The old MacOS kernel was written in Pascal)

Makes sense, I heard Niklaus Wirth and Ken Thompson studied under the same professor; he taught the importance of simplicity.

I do wonder why Pascal isn't used more. It was very popular in the DOS world before C, but I remember C having a certain glamour over and above the already impressive image of Borland Turbo Pascal. I guess it was the Unix connection. Of all the Big Boys Toys from Serious Computing, Unix was the only one most microcomputer programmers could even imagine getting access to, I think. But then the real reason for C's dominance is probably Linux and Gnu, which quickly came to dominate the emerging web server space while being available to any goof with a 386. Looking at Free Pascal's history, it was ported to Linux in 1994 but really, that was very late to the party compared to GCC. GCC had become a serious choice for commercial use before 1990, so it was clearly the better choice for Linux developers throughout the 90s, especially in the great .com bubble. (And GCC got that way at least partly because Sun tried too hard to milk their customers. Funny how these situations develop.)

Just musing.

eekee wrote:I do wonder why Pascal isn't used more.

Well, it was always a niche product. Pascal was always said to be a good beginner's language (and I concur), which gave it the air of a beginner's language, like Basic. Whereas C was the language for grown-ups. So there was a natural pull away from Pascal and towards C. Next problem was likely a lack of diversity of implementation. in the DOS days you had Borland Pascal, in the WIndows days you had Delphi, and now you have FreePascal. Whereas for C, everyone and their dog have written an implementation, and you can probably find a C implementation for everything that passes electric current.

In direct comparison, Pascal is also clunkier than C, with its "begin" and "end" keywords, the use of the semicolon as a separator, not a terminator, and lots of keywords that seem to only be there to make it perfectly obvious what was happening. I don't know the merits of Wirth having learned the same lessons as Thompson, but it apparently didn't sink in all the way. Why are functions that return nothing declared with a different keyword? They aren't that different! And what is that "then" keyword doing? C manages to make do without it! And the original Pascal rule of only being able to use simple types in function declarations meant you constantly had to define new types.

eekee wrote:But then the real reason for C's dominance is probably Linux and Gnu,

That is probably the reason for its endurance. When Delphi came out, RAD was a new thing, and being able to quickly click a GUI together and have a GUI "Hello World" be not a lot longer than the console version was pretty significant. But soon, RAD tools were developed for other widget toolkits, and Pascal lost that edge. Whatever popularity it had remaining dwindled at that point. Whereas C in Linux has been going strong for 30 years and is barely moving from its place. Other languages come and go, but C remains. Think we will still be talking about Ruby in ten years?

Ah, I've been forgetting things again. @nullplan, thanks for the clarification. In fact, now you mention those things, I remember you're right. I personally rejected Pascal, not because it wasn't available, but because of the syntax foibles. Years prior to that, I remember being surprised to learn of Borland Pascal and Pascal's professional use because of its reputation as a teaching language. C had much less presence to me back in the day, but now I've got FreeDOS, I'm finding all these old C compilers coming out of nowhere!

I've hardly heard anything about Ruby in the last 10 years. Does anyone know how it's doing in Japan, these days? It was a lot more popular over there. Websearching a little bit, Ruby for Android seems to get far less maintenance than AndroWish of all things -- that's Tcl/Tk!

iansjack wrote:In which case, why bother with C? We might as well still use PL/I.

Not by a long shot.

iansjack wrote:Nothing is so good that it can't be improved upon.

Yeah, but what for? Let me answer with some quotes: Some might say C++ is an improvement over C, but if you take at the typical overall project time and the time developers are wasting for waiting for the compiler to do its job, well, you won't be so sure.

Cheers,
bzt

pranavappu007 wrote:Exactly. Actually in the far future I want to get into hardcore C like, well, OS Dev. But nobody is gonna hire a simple guy who just completed his degree(after 1 yr) to make their next revolutionary OS. So I wanted some other stop gap soln. to get experience in C. My initial plan was to go something other than C but is close to C to later make the jump. But now I think it's better to go with something likeWin32, because it is used a lot in traditional applications(everything except store apps as I understand) and is completely compatible with C.

If you really want go into "hardcode C" like kernel development, my personal advice is to stick with it from now (you're a student, right?). Sure, you'll need to learn other languages in the meanwhile like python and bash for scripting etc, but, if you're sure about your plans, don't go working as a C#, Java, Web (etc.) developer. Even if C++, which seems somehow closer to C, in reality is very far from C in the job market. Let me explain that better: once you start your professional career, people and companies will search for you because you have experience with "XYZ", over and over again. Recruiters and hiring managers think about potential candidates considering their "profile". So, if you build a profile different than want to you want in the long term, it will be harder to switch. The "C++ profile" is typically far from the low-level C "kernel/embedded developer" profile. Even if C++ is sometimes used there, 99% of the C++ jobs will be about high-level stuff like software services in the cloud (backend) or video games (but there you need to have knowledge about computer graphics etc.). Other languages like Rust might be used in kernel development too but, it's the same problem as for C++. Actually, it's even worse because there are even fewer job offers for Rust developers.

So, you wanna be a low-level C developer? Start mastering C and system programming in user space. Learn assembly. Learn everything you can while you're a student about compilers, linker, executable formats and especially what's the job of an operating system. In parallel, learn one CPU instruction set (typically x86 or ARM). I'd recommend ARM. In the meanwhile, start contributing to open source C projects. In the Linux world, most of the "stuff" is written in pure C. Forget about finding a job with Win32 + C. It's very rare and there's less and less demand for that. There's very little demand for GUI desktop applications in general, no matter the technology, even less if you want to do that in C. Only in the open source world, you'll find that (see GTK applications). By contributing to open source projects, you'll build A LOT of experience and most companies will value that A LOT. Then, after you have a fair amount of experience with C and assembly in user space by working with other people (that's not a detail), start moving your focus down the stack and start learning about kernels. Contribute to small kernel projects as the ones you can find here or write your own. When you're confident enough, start contributing to major kernel projects, like Linux or FreeBSD. At that point, you'll find a job as a kernel developer. I know it's a long road, but that's the reality. If you really need a job earlier than that, try entering in the embedded/kernel world as an intern, showing just good C knowledge, algorithms & data structures + theoretical understanding of how operating systems work. It might be enough, depending on your skills and the company. If that doesn't work, apply for "system developer" positions. The closer you start to your end goal, the better.

Vlad

C will probably be around for a while because:

• You can get started on bare-metal without a runtime.
• There is a C compiler for every platform imaginable.
• Optimizing C compilers have been around for a long time and can produce very fast machine code.
• C has low-level appeal. You need to build your own mechanism for classes, virtual methods, etc. The sort of people to want to build their own kernel or language (that compiles to C) are likely to be interested in this highly-customizable DIY approach.
• C is a popular language to compile to - so by compiling your custom language to C then using an optimizing C compiler to compile to machine code, your language can run pretty fast.
• C has had nearly 50 years to establish itself for the above reasons. The more time that passes, the more ingrained it becomes, the bigger the improvements the new languages have to be to replace it. So a language that is slightly better than C, might have had much greater chance at widespread success in 1974 than 2014.