Hacker News Reader

Comment by nabla9 | Hacker News Reader

Just one counterexample: Texas instrument C28x core is 16-bit addressable. Each byte is 16 bits.

>The TMS320C28x byte is 16 Bits. By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits.

http://processors.wiki.ti.com/index.php/Byte_Accesses_with_t...

C is the closest thing to universally portable assembler.

View on HN

I fail to see how C is more portable than any other memory safe systems programming language, other than having the fortune that for 30 years OS and hardware vendors decided to only support C compilers.

But that's the most important thing, isn't it? Being able to compile and run your code? I mean, the English language sure isn't popular for its intrinsic merits either, but here we are.

Sure, but in a way C is the JavaScript of systems programming languages, in a deep need of a "The Good Parts" book as well.

I'm sorry, but is this comment a joke? Have you ever read "The C Programming Language", and seen how simple C is? These arguments that the two OPs are having are important, but only when faced with obscure architectures that nearly nothing but C will run on.

Conversely, JavaScript's failures are not because of the wide variety of architectures that it supports (a tiny fraction of C's), but instead on the monolithic and bad design of the language. If you read "The C Programming Language", you'll realize that in the ~240 pages of text, you know basically every feature of the language. It's small, and it's elegant, and it's portable. JavaScript is none of those.

It is not a joke, rather the conclusion of someone that was already dismayed with C back in the mid-90's.

> If you read "The C Programming Language", you'll realize that in the ~240 pages of text, you know basically every feature of the language.

Except for those little compiler specific little issues, it seems:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.regehr.org/archives/213

http://blog.regehr.org/archives/226

http://blog.regehr.org/archives/232

> It's small, and it's elegant, and it's portable

Have you had the pleasure to port C code across multiple C compilers and OS in the mid-90's?

Agreed. (yes, did a lot of C in the mid/early 90s that ran on sundry unices, DOS, OS/2, Windows & VAX). Ouch.

"The C Programming Language" isn't that great of a book, either. I had FAR better luck making sense of C (after having been in school for almost 4 years, and working part time on another language for almost 2 years) with the book "C, An Advanced Introduction" (1st version, not "ANSI Edition"), by Narain Gehani. For somebody transitioning from real high level languages, the array/pointer/string swamp was a real source of anti-productivity fun and games until explained by somebody other than its creators.

When you're done with The C Programming Language, read Expert C Programming, C Traps and Pitfalls, and The C Puzzle Book. Then tell me how simple C is.

Have you read "Expert C Programming: Deep C Secrets"? That book will show you that a simple language does not mean that programming in it is simple.

On a related note, I believe "The C Programming Language" is not a good book for the realities of 2016.

There's two recommendations here for "Expert C Programming".

I read it cover to cover fairly recently; I don't think there was really anything I disagreed with, but there also wasn't anything I didn't already know and wasn't already practicing. While I've been programming C a while now, that surprised me. I've decided that the book isn't bad but is probably more "help get you from beginner to intermediate" than "help get you from intermediate to expert", much less something of use to an expert (sadly, in my position).

An alternative interpretation would have it that there is just not enough to say about C that an expert-level book is likely to say things a C expert would not already know. That would argue against your point about the complexity of C. As I say, though, this has not been my conclusion.

[1] Except that Eliza was named after the character from Pygmalion - I'd somehow never put that together!

C is not simple.

There are tons of such books.

Compilers. Compilers for everything.

You can hype your favorite systems language all you want, but if there is no compiler, it wont compile.

>OS and hardware vendors decided to only support C compilers.

If you want your favorite language X to work everywhere C does. Just make X-to-C compiler.

X-to-C compiler isn't as nice as it could be, because you're writing code for some weird chip and need to twiddle some bits for IO using a macro defined in a header somewhere, and that doesn't play nicely with your pet X-to-C compiler.

Not an ideal situation, for sure, but a real one.

It's possible for translator understand headers and macros and generate bindings for them. Even for function macros. For example, GNAT has macro binding although it's not complete.

Btw. There is nothing "pet" in X to C translators. You pay good money for a good Ada to C compiler.

Or an RPG II to C translator/compiler :-)

A job I had in the early 90s, maintaining and extending such...

Of course, but that is an issue of implementation availability not language quality.

I remember the days when using C meant getting an account to the university (or work) UNIX system.

Every TI DSP I've worked with uses 16-bit bytes

c6x has 8-bit bytes.

Reply on news.ycombinator.com