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

21–30 of 116 posts

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

#21

Post by nkurz »

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…

Judging by his blog (http://benlynn.blogspot.com/) it looks like he has considerable affection for many languages beyond C. And I think you may have misinterpreted his comparison with Fortran: rather than showing how handily C beats Fortran (fish in a barrel), he seems to be saying that even with some C99 improvements, there still are places where Fortran has the advantage (refreshingly heretical). It's definitely not a piece for beginners, but I think it may be a more balanced picture than you present.

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

#22

Post by tsuraan »

jedsmith wrote: post #12
onan_barbarian wrote: post #11

There are some reasonable things here, but: "Lumping together function pointers that operate on the same data structure is essentially object-oriented programming" is unbelievably contentious regardless of which of the various definitions of OOP you follow.

I would strongly disagree that it's contentious. (Think that over...disagreement about contention. I raised my eyebrow too.) Some of the more exotic features of what people call "OOP", like polymorphism, take a bit more care and feeding to pull off in straight C. They are most certainly possible, that being said. Unwind "OOP" to "working with objects that contain data and methods together," and structs with function…

If you try to equate C and C++ by saying C++ can compile to C (not sure if that's what you're saying but it sort of looks like it), you might want to change your argument a bit. Haskell can also compile to C, but that doesn't make C strongly-typed, functional, or garbage collected.

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

#23

Post by Fargren »

Groxx wrote: post #16
jedsmith wrote: post #13

Earlier quoted context omitted.

I see your Java, and raise you Objective-C: NSString *thing = [NSString stringWithFormat:@"Result: %@", [foo someoneCouldntComeUpWithAShorterNameWithZipcode:08205 name:@"larry" parcels:5]]; NSDictionary *request = [NSDictionary dictionaryWithObjectsAndKeys:@"iphoneapp/0.1", @"User-Agent", @"news.ycombinator.com", @"Host", nil]; This isn't to kick off pet language wars, by the way, just to point out that my OCD tic to…

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…

I haven't worked a lot with XCode, but I remember using macros without problem.

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

#24

Post by onan_barbarian »

jedsmith wrote: post #12
onan_barbarian wrote: post #11

There are some reasonable things here, but: "Lumping together function pointers that operate on the same data structure is essentially object-oriented programming" is unbelievably contentious regardless of which of the various definitions of OOP you follow.

I would strongly disagree that it's contentious. (Think that over...disagreement about contention. I raised my eyebrow too.) Some of the more exotic features of what people call "OOP", like polymorphism, take a bit more care and feeding to pull off in straight C. They are most certainly possible, that being said. Unwind "OOP" to "working with objects that contain data and methods together," and structs with function…

At a high enough level of 'care and feeding' it's possible to pull off these things in assembly, or Fortran, or whatever, rendering the term completely meaningless.

C++ 'basically compiles down to C' for some constructs more than others (exceptions, RTTI, multiple inheritance goop) but if the C it compiles to is dark, arcane, unreadable crap, then this is no more illuminating than the truism that C++ basically compiles down to assembly language.

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

#25

Post by [deleted] »

tsuraan wrote: post #22
jedsmith wrote: post #12

Earlier quoted context omitted.

I would strongly disagree that it's contentious. (Think that over...disagreement about contention. I raised my eyebrow too.) Some of the more exotic features of what people call "OOP", like polymorphism, take a bit more care and feeding to pull off in straight C. They are most certainly possible, that being said. Unwind "OOP" to "working with objects that contain data and methods together," and structs with function…

If you try to equate C and C++ by saying C++ can compile to C (not sure if that's what you're saying but it sort of looks like it), you might want to change your argument a bit. Haskell can also compile to C, but that doesn't make C strongly-typed, functional, or garbage collected.

[deleted]

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

#26

Post by jedsmith »

Groxx wrote: post #16
jedsmith wrote: post #13

Earlier quoted context omitted.

I see your Java, and raise you Objective-C: NSString *thing = [NSString stringWithFormat:@"Result: %@", [foo someoneCouldntComeUpWithAShorterNameWithZipcode:08205 name:@"larry" parcels:5]]; NSDictionary *request = [NSDictionary dictionaryWithObjectsAndKeys:@"iphoneapp/0.1", @"User-Agent", @"news.ycombinator.com", @"Host", nil]; This isn't to kick off pet language wars, by the way, just to point out that my OCD tic to…

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:

    NSDictionary *frob = DICT(v1, k1, v0, k0);
Still wouldn't walk that road, personally.

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

#27

Post by KaeseEs »

jbooth wrote: post #20
Groxx wrote: post #9

Earlier quoted context omitted.

There you're largely screwed, but Java is well-known for being extremely verbose, and of course there will be languages that don't have basic features others have had for decades. The closest you can get in Java is to wrap it in a private, internal class. Which also lets you rename some verbose or frequently-combined operations, say: foo.someoneCouldntComeUpWithAShorterName() -> wrapped.succinct() -- or -- foo.store(…

Yeah, and congrats, now you have to hire people who already know what a foo is. The great thing about ConcurrentHashMap isn't writing it, it's reading it. Even if you're not a Java programmer you know exactly what that is (and FWIW it's world-class on implementation). We could do with some syntactical sugar to make that constructor line a little simpler, but declaring the type and calling a specific constructor, not…

I am skeptical of the claim that verbosity for its own sake aids comprehension. To borrow an example from Rob Pike, reading

  buf[thisVariableIsTheLoopIndex] = foo(...);
is no more obvious than

  buf[i] = foo(...);
and indeed is more likely to slow the programmer down by killing his train of thought and mental flow.

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

#28

Post by jedsmith »

KaeseEs wrote: post #27
jbooth wrote: post #20

Earlier quoted context omitted.

Yeah, and congrats, now you have to hire people who already know what a foo is. The great thing about ConcurrentHashMap isn't writing it, it's reading it. Even if you're not a Java programmer you know exactly what that is (and FWIW it's world-class on implementation). We could do with some syntactical sugar to make that constructor line a little simpler, but declaring the type and calling a specific constructor, not…

I am skeptical of the claim that verbosity for its own sake aids comprehension. To borrow an example from Rob Pike, reading buf[thisVariableIsTheLoopIndex] = foo(...); is no more obvious than buf[i] = foo(...); and indeed is more likely to slow the programmer down by killing his train of thought and mental flow.

The problem with that example is how contrived and narrow it is. All it proves is that verbosity doesn't aid loop indices.

ConcurrentHashMap, on the other hand, says everything it needs to in the name. As does NSMutableArray, and so on. Apples and oranges, here.

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

#30

Post by mhansen »

jbooth wrote: post #20
Groxx wrote: post #9

Earlier quoted context omitted.

There you're largely screwed, but Java is well-known for being extremely verbose, and of course there will be languages that don't have basic features others have had for decades. The closest you can get in Java is to wrap it in a private, internal class. Which also lets you rename some verbose or frequently-combined operations, say: foo.someoneCouldntComeUpWithAShorterName() -> wrapped.succinct() -- or -- foo.store(…

Yeah, and congrats, now you have to hire people who already know what a foo is. The great thing about ConcurrentHashMap isn't writing it, it's reading it. Even if you're not a Java programmer you know exactly what that is (and FWIW it's world-class on implementation). We could do with some syntactical sugar to make that constructor line a little simpler, but declaring the type and calling a specific constructor, not…

I think the verbosity complaint here isn't about the length of the name, it's about having to repeat the type and generic arguments.
Post reply on HN