Live data from Hacker News

Two types of C programmers

utcc.utoronto.ca

71–80 of 225 posts

Re: Two types of C programmers

#71
Many people I know (myself included) started in the second category in the 1980s and 1990s (C = God's programming language) and then moved to the first category once attractive alternatives (e.g., Go) that met our use cases became widely used.

Re: Two types of C programmers

#72
post #54

Earlier quoted context omitted.

I've been using D for OS development and have found it very good for controlling low-level details. GDC is the GCC frontend for D, and has most/all of the same features for controlling this stuff as GCC. For example, you can use `@register("edx") ulong x;` to specify that a variable should be in a particular register, `@section("t1")` on functions to place them in certain sections, and the inline assembler is the sam…

Thanks for the information. Appears that it does support the section attribute from GCC too. I'll have to explore this a bit and see if I can use it, since it seems to have all or most the features I use. I did learn D some years ago when the standard library situation was not great, but might be worth looking at again.

Depending on how much language support you want, you may want to compile without the D runtime (in which case you only have access to the C standard library, and various features are disabled, such as classes/interfaces, garbage collection, exceptions, and most of the D standard library). You can disable the D runtime in GDC with -fno-druntime and in LDC with -betterC. With those flags, the basic hello world program looks like this:

    import core.stdc.stdio;
    extern (C) void main() {
        printf("Hello world\n");
    }

Re: Two types of C programmers

#73
I am definitely the former. I didn't like C too much in 1986 but there wasn't really anything else except writing in Assembler! Having programmed in Pascal, it wasn't too much of a leap to transition to C. The C compilers at the time were buggy. 37 years later, I still write C programs. I won't touch C++.

Re: Two types of C programmers

#74
post #42

Earlier quoted context omitted.

The free beer one, because everyone likes to get source tapes for free, regardless of the quality, free usually wins out.

This doesn't seem to hold in the general case. Windows and Macos are not free in any sense, but vastly outnumber linux on the desktop.

The desktop is not the general case.

By install count, Linux runs on far more platforms than anything else: smartphones, tablets, servers, virtual machines, embedded devices, supercomputers, and spacecraft.

Re: Two types of C programmers

#75
post #42

Earlier quoted context omitted.

The free beer one, because everyone likes to get source tapes for free, regardless of the quality, free usually wins out.

This doesn't seem to hold in the general case. Windows and Macos are not free in any sense, but vastly outnumber linux on the desktop.

Because Linux folks cannot get their act together in what means a full stack desktop experience.

Not even Android games get ported in any significant number to GNU/Linux.

The war of Linux Distributions is ten fold worse as the UNIX wars.

Re: Two types of C programmers

#76
post #2

The post is kind of confusing regarding which sort is the "first sort", because they are presented in one order in the provocative thesis, and in the other order in the following paragraphs. But: > My perception of the second sort of C programmer is that if they've moved to any more recent mainstream language, it's probably Rust. If in this context the "second sort" is the type who likes C on its own merits (rather t…

I've always thought of myself as the second type of C programmer... I only used C if no other option was available (yeah, it was indeed fear!). After I started programming in Zig, I realized I really appreciated all of C's simplicity and (lack of) features, but now in "Zig fearless mode", it makes me feel like I always belonged to the first group.

Re: Two types of C programmers

#77
post #56

Earlier quoted context omitted.

The register support you describe is an extension, not really part of C. Gcc has lots and lots of C extensions, but they don't make the language simple. D's inline assembler does register management for you, i.e. it tracks register usage through the instructions, so you don't have to say which registers are read or written to. D does not support the "section" extension. I understand that certain gcc C extensions are…

Thanks. My root comment mentioned that it was not really the features of C that I depended on, but the GCC specific features. I'm interested in using D now as sibling comment mentions that I can use some of these features in gcd, but I'm not yet sure how much benefit I'd get over using C by using a subset of the D features which are compatible with the constraints of my VM.

One big feature is D has modules. There's no reason C can't have modules, but they don't. You don't need to code .h files anymore.

Re: Two types of C programmers

#78
post #42

Earlier quoted context omitted.

The free beer one, because everyone likes to get source tapes for free, regardless of the quality, free usually wins out.

This doesn't seem to hold in the general case. Windows and Macos are not free in any sense, but vastly outnumber linux on the desktop.

They may not technically be free, but they typically come bundled with the computer you buy. Linux has yet to be shipping with free comparable computers, so the cost of Windows/MacOS is invisible to the end consumer.

Re: Two types of C programmers

#79
> I no longer want to have to think about memory management and related issues.

In some cases efficient memory management _is_ the problem to be solved. I'm not just talking about esoteric or embedded systems here. If you're developing for modern GPU's with a modern API, like Vulkan, you must manage GPU memory yourself. With direct memory access you can do many "unsafe" things, like memory aliasing, to improve performance. "Safe" languages, like Rust, will not help you here.

Re: Two types of C programmers

#80
What about those who are stuck with it because of the huge legacy code base? They wouldn't choose it deliberately for anything new, but there isn't much they can easily do about it in the above case.

People who chose C as the best option at the time might not be even around the project anymore.

Post reply on HN