Live data from Hacker News

C, The Beautiful Language

tenaciousc.com

61–70 of 85 posts

Re: C, The Beautiful Language

#61
post #57
post #2

C is more a description of a Harvard machine than a von Neumann machine. In fact, a useful new language feature would be dynamic generation of machine code.

Lisp provides exactly that: functions are lists (primary data structure of the language) of expressions (in VM's instructions) and you have direct access to VM's memory cells (conses, [1]). You can generate and change functions at runtime. For example, inject tracing code. Actually, at least in some implementations, all functions are created dynamically, except for a few core functions (implemented with C, d'oh). And…

Only in early Lisps (and the broken newLisp) are functions lists.

The syntax for functions is lists. But at runtime functions are their own type.

Re: C, The Beautiful Language

#63
post #22

All it means is that he understands C better than other languages. Even Java (yes, Java) has these rhythms that he speaks of. You look at code and you feel the logic, even the necessity of it. That's just the feeling of being in tune with code and with the person who created it, thanks to a shared understanding of the language. Master any language and you'll get the same feeling when you read well-written code. Actua…

Occam's razor. Keeps things simple and beautiful.

Re: C, The Beautiful Language

#64
post #58
post #22

All it means is that he understands C better than other languages. Even Java (yes, Java) has these rhythms that he speaks of. You look at code and you feel the logic, even the necessity of it. That's just the feeling of being in tune with code and with the person who created it, thanks to a shared understanding of the language. Master any language and you'll get the same feeling when you read well-written code. Actua…

I can sympathize with the author about C, but with Java... Every time I need to figure out a Java program, I end up being in almost physical pain. Huge trees of empty nested directories and files with nothing but method definitions that do nothing but return a property... or, better yet, tons of empty functions called pure virtual. It's hard to feel the logic and necessity of code when you can't stop being flabbergas…

But those aren't really problems with Java - they are problems with the idioms common amongst Java developers.

Re: C, The Beautiful Language

#65
post #61
post #57

Earlier quoted context omitted.

Lisp provides exactly that: functions are lists (primary data structure of the language) of expressions (in VM's instructions) and you have direct access to VM's memory cells (conses, [1]). You can generate and change functions at runtime. For example, inject tracing code. Actually, at least in some implementations, all functions are created dynamically, except for a few core functions (implemented with C, d'oh). And…

Only in early Lisps (and the broken newLisp) are functions lists. The syntax for functions is lists. But at runtime functions are their own type.

Pardon? [1]

Are you sure? [2]

How about no? [3]

Perhaps you prefer Vim over Emacs? [4]

---

[1] http://en.wikipedia.org/wiki/Picolisp my favorite

[2] http://en.wikipedia.org/wiki/Scheme_(programming_language) probably the best known

[3] http://en.wikipedia.org/wiki/Arc_(programming_language) this bloody website runs on it

[4] http://en.wikipedia.org/wiki/Emacs_Lisp the good, the bad and the ugly, all in one package

Re: C, The Beautiful Language

#66
post #42
post #22

All it means is that he understands C better than other languages. Even Java (yes, Java) has these rhythms that he speaks of. You look at code and you feel the logic, even the necessity of it. That's just the feeling of being in tune with code and with the person who created it, thanks to a shared understanding of the language. Master any language and you'll get the same feeling when you read well-written code. Actua…

Exactly, and C is the worst offender for boilerplate code. There isn't even a list abstraction! It's surprising that there's an array abstraction and that people aren't just forced to use pointer arithmetic.

There are list abstractions in libraries.

See the Linux kernel's list.h for a very nice and generic linked-list implementation.

Re: C, The Beautiful Language

#67
post #34
post #4

> In other languages, the abstractions and sweet (if helpful) syntactic sugar that attend the code conceal the heartbeat. IMO, that means they're failed abstractions and syntactic sugar. Proper ones should result in better understanding due to simplification - you can learn it in levels, easily encapsulating the knowledge at each level so you know you can "trust" what it's doing without having to remember all of it.

Yeah, code without abstraction is good and works on a small scale. But on a bigger scale, it leads to not being able to see the forest for the trees. I want to be able to see the big picture while being able to dig up the smaller pictures if I have to.

> it leads to not being able to see the forest for the trees

And it's entirely possible the forest will end up being a beautiful one.

Re: C, The Beautiful Language

#68
post #49

Earlier quoted context omitted.

+1 C is ugly. - Why do I need to typedef a struct to make it look like any other type? - Why do function pointers look so bad? - Error handling in C? Those goto exception; if(0){exception:} sure look fantastic. - int* var1, var2; var2 is an int, not an int* ... The language lets you stick the * right next to the type as though it modifies the type. Which it does in casts. (how do I escape asterisks on here?) - A syst…

- You don't. C99 treats structs like classes. - Typedef them. - If done right, it can be quite unobtrusive. - That's not how it should be written. This is a 100 times clearer: int *var1, var2; - Not really. And don't use int, int32_t is where it's at.

"- That's not how it should be written. This is a 100 times clearer:

int var1, var2;"

Somewhat aside from the actual article, but this might actually be the least clear way to write a definition, since the pointer marker appears to belong to var1, but not the overall definition of int. Here is how I would automatically read the definitions:

"int var1, var2;"

Of type int (variable), create var1, var2.

"int var1, var2;"

Of type int and type * (pointer), create var1, var2.

"int var1, var2;"

Of type int, create pointer var1, pointer var2.

"int *var1, var2;"

Of type int, create pointer var1, default (variable) var2.

Not sure how this works for and against C, since the language definition is really old at this point and by the standards of its time C is really clear. But languages have moved on and a standard has emerged over the intervening time that is a bit more logical.

Also, I think this article is a real piece of fluff :).

Re: C, The Beautiful Language

#69
post #9

This is a nicely written tribute, but there are two generalisations that I feel are worth pointing out. Many parts of Linux kernel are really, really nice C code. Sadly, in my experience most C code is not especially nice. I don't know how this extends to the football metaphor, but certainly I wish most of the C code I have encountered (not to mention written) in my career to date was one tenth as neat. On balance, I…

What are some specific examples of beautiful C code in your view? Asking for a friend.

Lua, SQLite, the OpenBSD/FreeBSD userland utilities.

Re: C, The Beautiful Language

#70
post #65
post #61

Earlier quoted context omitted.

Only in early Lisps (and the broken newLisp) are functions lists. The syntax for functions is lists. But at runtime functions are their own type.

Pardon? [1] Are you sure? [2] How about no? [3] Perhaps you prefer Vim over Emacs? [4] --- [1] http://en.wikipedia.org/wiki/Picolisp my favorite [2] http://en.wikipedia.org/wiki/Scheme_(programming_language) probably the best known [3] http://en.wikipedia.org/wiki/Arc_(programming_language) this bloody website runs on it [4] http://en.wikipedia.org/wiki/Emacs_Lisp the good, the bad and the ugly, all in one package

[deleted]
Post reply on HN