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

41–50 of 116 posts

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

#41

Post by leon_ »

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:…

Yup, macros are a bad idea in that regard. Had to work on a codebase where the prior programmer had fancy defs like _dict k1, v1, k2, v2, k3, v3 dict_

I wasn't too happy about that :/

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

#42

Post by leon_ »

cabalamat wrote: post #36
chittis wrote: post #5

Earlier quoted context omitted.

Given that Java doesn't have typedefs how would you reduce the verbosity of : ConcurrentHashMap foo = new ConcurrentHashMap ();

I'd write the code in Python (or indeed any sensible modern language). foo = {}

and then you get an int instead of a string and your python app explodes. let's not start on "sensible modern" languages.

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

#43

Post by leon_ »

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…

Yup, many "hip" folks believe they don't do OO just because they are using a language without classes, etc.

But what's the difference between foo->doshit() and doshit(&foo)? Those people still don't get stuff like data orientation, etc. but are shouting out loud how evil OO is and how they killed that dragon ;)

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

#44

Post by blub »

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…

> C++ is object-oriented and C isn't

Neither is object-oriented, except C++ allows you to easily work with objects unlike C, where you have to reinvent them.

It is easy for me not to pick C if I need more abstraction than a struct with pointers to functions can provide.

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

#45

Post by bpodgursky »

mhansen wrote: post #17
chittis wrote: post #5

Earlier quoted context omitted.

Given that Java doesn't have typedefs how would you reduce the verbosity of : ConcurrentHashMap foo = new ConcurrentHashMap ();

Do something like the Google Collections Library does: HashMap foo = Maps.newHashMap(); The return type of newHashMap is determined by the type of foo, so you don't need to repeat the generic types in angle brackets. public static HashMap newHashMap() { return new HashMap (); } http://google-collections.googlecode.com/svn/trunk/javadoc/i... (I'm not a fan of Java myself, but there are some tricky ways to cut down on…

The Collections class built into Java has a lot of timesavers like this too--singleton, singleonList, singletonMap, and Arrays has stuff like Arrays.asList( ... ).

Also it's rarely important that you know the actual type of Map you're using (the interface is what's important), so you can just call

Map foo = Maps.newHashMap();

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

#46

Post by Confusion »

Groxx wrote: post #3

> 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. Supposedly clarity is maximized. But how can this be if we do the opposite when we speak? Do you say “taxi cab”, or “taximeter cabriolet”? Redundant utterances are tiresome and worse still, obscure the idea being expressed. I see this argument a lot, and they strike me…

I also tripped over this argument in the first chapter, but it should be emphasized it's an exception of a bad argument in the book, not the rule. The author would have been wise to avoid this red herring.

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

#47

Post by leon_ »

tptacek wrote: post #15

You can easily beat "static const volatile signed long long int bar" with a function pointer (and without the unrealistic redundant indirection of "int const ... const foo"). Start with static const volatile signed long long int (*foo)(static const volatile signed long long int bar). :)

calls by function pointers can't be resolved at compile time and thus won't be optimized. depending on the program you're working on you might want to consider this.

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

#48

Post by blub »

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 code size. It's almost impossible for C++ to be more verbose than C - consider that you can write C-like code directly in C++.

Second of all, for a developer that has good knowledge of both C and C++, writing quality C is harder. C is very prone to programmer errors, much more so than C++ where you can choose to use libraries/language features that completely eliminate some of these errors. e.g: scope-based destruction, the STL data structures, string classes, etc.

Third of all, when discussing C++ many try to make C++ look as a frightening monster ("full-blown C++"?) where you have template meta-programming interacting with automatic conversions and operator overloading and all the other features in the worst possible way. This is not much different to claiming C is bad because you can use macros and void* for everything. The languages should be compared by real-world use patterns, not dreamed up criteria.

[1] Estimating Software Costs (Jones 1998) and Software Cost Estimation with Cocomo II (Boehm 2000)

"[...]that object-oriented programming is no panacea[...]"

While it is true that some have argued for OOP as panacea, this is mostly a strawman. OOP is one possible solution that works most of the time.

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

#49

Post by Stormbringer »

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…

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

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

#50

Post by nkurz »

angusgr wrote: post #37
nkurz wrote: post #21

Earlier quoted context omitted.

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…

Yeah, you're right about Fortran, my mistake. I actually skipped that chapter because I've never written Fortran. I did read the other chapters, paying particular attention to languages I've used at least a bit (Haskell, Java, C++ from that list.) Like I said also, I agree with a lot of the premises. I just think the essay is overly positioned as "C is the best hammer" when a better essay might be "Use the right tool…

That's certainly a fair question. I think he probably wrote it mostly for himself: a CS graduate who fell hard for some modern languages and then later realized that neither OO or functional has all the answers. Like someone raised in a strict religious household who's always had his doubts about the faith, he finally feels confident in expressing his true feelings, and maybe gets a little carried away. I like it though.
Post reply on HN