At what point should a coder learn C and ASM?

[mac]

I downloaded a compiler IDE for DarkBasic Professional (specialising in game dev), BASIC does count as a beginners language right? I think it would still count. Anyway, after I know a little BASIC programing concepts and experience, I move straight to C. Right?

Experimenting with Linux a bit had helped me get into actually reading manuals and documentation better. It forced me to think ahead more.


I know these sound very obvious, but what's your opinion? My target end goal is low level programing, I crave the idea of doing things like hardcoded GUIs and all that neat stuff.

[alexfru]

I can't tell for sure. It depends on what you already know, whether you actually need either of them and how much effort you're going to put into learning.

My progression was this since around 1991:
ZX Spectrum ROM Basic
Z80 assembly language (I actually wrote most in machine code because the assembler was taking too much time to load from tape)
Pascal with Borland/Turbo Pascal 5, 6, 7
8051 assembly language
x86 assembly language with TASM, MASM, machine and inline in Turbo Pascal 6 and 7
C with Borland/Turbo C++ 3, DJGPP
Since then I've picked up some C++, Perl, Python and worked on a variety of architectures (TI 54xx/55xx series DSPs, ARM, PPC, MIPS) and platforms (embedded, Linux, Windows) with different compilers (Microsoft C++, gcc, clang, etc).

I struggled with C for several years despite knowing what kind of CPU instructions it would eventually turn into, despite being able to write in assembly or machine code. Oddly enough, asm was much easier to grasp (unless we go into x86 memory management and protected mode). It was defined much more precisely than C. The problem was that at the time there were very few good books on C that I could get and literally none at my disposal. And almost nobody around programmed in C at the time (there was one person whom I saw on occasions sufficiently rare to bar any C learning from him). So, I first had to make pretty much every mistake possible, learning the hard way from how my C code would fail to work or break when compiled with another compiler. C is not intuitive and in a number of places outright awkward or broken by design. Some of its crazy stuff has to do with its origins, the history of how it came to be. Of course, one is rarely bothered to learn about that before learning C and many have no idea that there was something in the past that could help understanding the language in the present.

Things improved with extensive practice and with reading the C standard (not an easy read first couple of times).

Why don't you give it a shot?

If you decide to learn C, get a known good book on it (e.g. K&R 2nd ed, there are others). There are also bad ones (stay away from Herbert Shildt's books and any books of the "Learn X in Y days" kind; they will either teach you bad habits or provide you with insufficient info, which may lead to creating bad habits or writing fragile code (by bad habits I don't mean things like code style/formatting/copy'n'paste/commenting, I mean code that is syntactically correct and can compile but isn't guaranteed to work as you might be expecting, which also known as undefined behavior, unspecified behavior and implementation-defined behavior)).

[Muazzam]

You should start with event-driven languages such as C# or VB.Net. Also see http://smallbasic.com/.

[Brendan]

Hi,

I know these sound very obvious, but what's your opinion?

In my opinion; there's 2 groups of people with opposite views.

The first group thinks it's best to learn very high level languages first, and then learn lower level languages later. In this case students tend to get to things like pointers and get all confused, and these students are less likely to become good low level programmers.

The second group thinks it's best to learn very low level things first (e.g. starting with how the hardware works at the "electronics" level, then assembly, etc) and then learn higher level languages later. In this case students tend to get to things like lambdas and functional programming and get all "confused" (or, think it's a worthless pile of bloated puss), and these students are less likely to become good high level programmers.

Basically; if you want to become a good low level programmer I think you should start with low level.


Cheers,

Brendan

[alexfru]

Sorry, IMO, a good programmer cannot neglect the details of the implementation of their language and their hardware. Especially with a lot of data processing and real-time things, which is kind of important these days. One still needs to know the costs of various operations, be aware of bottlenecks, etc.

[alexfru]

You should start with event-driven languages such as C# or VB.Net. Also see http://smallbasic.com/.

Y? It would be nice to hear of your reasoning.

[Combuster]

I would at least claim Java for that role for the sake of not getting people unnecessarily stuck in Microsoft's web of illusions.


That said, programming languages are like real languages. You really know a language if you can actually think in that very language instead of trying to translate it. This obviously leads to cases where people get stuck in one language because they translate all other languages to their primary language before reasoning about it, as well as the side-effects of being overly attached to your initial language.

Bilinguality has to be taught early. Don't just start with one language, pick up a second, different one the moment you gathered the basics. This is probably one of the reasons why my university taught both assembly and java in the first half year.

[Antti]

Usually low level programming is like composing the binary image. You just have different tools that help doing it (e.g. assembler). I made a tool written in C for demonstrating this:

Code: Select all

#include <stdio.h>

static const char *outputComFile = "OUTPUT.COM";
static const char *outputTextStr =
        "This is a sample text to be printed. Replace this with your own.";

int main(int argc, char *argv[])
{
    FILE *pFile;
    const char *ptr;

    unsigned char Mov_Dl_XXh[2] = { 0xB2, 0x3F };   /* mov dl, '?' */
    unsigned char Mov_Ah_02h[2] = { 0xB4, 0x02 };   /* mov ah, 02h */
    unsigned char Int_21h[2]    = { 0xCD, 0x21 };   /* int 21h */
    unsigned char Int_20h[2]    = { 0xCD, 0x20 };   /* int 20h */
    unsigned char Short_Jmp[2]  = { 0xEB, 0xFE };   /* jmp $ */

    pFile = fopen(outputComFile, "wb");
    if (pFile == NULL) {
        perror("Error");
        return 1;
    }

    for (ptr = outputTextStr; *ptr != '\0'; ptr++) {
        Mov_Dl_XXh[1] = (unsigned char)(*ptr);

        fwrite((const void *)Mov_Dl_XXh, 1, sizeof(Mov_Dl_XXh), pFile);
        fwrite((const void *)Mov_Ah_02h, 1, sizeof(Mov_Ah_02h), pFile);
        fwrite((const void *)Int_21h,    1, sizeof(Int_21h), pFile);
    }

    /* TODO: print carriage return and new line */

    fwrite((const void *)Int_20h,   1, sizeof(Int_20h),   pFile);
    fwrite((const void *)Short_Jmp, 1, sizeof(Short_Jmp), pFile);

    fclose(pFile);
    return 0;
}

Compile with your favorite C compiler. If you run the program, you will get a valid DOS program (OUTPUT.COM) that prints the message you want. Both programs are bad but that is not the point. Actually, it is the point. Now we understand better that other tools may be better at doing this job (composing the binary image).

The point is that you understand what is happening.

[Muazzam]

You should start with event-driven languages such as C# or VB.Net. Also see http://smallbasic.com/.

Y? It would be nice to hear of your reasoning.

(Can you confirm that 'Y' is for 'Why' or some thing else?)
Nothing is special, but at least, for me, event-driven programming languages were much easier for me.

[Kevin]

I don't think the language actually matters all that much at this point. You need programming experience, and you can get it more or less with any language. Once you feel you can do something useful in one language without too much hassle, it might be time to look into the next one. As long as you stay within the same paradigm (i.e. imperative languages), you'll learn the basics of the new language quickly, but will still learn some different ways of approaching some things. Do that with maybe three or four languages and then try to really master one of them in great detail.

Dabbling in other paradigms potentially makes you an even better programmer because you'll know very different perspectives to the same problem, but that's more of an indirect affect, so it might feel like an unnecessary detour.

[iansjack]

Learn as many languages as you can. Each one will give you a different perspective. As for assembler, learn it when you need it; you'll know when that is.

As you're posting on a site devoted to OS development you probably want to learn assembler, and C, right now. Forget event-driven, and even object-oriented (IMO) for this purpose, at least to start with.

[Rusky]

I'd say it doesn't much matter which direction you come from (high->low or low->high), or how quickly you start using multiple languages. What matters is that you have clear goals for what you want to make, and that you're committed to learning how your tools work.

Learning a higher level language first is good for teaching you the conceptual parts, like algorithms and data structures. Learning a lower-level language first is good for teaching you the mechanical parts, like memory layout and how your program is executed. All of these are important, but some are more important than others for different applications.

Mastering a single language before branching out will give you a good basis for comparison, although you may have to fight at first to keep yourself from falling back on what you already know. Learning several languages at once before mastering one of them will give you an appreciation for what you're missing, but it will take longer to really understand what's going on.

In my experience, people who advocate for "low level first/only!" or "high level first/only!" tend to be pretty misguided about the importance of tools other than their favorites, and they tend to forget what it's like to be a beginner and not know simple things like how to get started. Pick a project, learn what needs to be done, what tools you have, and how they work. If it seems daunting, start with a smaller part of your project, potentially in a simpler environment, or look at how existing ones work.

[trident]

...

[alexfru]

The Development of the C Language by Dennis M. Ritchie

[Solar]

I know these sound very obvious, but what's your opinion?

I think that, to really understand things, you have to cover the basics. But you also need some "instant gratification" to stay interested.

I thought about this quite a bit, because I frequently find myself in the position of tutor and instructor -- at work, where I'm instructing student interns, and now also at home, where my own kids get into an age where they start getting interested in programming themselves. I'm currently trying to find a good balance for that in a new blog I'm writing on the very subject. (It's still pretty empty so I won't bother you with a link at this point. Perhaps later.)

But it's about more than just which languages you're picking up in which sequence. Some things require a bit of history, or they will forever remain "mystic" and "that's just like it is". Intel x86 / x64 assembly, in particular, cannot be taught properly without quite some historical background.

All that "meta" being said... I think picking up C early on (right after whatever drew your attention to programming in the first place -- the "instant gratification" part) is absolutely essential. It shows you elementary things like pointers, memory allocation / deallocation, pass-by-value vs. pass-by-reference, and allows easy showcasing of other basics like stack vs. heap, signal handling, and character encoding. All that in a "stark naked" environment without (m)any distractions. It's also one of the most influential languages, with many of its constructs found in later language generations like C++, Java, or C#.

As for Assembly... I know I will get flak for this, but I don't think Joe Average Coder will need actual experience with Asm, unless his specific project calls for it (i.e. you're doing hardcore embedded stuff, compiler optimization, or OSDev). You need to be aware that it exists, and some anecdotes from "that age" can me instructional or entertaining, helping with general understanding. But the only Asm I've ever actually coded in 15 years of system development has been the stuff I've done for my OS project here on OSDev. I never needed that knowledge, and the occasions where I could apply that knowledge were very, very few -- I can remember one time when looking at Asm in the debugger actually helped somewhat.

So, yes, you should learn C, and do so early, usually as your second language. From there on, whatever takes your fancy. Just never stop learning.