Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Craft: C is the desert island language.

www-cs-students.stanford.edu

Post reply on HN
Print view View original

91–100 of 116 posts

Re: C Craft: C is the desert island language.

#91

Post by msg »

ElliotH wrote: post #69
nadam wrote: post #62

It says: "In my Eiffel days, I was encouraged to write "integer", not "int", "character", not "char", and so on. I believe Java encourages this practice too." 1. No Java uses char, int, and so on. 2. No, C is absolutely not concise even compared to Java. At least how I write Java code. Look at this Java method: String strangeConcat(String str1, String str2) { return str1.substring(0, str1.length() - 1) + str2.substri…

In Java int and char are primitive types. They don't provide methods so: int i = 4; i.toString(); //Exception - int isn't a class, so i isn't an object, so you can't call its methods. Integer j = 4; j.toString(); //Returns "4" as a string, because Integer is a class. Java would 'encourage' the latter practice at times because its useful to be able to call methods off of characters and integers and such, but there is…

But you wouldn't do this in Java (need a random string for an integer).

Instead you might see:

  logger.fatal( String.format("Program crashed on index %d: %s", i, message) );
I think C has a similar construct, not quite as verbose, that would save 7 characters out of the line...

Re: C Craft: C is the desert island language.

#92

Post by gnosis »

berntb wrote: post #84
gnosis wrote: post #76

Earlier quoted context omitted.

"Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe." You can't print code longer than 150 characters wide? Since when?

Sigh, are you trolling or new? OK, I'll answer. The point of printing and browsing code is that it is easier and nicer than to read it on a screen (you'll have a portable with you at the cafe anyway to search, annotate, etc.) If you get lots of broken lines, it isn't readable. Point was, you lose a capability with long lines -- a nice way to go over code. This is important for many of us. Edit: Point jedsmith, write…

Broken lines?

We no longer live in the days of typewriters or daisychain printers with fixed column widths.

We now have these wonderful things called laser printers which can print using fonts.

Fonts are resizeable. Even to the point that 150+ columns could be fit on one unbroken line.

And even lines that long can be quite readable if you print in landscape.

Re: C Craft: C is the desert island language.

#93

Post by gnosis »

beagle3 wrote: post #85
gnosis wrote: post #78

Earlier quoted context omitted.

So I suppose this leads Rob Pike to use one-character names for all the variables and functions in his programs? Such programs must be a joy to read.

His code actually _is_ a joy to read and use. Some of it requires more than a passing scan. But that's true of any code worth reading - if you don't need to scan it twice, it's most probably useless and bureaucratic, and could be done away with if a better design is used.

I very much doubt his code is both a joy to read and made up exclusively of one-character variable and function names.

It's one or the other.

Re: C Craft: C is the desert island language.

#94

Post by antirez »

roel_v wrote: post #64
Stormbringer wrote: post #49

Earlier quoted context omitted.

LOC means nothing, and if you want to generate subtle programmer errors, then templates is definitely the way to go.

"if you want to generate subtle programmer errors, then templates is definitely the way to go." Please indicate how so. I cannot think of ways that make templates more prone to programmer error than, let's say, str_xxx functions for which the programmer needs to allocate extra room for a \0 (or not, depending on which function you use...). Those types of C idiosyncrasies cause much more mistakes than any inadvertent…

agreed on str...(), but this is not semantic, is broken lib that is hard to update for backward compatibility issues, so in some way it is not a matter of the language.

Re: C Craft: C is the desert island language.

#95

Post by rdtsc »

blub wrote: post #48
angusgr wrote: post #7

I'm deeply conflicted about this article because I agree with many of its premises. For instance: that C is superior to full-blown C++, that object-oriented programming is no panacea, that simplicity is good. I have serious concerns, however, especially with the first page and the first few chapters. - They support the biases of the myopic programmer who believes that now he or she knows C, they know everything one m…

"that C is superior to full-blown C++[...]" I disagree that C is superior to C++ for most projects. First of all, C++ offers higher-level semantics which leads to an increase in productivity. According to [1], the ratio of C++ to C LOC is 1 to 1-2.5, but I'd be interested to read other studies or articles. My experience and [1] also contradicts your statement that rewriting code with STL/Boost will lead to increased…

> First of all, C++ offers higher-level semantics which leads to an increase in productivity.

Strongly disagree. The full C++ spec, templates and all is pretty complicated. I am sure you can squeeze out less LOC out of it, but then why not just use APL.

> Second of all, for a developer that has good knowledge of both C and C++.

I think there are very few people who know C++ well. And by know I mean they know all of its aspects equally well. Now there are plenty of people who _think_ they know C++, but don't or just know just some parts of it well. I can easier trust someone who says they 'know C', because it is a fairly short spec, not so with C++.

If you imagine a team of developers. If all of them are true C++, experts, then everything is fine. But I have never seen that. So one developer likes templates, another likes some other part of C++, and they start using that and eventually they all write C++ but they can't all necessarily read and understand each others' code. And here is where another 50 pages of C++ style guide comes in to help. But if a language needs 50 pages of custrom style guides to be useful, there is probably something wrong with that language.

> It's almost impossible for C++ to be more verbose than C - consider that you can write C-like code directly in C++.

I think it is a false dichotomy. I know the original article compared both head to head, your point picked it up, but in general it should'be be between C and C++ only. It should be C++ vs C+Python or C vs Go and so on. In other words comparing lines of code by presenting a somewhat artificial constraint is not that representative of the real world.

Re: C Craft: C is the desert island language.

#96

Post by rdtsc »

blub wrote: post #52
Stormbringer wrote: post #49

Earlier quoted context omitted.

LOC means nothing, and if you want to generate subtle programmer errors, then templates is definitely the way to go.

LOC means a lot when it comes to: * reading and trying to understand source code * maintaining source code * typing and programming-related injuries The dynamic-typed camp argues that even declaring a variable is a pain. Conciseness is one of the favourite features of JS/Ruby/Python developers and prolixity is universaly loathed in Java. Please expand on your assertion that subtle programming errors are caused by tem…

> reading and trying to understand source code ... maintaining source code

I think it helps but in general those things are not related very well. For examples guess what this line of code does (this is APL) ?

    X[⍋X+.≠' ';]
According to APL's Wikipedia entry it "sorts a word list stored in matrix X according to word length". It is just 1 line of code so it wins there. But now imagine reading code like that and maintaining it.

Re: C Craft: C is the desert island language.

#98

Post by beagle3 »

gnosis wrote: post #93
beagle3 wrote: post #85

Earlier quoted context omitted.

His code actually _is_ a joy to read and use. Some of it requires more than a passing scan. But that's true of any code worth reading - if you don't need to scan it twice, it's most probably useless and bureaucratic, and could be done away with if a better design is used.

I very much doubt his code is both a joy to read and made up exclusively of one-character variable and function names. It's one or the other.

His local indices are usually one letter (i, j, k), his local counters are usually one letter (m, n). His accumulators are sometimes one letter - much like math expressions.

He gives a more descriptive names to variables that live for more than a 10 lines or code or so.

And that's way more of a joy than reading a Java sourceful of "indexThatGoesSourceThe2ndArray"

Re: C Craft: C is the desert island language.

#99

Post by Groxx »

jedsmith wrote: post #26
Groxx wrote: post #16

Earlier quoted context omitted.

disclaimer: I have not tried these. Totally pulling these from a quick googled-refresher of macros. #define withZip someoneCouldntComeUpWithAShorterNameWithZipcode #define dictWith dictionaryWithObjectsAndKeys or #define dictWith NSDictionary dictionaryWithObjectsAndKeys so you can [dictWith: key, value, key, value] :) I forget, does XCode intelligently handle macros? Or does using a macro destroy its helpful feature…

Doing that is probably fine if you are working alone and nobody will ever read your code. Reading Objective-C is already enough of a challenge without having to context switch to a header just to mentally resolve symbols. Instead of using a macro for the selector: NSDictionary *frob = [NSDictionary macroHere:v1, k1, v0, k0, nil]; It would probably be far more efficient to macro the entire call using C99's variadics:…

The reason I went for the selector is because it makes the macro into essentially a function-typedef. I don't know any languages which allow typedefs to specify things like `Class.short = Class.super_long_name_here`, even though it's essentially the same concept, especially if looked at from a C standpoint. It's a minimally-intelligent text replacement.

IMO, something like `[NSDictionary with:key,val,key,val,nil]` is far less brain-taxing than `DICT(key,val,key,val)`. It fits without modifying the language or the syntax, it merely makes something long shorter, and the usage implies it does nothing "shiny" - you even keep the class name you're calling, making it clearer what you should be expecting, and it still allows access to all other parameters without modification or even thinking differently. DICT(...) is ambiguous about what kind of dictionary it's returning.

Re: C Craft: C is the desert island language.

#100

Post by jbooth »

beagle3 wrote: post #98
gnosis wrote: post #93

Earlier quoted context omitted.

I very much doubt his code is both a joy to read and made up exclusively of one-character variable and function names. It's one or the other.

His local indices are usually one letter (i, j, k), his local counters are usually one letter (m, n). His accumulators are sometimes one letter - much like math expressions. He gives a more descriptive names to variables that live for more than a 10 lines or code or so. And that's way more of a joy than reading a Java sourceful of "indexThatGoesSourceThe2ndArray"

I really don't get what you're driving at here.

Are you claiming there's a java language requirement that array indices are named with more than one letter? That's not what the screen in front of me says.

"He gives a more descriptive names to variables that live for more than a 10 lines or code or so."

Ok, now we're talking. I like go and Rob Pike's reputation speaks for itself but don't put words in the guy's mouth, go has strong typing in a way that's much more similar to Java than whatever your pet language is, the major difference is syntactical sugar that infers types more often, and a looser contract for interface (both of which I agree with).

Post reply on HN