OSDev.org

pranavappu007 wrote:

PeterX wrote:[Maybe it is system programming on a userland level instead of kernel development. And it is true that that doesn't give you the best job opportunities.

Yes, I have to learn complex stuff to be a pro. But you can't learn till you get professional skills and then get a job. Work experience is a part of becoming pro.

My question was simple. Now, I have intermediate skills at C and beginner skills at Assembly. But, I don't think sticking to C will get me a job right away, as I don't think embedded programming jobs will be given to beginner level programmers, and also kernel level stuff. So until I get a job and become a pro, my C probably won't be helpful.

I need a language that can get me a job quickly, and the experience will be helpful for my C skill, so that I can become a pro and get inside low level programming community and back to C finally.

Sorry, my answer was more generally on the job situation. More to the point of your question: Yes, both Rust and Go are candidates. But why shouldn't you get a job with just C knowledge, I don't understand that? And don't forget: You don't have to be perfect to get a job.

Greetings
Peter

PeterX wrote:But why shouldn't you get a job with just C knowledge, I don't understand that? And don't forget: You don't have to be perfect to get a job.

Because C jobs are few and far between and they require higher skills?

pranavappu007 wrote:

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

Will that be the case in future, tho? I heard the rust compiler is smart and can detect a lot of logic errors and stuff.

I am not confident that I can predict the future of Rust (it's still a young language) but I am sure that C will remain relevant for at least two decades. The amount of C code out there is simply too big to be replaced within 10 years.

In the long run, you want to be able to work with multiple languages. Being also able to write a single language would unnecessarily harm your career. Even if you do system programming, you need to know at least one decent scripting language (probably Python) and all common build systems.

pranavappu007 wrote:I don't know about Go, but I've heard it is more of a language for server stuff. Does it output executable binary?

It does.

Korona wrote:I am sure that C will remain relevant for at least two decades. The amount of C code out there is simply too big to be replaced within 10 years.

For what it's worth, a couple years ago I was trying out a program called agrep (a fuzzy grep) that I found online and was dated 1992. The C code compiled and ran perfectly without any modifications, not even to the Makefile.

There aren't a lot of languages that can claim that kind of longevity. C isn't going anywhere for a long time.

Korona wrote:In the long run, you want to be able to work with multiple languages. Being also able to write a single language would unnecessarily harm your career. Even if you do system programming, you need to know at least one decent scripting language (probably Python) and all common build systems.

Yes, currently I know only C and maybe x86 asm. That is why I need to learn some other more general case language like Go or Rust(currently recommended by you guys).
But why python tho? It is mainly used in scripting and AI and stuff, right? And maybe server side stuff. I tend to look more on desktop applications and such. Probably I'll have to take a course on Win32..

Python is a very different language in that it uses so-called dynamic types. What is happening is types are validated at runtime as opposed to compile time.

JavaScript is also like that, but a much harder language to use than Python (for example, it will automatically convert types to other types and confuse you at times).

Python is used a lot for build tools, but I'd say the main value of Python is that it will show you a different way of thinking about programming.

Forth is a real alternative to C, and can cover everything from the lowest level to the highest in one language. You do have to learn some different ways of thinking; it's easier to shoot yourself in the foot with Forth than with C. You also have to break things down into tiny pieces to cope with the stack effects, but this same practice can help build reliable code: you test all the pieces as you go. The abundance of interactive Forths also helps with testing. Ultimately, the advantage seems to be with Forth: it's well-known in the Forth community that good Forth programmers can reach targets in far less time than C programmers take; 1/4 or less.

As for Go, it was intended to be a systems language when first released. It was intended to be a replacement for C++, but the C++ programmers didn't want it. I think a lot of changes have been made to its toolchain since then, so I don't know how hard it would be to build an OS with it. I think it's ended up in "server stuff" because sysadmins love Unix and Go was written by basically the same people. But I don't have any high praise for Go.

eekee wrote:it's easier to shoot yourself in the foot with Forth than with C

Wow. Considering how easy it is to shoot yourself in the foot with C, that is not exactly a ringing endorsement. Most C replacement languages have been focused on making that particular thing harder, not easier.

Indeed it isn't, but what's amazing is how it doesn't seem to matter. It's probably the completely different development practice of Forth: test every little piece as you go. I have to admit my opinion is probably influenced by using Forth interactively. This is wonderful for testing, but when you use it all day every day, even when you're tired, there are a lot of things you can trip over.

I would say that Forth is worth learning at least a little about, just as a matter of principle, as it is quite different from Algol family languages in very Illuminating fnord ways.

The same applies to Smalltalk, Haskell, APL, SNOBOL, and the various Lisps, too. Even if you never use them, they are worth knowing about, just because they are so different from the general run of languages. However, they wouldn't qualify as C replacements for the most part, whereas Forth does.

(Though Smalltalk was used for large parts of the original Alto operating system, the various Lisp Machines all used their own Lisp dialects before Common Lisp came around, there are ways to use Common Lisp for OS dev on a PC with a lot of effort, and I am hoping to use a Scheme derivative for OS dev myself.)

While you are at it, check out the List of Programming Languages, Rosetta Code, or to really blow your mind, the Esoteric Programming Languages wiki. The sheer number of esolangs with names which resemble line noise (NSFW) is worth a look, IMAO.

I should add that, from my own perspective, the various 'dialects' of Lisp are very different languages from each other, in some ways more so than most of the languages derived from C - C++, Java, C#, etc. are all quite similar to each other in many ways, but everyone agrees that they are different languages, whereas Scheme and Common Lisp are at least as different from each other as C is from Ada but are often termed as just variants of Lisp. Most people don't see that, since they have a shared core syntax and central concept.
We lost the documentation on quantum mechanics. You'll have to decode the regexes yourself.

I should have mentioned that Forth programmers use a lot of functional programming techniques, presumably to avoid shooting themselves in the foot. I forgot my initial plans for Forth included a set of APL-like array features for this reason.

APL has run on bare hardware, not so much as an OS as a way to use the language with its special character set; a feature which causes difficulties with conventional terminals. When 16-bit systems with decent graphics became affordable, APL68K was produced and it ran on a bare machine. APLX is a descendant of this, and its documentation still likens functions to programs. It doesn't mention that variables are basically data files, but they are and they can have complex structures understood by the language. I like that.

I considered trying to write a bare-metal APL myself, and build more of an OS with it. It would be a very big job; a compiler, standard library, and an OS because there aren't any open-source APL systems, but I think the wealth of array operations (1D and 2D) would take a big chunk of the work out of string and graphic libraries and maybe others. I rejected it because, when using APL interactively with its strict right-to-left evaluation order, I found myself constantly having to insert parentheses whenever I modified an expression. Perhaps I should have used more temporary variables. I find Forth syntax better with its left-to-right evaluation order, (not to mention easier to read!) but it's clumsy when you have to manually handle the type and size of every piece of data, even interactively. Simple calculations require different operators for floating point or integer numbers. Every different array-ish or list-ish task (e.g. text editing) needs its own small library, and it's taking me a long time to find good ways to do the different things. I found a few new tricks this week, but they were for such basic things; equivalent to things I learned in the first week of my interest in APL. It's probably just the weird way my brain works; I do not get on with lots of different words for similar things. I suppose I could still try to build those array features with type and array shape stored with the data, allowing a few words to work with a variety of types. It would pretty-much be a standard library project and then implementing all the useful things on top of that.

I didn't mention Plain English Programming. I've been thinking of it as kind-of borderline as a "real" alternative to C, but maybe that's because it's still rather new and its overall style is rather lighthearted. Despite that, I think it's closer to the machine than Lisp. It's also a language with a decent set of types (he said with feeling)... but now I remember there's no actual array type; another reason it's borderline. It uses lists instead, integrating them with records (structs for you C types). I imagine adding arrays would not be terribly difficult, but haven't looked into it yet. Anyway, I started a wiki page on it today. It's rough because I was half-asleep all day, but it has some info and perhaps all the available links already. The documentation is limited but the language is, of course, more self-documenting than any other for those fluent in English. That's the other thing I love about it.

I have to disagree with eekee and Schol-R-LEA here. Yes, these languages can solve the same tasks that C can. But they are not an alternative to C since they lack the ecosystem. There is at least 2-3 orders of magnitude more C code than there is Lisp code even though Lisp is considerably older than C.

That doesn't mean that these langs are not worth learning, but they should be learned in addition to C and not as a replacement. My own two cents: out of all the langs listed, pick Haskell, or maybe a Lisp derivative, as both of these will teach you unique methods. To be honest, I do not like stack-based languages like Forth too much, developing a compiler for the JVM (which is stack-based) killed my enjoyment of these.

Korona wrote:I have to disagree with eekee and Schol-R-LEA here. Yes, these languages can solve the same tasks that C can. But they are not an alternative to C since they lack the ecosystem. There is at least 2-3 orders of magnitude more C code than there is Lisp code even though Lisp is considerably older than C.

Spoken like a true POSIX developer! There's nothing wrong with that if it's what you want. However, I'd just like to make the small counterpoint that there is far more base-library code for Forth in the public domain, both for ANS standard Forth and non-standard. There are even public domain compilers.

Korona wrote:That doesn't mean that these langs are not worth learning, but they should be learned in addition to C and not as a replacement. My own two cents: out of all the langs listed, pick Haskell, or maybe a Lisp derivative, as both of these will teach you unique methods. To be honest, I do not like stack-based languages like Forth too much, developing a compiler for the JVM (which is stack-based) killed my enjoyment of these.

That's all fair enough. I have struggled with Forth at times. Some (not all) of my struggles are evident from my 2 previous posts in this thread. It also took me time to get comfortable with writing it. My skill, comfort and development speed have improved exponentially over time. I got quite a lot done (by my standards) in the 2 days since my last post here.

I forgot that I had a thread in here

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.

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?