Real alternatives of C

[eekee]

I forgot that I had a thread in here

I do that if I don't get email reply notifications... and sometimes when I do.

I googled about forth and it is as old as C or older. Also, when I look at an example, it is much weirder than languages I've learnt(basically C..). I think it is more used for scientific computing or such, and I've read that it is extensible and therefore not consistent from program to program. Even if I learned it it is less used than C and I don't see it's becoming widespread than C in future.

It's definitely weirder. I've come to the conclusion that basic proficiency in Forth requires a wide variety of skills; more so than C. Its extensibility is its great power, but I think everyone who works with it likes to keep it to smaller projects. On the other hand, as a primitive OS, I think a native Forth systems could be much more consistent than what I experienced in Unix and Plan 9 from Bell Labs: an awkward hodgepodge of domain-specific languages with C. From printf format strings to sed and later sam, all these DSLs are cryptic and kind-of awkward and it takes effort to make them work together because they all have different syntaxes for their "plain text" data. Awk is the best of them but it feels like an outsider to the others, being much more powerful, especially on Plan 9. Forth is exceptionally good at DSLs because it's extensible and its syntax doesn't get in the way; you can write DSLs in the language itself instead of consigning them to strings or whole separate interpreters. (The same is true of Lisp.) That's basically my plan; an OS as componentized as Plan 9, (it's better than Unix in that regard,) but more consistent and powerful in its components. I have an idea for better pipes, amongst other things. But Forth is at least as bad as C when it comes to shooting yourself in the foot. I keep coming back to the idea that I should have chosen Lisp instead, but a reasonably efficient Forth compiler can be much simpler than a reasonably efficient garbage collector alone, if I'm not mistaken. And yes, I'm crazy enough to want to write a compiler and an OS!

I was thinking about learning Win32 API in C as Windows developer can get more jobs than just C dev. I kinda looked at the basics, it's hard too. But, I think I don't need to use much C++ features if I have to code in CPP. Is it a good idea?

Uh... it's C on Windows, so if it's not your long-term plan, yeah? I say "not your long-term plan" because Win32 is very old and very bad -- at least the graphics side of it is widely considered very bad. I heard Microsoft have tried to kill it off, but much like x86, demand for compatibility has kept it alive. I imagine there's a few years left in it; time to get practice with C while getting paid. I don't know what the C vs. C++ situation is in that field.

Just to scare you, there's an image somewhere on the Net with listings of minimal graphical hello world programs in Win32, X Windows (probably Xlib), and Plan 9. The Win32 listing is in a font half the height of the others and is still more than twice the length of the X listing... and people hate X for being too much work! The Plan 9 listing is about 1/5th the length of the X listing. It's a shame there are virtually no Plan 9 jobs.

[pranavappu007]

Uh... it's C on Windows, so if it's not your long-term plan, yeah? I say "not your long-term plan" because Win32 is very old and very bad -- at least the graphics side of it is widely considered very bad. I heard Microsoft have tried to kill it off, but much like x86, demand for compatibility has kept it alive. I imagine there's a few years left in it; time to get practice with C while getting paid. I don't know what the C vs. C++ situation is in that field.

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.

Just to scare you, there's an image somewhere on the Net with listings of minimal graphical hello world programs in Win32, X Windows (probably Xlib), and Plan 9. The Win32 listing is in a font half the height of the others and is still more than twice the length of the X listing... and people hate X for being too much work! The Plan 9 listing is about 1/5th the length of the X listing. It's a shame there are virtually no Plan 9 jobs.

Actually I built a simple app to print out some system metrics.. yes it's hard.. and actually there is not much organized tutorial like resources that is new.. I'm actually following a 2002 textbook pdf which is 1998 Windows NT based and correcting myself using Microsoft Documentation..
Also I would like to ask, Is there any other method to code for windows except store app and legacy Win32, as you said win32 has only some years left? If all traditional apps are in it, that is not the case..?

[iansjack]

Win32? Surely everyone uses the .NET framework nowadays for non-universal Windows programs?

[thewrongchristian]

Also I would like to ask, Is there any other method to code for windows except store app and legacy Win32, as you said win32 has only some years left? If all traditional apps are in it, that is not the case..?

Very much depends on what you're trying to do.

If it's front end work (GUI) you can use any toolkit to wrap and hide the Win32 nastiness from you. Something like Qt, GTK+ or wxWidgets, with the added benefit that these tend to be cross platform.

If you're not wedded to C/C++, other languages will shield you from Win32. C# and Java, with their respective tool kits, will be both cross platform and abstracted away from Win32. You can also use scripting languages like Python and TCL with TK, for example.

If you're working in the back end, then you have a myriad of choices, both Windows specific and cross platform.

With the advent of the web based apps, we're largely freed from the shackles of Win32 to reach a mainstream audience.

But it doesn't matter if Win32 only has limited life for new applications. I'd be surprised if anyone is writing anything new to native, bare Win32, but there are plenty off applications already written that need maintenance, so as a skill, it may well be marketable for some time to come.

[pranavappu007]

I'm actually looking to make my career C based, cause I like working with C than other languages for some reason. I like hacking things together, or that control C provides. But that doesn't mean I want to code only in C.

So, for a job, I am looking to learn some non web API(I don't like web for some reason) like Win32 or .NET. So, what should I choose? Is there an advantage for Win32 in market? or it's the other way around? I like to stick with C, but I prefer job stability more.

[iansjack]

Choose .NET.

[pranavappu007]

Choose .NET.

.NET doesn't support C, so which language should I choose for it?

[iansjack]

You can use .NET with C (or C++), but it's a better fit with C#.

[nexos]

If you're taking up Win32, read Charles Petzold's renowned Programming Windows. It can be purchased off Amazon. I'm no Win32 expert, I know the basics, but not the more complex stuff.

[iansjack]

C and C++ have much more jobs than Rust. (But Rust is still a decent replacement for C)

Amazon are now hiring Rust programmers. That's quite a recommendation.

[AndrewAPrice]

I have college experiences for C++, but I can't exactly figure out how those OOP concepts of C++ map to assembly.

A C++ method call is just a function call, but there is a hidden first parameter `this` that passes in the object you're calling the method on.

You can emulate the OOP model in any language by passing around the object explicitly.

e.g. You can turn this C++:

Code: Select all

class Cat {
   Cat(int age) : age_(age) {}
   ~Cat() {}
    int GetAge() { return age_; }

    private:
        int age_;
};

Into this C:

Code: Select all

typdef struct {
  int age;
} Cat;

Cat* CreateCat(int age) {
  Cat* cat = malloc(sizeof(Cat));
  cat->age = age;
  return cat;
}

void DestroyCat(Cat* cat) {
   free(cat);
}

int GetAgeOfCat(Cat* cat) {
   return cat->age;
}

And implement similar functions (CreateCat, DestroyCat, GetAgeOfCat) in Assembly.

[PeterX]

Code: Select all

typdef struct {
  int age;
} Cat;

Cat* CreateCat(int age) {
  Cat* cat = malloc(sizeof(Cat));
  cat->age = age;
  return cat;
}

void DestroyCat(Cat* cat) {
   release cat;
}

int GetAgeOfCat(Cat* cat) {
   return cat->age;
}

And implement similar functions (CreateCat, DestroyCat, GetAgeOfCat) in Assembly.

I think

Code: Select all

release cat;

should be

Code: Select all

free(cat);

And I would recommend putting the class/struct name at the beginning like cat_create() or CatCreate() . But in general you are right.

Greetings
Peter

[AndrewAPrice]

I think

Code: Select all

release cat;

should be

Code: Select all

free(cat);

You're right. I made an embarrasing mistake!

[PeterX]

You're right. I made an embarrasing mistake!

Not embarrasing, but normal when you think about both C and C++ at the same time. It's like translating between English and French.

BTW Linus Thorvald said once that they are actually using OOP in C in the filesystems code.

Greetings
Peter

[bzt]

Here are some kernels written in various languages.

My personal opinion on the matter from what I've learned doing those kernels:
- 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?
- C++ I worked with it for more than a decade, and I don't like it. I was unlucky enough to work on projects for years where my job was to fix beginners mistakes in an inherited code base. C++ is a write-only language for sure. Plus it always gets in my way when I try to do low level stuff (as its creator said "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg." /Bjarne Stroustrup/). I'm not alone with this (read here, and here, oh, and of course here).
- Ada is really good, but needs some serious run-time (which is already provided) for it's wast range of features, and it has a long learning curve (most complex of all the kernel-capable languages)
- 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)

And now the "new" languages
- Rust, just take a look at the numbers of required files to compile that simple Hello World kernel.
- Go, was the biggest s*ck from all by lightyears. No pre-compiler, not possible to link with font.o, no support for static character arrays (only strings), no way to figure out which run-time features will be used (unresolved dependencies just pop up along the way as you try to write your code). You can't even create a typedef struct without run-time support!!! Holy ***, definitely not a C killer, and never will be!

Cheers,
bzt