Advice for novice programmers thread

[Muazzam]

Why have you deleted my post, mods? You are constantly doing so.

Maybe it's time to quit.

(It's very unprofessional, by the way, without even notifying me.)

[Satoshi]

learn D, you can do everything in it.

[SpyderTL]

I also have Asperger's Syndrome, this makes it so complicated. It's like I need an outline for everything to keep me on track.

Heh, I'm pretty sure that 95% of the people that I work with have Asperger's. They're all socially awkward, quirky, quiet, and can sit at a desk in front of a computer screen for 10+ hours a day.

I like to think that I'm the most "normal" guy in the office, but I guess the fact that I'm on this site several times a day probably makes that very unlikely...

But back to your ability to stay focused on a project... I have somewhat the same problem. I've got probably 30 projects or more that I've started and never finished. I usually get far enough along to prove to myself that I "could" finish it if I wanted to, and then I put it down and go work on something else.

I guess that's one reason I decided to start doing OS development -- because there are so many different problems to solve, and an endless list of hardware to support, once I get something working, I can just switch to something else that doesn't work at all.

So, I wouldn't worry about trying to get everything done, because that'll probably never happen. Just spend a few days working on it, and then take a break for a few days and watch some TV or hang out with your family or something to take your mind off of your project for a while. When you come back, you'll probably make more progress than if you had worked on it for 2 weeks straight.

There have been several threads about how to keep from getting "burned out" while working on this type of project that are worth reading, I think. But basically just work on it when you feel like it, and put it away when you don't.

And, show off your progress in the "What does your OS look like" or the "AWWW YEAH!" threads whenever you reach some sort of milestone. That helps with the motivation as well.

Good luck. Let us know if we can help, or if you get stuck on a problem for more than a few hours.

[SWGDev]

Heh, I'm pretty sure that 95% of the people that I work with have Asperger's. They're all socially awkward, quirky, quiet, and can sit at a desk in front of a computer screen for 10+ hours a day.

Nah, most people don't like to communicate with others. That's why no one wants to be sales manager or something similar.
When learning programming you have to do only one thing - keep yourself away from any distractions. It happens with me all the time. I think that I've read page and then BANG - at the end of the page I can't understand what I've just read. It's really hard, because distractions are everywhere - music, TV, phone, cars in the street... Gosh. I think it's better to learn coding in the closet with your laptop.

[ImmortaleVBR]

My advice is something really fundamental which should be taken on-board by anyone who is considering being serious when it comes to software development, and that is to care about security and test, test, and test your code! Don't rely on your users to be the Quality Control!

1. Debug your code regularly, this can help you find mistakes during the early-stages or diagnose current issues you're trying to understand.
2. Perform regular audits of your code-base and get a second, third, fourth (or more) opinion from other people.
3. If you're stuck, do some research and if you are having difficulty with this, just ask someone (we all get stuck sometimes, there's no shame in it!). Remember to explain what you're actually trying to accomplish and provide as much detail as possible when asking someone for help though, because more often than not (in my experience - at-least when helping on forums regarding Windows driver development or the alike), I find people asking for help on doing a particular thing when in actual fact there is a much better approach that can be taken in the first place.
4. Take documentation seriously. Do not assume but verify. This will make your life a lot easier in the long-run 99.9% of the time.
5. Stay away from undocumented techniques as much as possible. Occasionally, this will not be applicable... It really depends on what you're doing. You'll have no choice sometimes, but it is worth remembering. In the past, I've gone through a phase of being extremely interested in undocumented techniques when working on OS's like Windows, but it can smack you in the face out of no where. At the last, it is risky to rely on the undocumented... And a negative result down the line could be your entire implementation falling apart because of one undocumented factor.

Regarding testing your functionality, do not limit this to your own environment. Consider what could impact the functionality you're implementing into your product and implement measures to help improve the stability under the impacting conditions, and simulate tests on a wide-variety of hardware and software configuration environments.

The last piece of advice I can think of from the top of my head right now is to remember the enjoyment factor and to be open about learning more; from my experience, you can never really learn something 100% - I've been mislead in the past into believing there was nothing else I could learn about a topic after working with the said product for years even, only to discover something new later down the road. It's an easy mistake to make, but try not to make the same mistake I once made!

I hope this helped someone out there.

[Solar]

Coming back to this a long time later, I'd like to pick up the very first post made to this thread by Schol-R-Lea, and add a completely different take -- partially because I had been involved in some novice-level teaching recently and had done some research in preparation for that. Also because the field of available languages (and the available versions of preexisting ones) has changed since 2003.

If I were to suggest a specific curriculum, it would be:

• Start off learning HTML markup [...]
• Learn a language that can be run interactively [...]
• Go on to a simple compiled language [...]
• Learn some assembly language [...]
• Learn the basics of Perl scripting [...]
• Now dive into C, and learn it in depth [...]
• Go back and learn more Perl, or another scripting language like VBA [...]
• Last, tackle either C++ or Java, depending on what you mean to be doing with it. You can always go back and learn the other; you should by now have enough language experience under your belt that even a massive language like C++ should be easy to learn enough to work in.

This is a "bottom up" approach. It takes you for a really long trip of either old or dumbed-down languages before you arrive at a point where you can do things comfortably. I would advise against learning old / low-level stuff first, because there are a lot of things you have to learn and do in those environments that are simply no longer necessary in today's environments. What makes learning them positively harmful is that you usually still can do it that way in modern languages as well; you are just making things needlessly hard for yourself, and will have to unlearn a lot of the things you had to struggle through.

My recommendation today would be:

* Get a Bash command line environment -- Linux and MacOS come with it included, for Windows I still recommend Cygwin (or it's GUI-packaged derivative, MobaXTerm) over "leaner" solutions.

* Learn to walk. Understand what a shell script is, and an executable. Understand was a return code is, and how a script can use another script's or executable's return code to decide how to proceed. Learn what a loop is, and what standard input / standard output are for.

* Pick an editor you're comfortable with -- good ones are Notepad++, UltraEdit, or Vim (the latter being my personal choice -- steep learning curve, but oh-so-rewarding once you're "in the zone"; and literally available everywhere). The editor is the tool of your trade. Do not skimp. Read the docs. Learn the advanced features (regular expressions and macros, especially). Practice. Do not "make do". (I will advice against IDEs further down -- editor knowledge is portable, most IDEs aren't.)

* Pick either Java or C++, right from the beginning. My tip for those that actually get to osdev.org for their "novice advice" would be C++, because it does allow you to go down all the way right to the metal if you want to. Java has strengths at the other end, with large-scale web-driven applications, and is also the language of choice for mobile app development... but you can switch from C++ to Java easily, while the other way around is fraught with problems.

* Do not learn C first; learn the state of the art top-down. (Yes, do watch that video, even if you only understand a fraction of it -- it gives you an idea of what to look for in study materials.)[1] Don't worry about how things work "under the hood"; instead, get some nice quick results using all the nice things the standard library gives you. Use vectors, maps, range-for's, smart pointers and lambdas. Not a bit of what you will learn there will ever go to waste. Once you are comfortable there, start digging down at whatever pace suits you -- nobody needs arrays, zero-terminated strings, and naked owning pointers these days -- not as a novice.

I do second the point about "do not use an IDE", though. These things hide too many things from you for questionable gain, and bring a whole bunch of "what's this button doing" problems that tie in your learning experience with a specific IDE instead of making you comfortable with the language per se.

* Write a Makefile.

* Get things under version control. The craze today is Git, but even after all these years I still feel it is oversized and overcomplicated for anything that does not involve quite a large number of concurrent developers; I prefer and recommend Subversion as it's easier to handle and will give you an understanding of what e.g. branches and tags are before tossing you into deep water and adding another level of remoteness like Git does.

* Pick something that interests you, and could conceivably give you short-to-mid-term results. Yes, I recommend against starting an OS as your first project. That is a hard truth. Instead of setting yourself up for failure, write a recipe manager, a vocabulary trainer, a calendar, or something along those lines. Yes, done before thousands of times, but you understand the problem domain, you can "get there" on your own, and you can actually use the result. You also learn handling data structures where you can see and debug them with ease, instead of facing hardware registers and triple-fault reboots.

* Get crackin'.

You will come to a point where you will want to pick up other things -- Perl, Python, XML, SQL, whatever. But you need none of those to get from A to B, they are just making things easier -- and none of them will serve as a go-to foundation. Pick them up as and when necessary.

----

[1]: Two of the many really good lines from that vid:

"'One of the great things about C++ is that it is the language for smart people; and one of the bad things about C++ is that it is the language for smart people.' Why is there this barrier to entry that says you have to be super super smart? Believe it or not, a lot of that comes from what we put people through in the first two days of their five-day Intro to C++ course, and a lot of that isn't even C++."
-- Kate Gregory

"I am not trying to make library writers. I am trying to make library users. It is alright, if you are going to be inducted into the tribe of library writers, for someone to pull back a curtain and show you a lot of stuff, a lot of punctuation -- "...", says Andrei, is where the fun begins -- that is OK for the people that are going into that tribe."
-- Kate Gregory

[Antti]

As far as "C vs. C++" is concerned, this a very tangential point but I'd like to write it down anyway:

I don't think it would harm to understand very basics of assembly. This example is written in C and compiled to assembly and, although this is for x86 CPUs, it uses universal instructions like "mov" and "add" that should be available in every instruction set. As an OS hobbyist, my opinion is very biased but I believe that many programmers would be happy to know that there was no "magic" in it. If programmers did never study this at all, they could have very imaginative theories of what is happening under the hood. For low-level programmers and OS hobbyists this is obvious but not for everyone.

By the way, I'm a bit worried that things like "integer overflows" are considered as "advanced topics" although those should be the first lessons to be taught? Perhaps after the "hello world" to make studying a bit more appealing.

Code: Select all

struct osdev {
        const char *name;
        unsigned long posts;
};

const char *get_name(const struct osdev *This)
{
        return This->name;
}

unsigned long get_posts(const struct osdev *This)
{
        return This->posts;
}

void increment_posts(struct osdev *This)
{
        if (This->posts + 1)
                This->posts++;
}

Code: Select all

_get_name:
        mov eax, dword ptr [esp+4]
        mov eax, dword ptr [eax]
        ret

_get_posts:
        mov eax, dword ptr [esp+4]
        mov eax, dword ptr [eax+4]
        ret

_increment_posts:
        mov ecx, dword ptr [esp+4]
        mov eax, dword ptr [ecx+4]
        add eax, 1
        jz .L1
        mov dword ptr [ecx+4], eax
.L1:    ret

[Schol-R-LEA]

I agree now that C isn't where to start; that doesn't make sense any more.

The problem was that most C++ courses at that time I wrote that basically taught "C, but using the iostream operators". My impression is that this is still pretty much true, and that video just reinforces that impression, since it mostly about why that's a Bad Idea (something that you shouldn't need to have to say, but apparently do).

Though most schools don't seem to teach anything other than Java or Python, now, anyway, so the argument for 'teach C++ first' is moot; no one learns either one of them as their first language these days, not in formal settings at least.

I also am pretty embarrassed by the emphasis on Perl (I language I never really liked, but which was ubiquitous for scripting back then), but at the time, it made a lot of sense.

I still think starting with something like Python or Ruby makes more sense than C++, Java, C#, or any of those, if only because they don't get in the way the way all of the curly-brace languages I know of do. You wouldn't need to convince people to use the standard collection and string types up front - it's obvious to do that.

And as I have said before, the only reason I didn't recommend Scheme first and foremost is because the Scheme libraries and toolchains are about as consistent and well standardized as Michigan tap water. If I were to recommend a Lisp today - and I sorely would want to - it would be Racket, but there's a lot about that which I find a bit irritating. Clojure is a good choice too, if you hate variable re-assignment and want to go FP forever, but that's not for me personally - if you want Haskell, you know where to find it.

I definitely don't agree that C++ is the language for smart people - in fact, I have come to deeply loathe the curly-brace languages in general. Also, IMAO the 'language family for smart people' hasn't changed in 60 years - and it ain't the Algol family that C is a branch off of. But you know my biases on that - my .sig makes that part clear - and most people dislike Lisps as much as I dislike Cs, so I don't expect you to agree with me about it.

[Solar]

[...] most schools don't seem to teach anything other than Java or Python, now, anyway, so the argument for 'teach C++ first' is moot; no one learns either one of them as their first language these days, not in formal settings at least.

Schools teaching Java / Python are basically feeding the industry needs -- rapidly educated Junior Developer manpower for Rapid Application Development needs. They're the conveyor belt of developer education, turning out tools (meant in a non-offensive way).

I considered this thread to be asking about an individual that is setting out to become a programmer, on his own volition, as a long-term career choice, with an eye on becoming a Senior Developer, i.e. looking to build the strongest foundation possible. More the manufacture turning out a gem.

That's why I would teach C++ first. The foundation you can build without changing languages is broader, including quite some functional programming if you're got a really good instructor. (Definitely not holding a candle to LISPs, but at least preparing yourself for the style.) While yes, the language is quite complex, but on the other hand it can be made into a big comfort zone of "I've seen similar things done already". It also gives you a head start should you decide to go for systems development, or "the backend stuff" (VMs, RDBMs, high-performance server architectures etc.), where it's still the language of choice (and not really facing much competition so far).

But I don't want to turn this into a to-and-fro discussion; I was merely taking some points I mentioned in this thread before, some experience gained in more recent years, and some things I hadn't said yet and put it into "my take" on the thread subject. I'm fine with other people suggesting different things.

[Schol-R-LEA]

Fair enough.

[glauxosdever]

Hi,


I think that C is a good language to start, because it exposes the low-level details without getting too much architecture-specific. In the uni, we started from C (although we learned it with some very serious omissions), then we did Java. We are doing data structures just now, algorithms are in the next semester.

Since we are talking about advice for novice programmers here, would anyone be interested in starting a project where novice programmers get to know stuff better than any time-pressured uni would teach? Specifically, some guides for programming languages (e.g. C), data structures (arrays, stacks, queues, lists, etc), algorithms (searching, sorting, etc), various fields of maths (calculus, linear algebra, discrete maths, probability theory, etc -- not going to contribute those, since I don't trust myself at maths), CS fundamentals (binary, octal, hex, binary addition, binary multiplication, bit shifting and rotation, boolean algebra, etc), digital logic, networking stuff, etc? Possibly with good explanations, examples and exercises? Of course, it'd not be to replace unis (no degrees obtained here).


Regards,
glauxosdever

[nullplan]

If you want to learn but no pressure, then self-teaching is going to be the only way. Only that requires the discipline to actually go through with it.

My first language was Pascal, and back then (late 90ies, early naughties) it was a treat. Such a shame that the C standard allows so many things in regards to "testing all array accesses", but it is hardly ever done. Even now we have address sanitizer and it is hardly ever used.

Pascal also impressed the fundamental divide between interface and implementation into my mind, and that was very helpful for learning to deal with Java and C#. But Pascal always felt a bit like a toy. So then (ca. 2006) I got into Linux, and with that into C, given that most projects on that platform were and are written in C. And I immediately liked the way things were better defined in C than in Pascal (for example, in Pascal you have the type "integer" and not really an idea of what that is supposed to be, whereas in C you have "int", "long", and "uint32_t", and while all three might be (almost) the same type, each has a different definition for different use cases. And those were absent from Pascal. Just to name one example. Another would be how in Pascal it is impossible to create variadic functions, and yet the language itself provides four of them).

The most important thing I ever did was subscribe to the "de.comp.lang.c" newsgroup. While there, I learned way more about C in particular and programming in general than I ever did at Uni. Not to say Uni wasn't important, it just wasn't important for the craft of programming. Uni teaches computer science, which is completely different from programming. Honestly, if you're a CS graduate: When was the last time you needed the pumping lemma for something?

So let that be my advice: Whatever language you get into, find yourself an active community for that language and learn from the experience of others.

[Schol-R-LEA]

Pascal also impressed the fundamental divide between interface and implementation into my mind, and that was very helpful for learning to deal with Java and C#. But Pascal always felt a bit like a toy. So then (ca. 2006) I got into Linux, and with that into C, given that most projects on that platform were and are written in C. And I immediately liked the way things were better defined in C than in Pascal (for example, in Pascal you have the type "integer" and not really an idea of what that is supposed to be, whereas in C you have "int", "long", and "uint32_t", and while all three might be (almost) the same type, each has a different definition for different use cases. And those were absent from Pascal. Just to name one example. Another would be how in Pascal it is impossible to create variadic functions, and yet the language itself provides four of them).

Which brings up one of the might-have-beens of the programming language world: what would have happened if there had been even one decent Modula-2 compiler for the PC that didn't cost $400+ (1985 US dollars) and some of the other things C had but Modula-2 didn't.

Wirth designed Modula-2 as a successor to Pascal, but added several of the things you've mentioned as missing. It was cleaner and better defined than either Pascal or C (Pascal was actually better defined than C, but with a different goal; Pascal was always meant solely as a teaching language), with far less confusion in handling things like pointers and so on. It was designed to fit more or less the same niche as C, but with Pascal's syntax, a very well-designed module system and built-in concurrency primitives.

(It was also case-sensitive, unlike Pascal, but that's a topic people still fight over today.)

The standard integer types are CARDINAL, INTEGER, and LONGINT, while the FP types are REAL and LONGREAL (the identifier FLOAT exists, but it is for an int-to-real cast function); the ISO standard added COMPLEX and LONGCOMPLEX, as well. There are also CHAR, BOOLEAN, and BITSET types, which are not numeric types in any way, shape, or form.

Unfortunately, not only did few people hear about it even at the time, those who did were mostly put off by the verbosity; by the pointer security (despite having a much easier pointer system to actually use than C's); by the fact that linkable compilation units required separate 'definition' files which it used for linking; by the use of p-code compilation rather than native code in most of the inexpensive compilers (absolutely deadly for a systems language of the time) and those which did compile to native code were inordinately expensive, hard to get, and loaded with licensing restrictions; the ISO standardization came over a decade too late to help; the standard I/O library of the pre-ISO versions was extremely limited; the way the 'clean and clear code' crowd were split between supporting either Modula-2, Ada, or extended versions of Pascal; and the fact that it lacked the sort of killer app which Unix was for C.

That, and as I've said before, the fact that it was cleaner meant fewer (simple) bugs, and hence less paid programming time, which made it less competitive precisely because it was 'better' than C.

I've waffled in the topic a lot over the years, but I now think Modula-2 is a better systems language than either C or Ada. It is almost as small and concise as classic C, but with a much easier to read syntax and a proper module system instead of the cheap hack that is header files. But even at the time, that was very much a minority opinion, and in any case, I favor Lisps over all of them anyway.

[Solar]

...the use of p-code compilation rather than native code in most of the inexpensive compilers (absolutely deadly for a systems language of the time)...

Just now I've read this take on p-code by Robert Nystrom of Game Programming Patterns fame (added here for completeness' sake):

One of the first bytecode formats was p-code, developed for Niklaus Wirth’s Pascal language. You might think a PDP-11 running at 15MHz couldn’t afford the overhead of emulating a virtual machine. But back then, computers were in their Cambrian explosion and new architectures appeared every day. Keeping up with the latest chips was worth more than squeezing the maximum performance from each one. That’s why the “p” in “p-code” doesn’t stand for “Pascal”, but “portable”.

[0b1]

I have become a big fan of nodejs in the past year. Now that ECMA is fully OO without jumping through hoops, you can use it to script build processes or just about anything else you have a mind to.

I started out using it as a web backend, but now i use it in my OS project to create file systems, parse memory dumps, and I'm working on a packet responder/simulator for BOCHS, which will not talk to my network at all!)

Plus, you are learning a language that is versatile and in very high demand: it's used for microservices, web applications, and everything in between. And its basically the JavaScript you see in the browser now they have all caught up (reasonably well) with the ECMA standards.

{And I love squirly braces, strange for someone who coded for his first decade exclusively in BASIC}. I guess they give me a good sense of closure