I'm assuming the island has power and modern computers.
C Craft: C is the desert island language.
71–80 of 116 posts
Re: C Craft: C is the desert island language.
#72Earlier quoted context omitted.
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 ;)
You're probably getting voted down for the tone, but I agree with your point. Case in point - GObject, from glib (foundation libs of Gnome, for those not familiar with it). I understand the historical reasons for that specific case, but is the macro magic really an improvement over using (a subset of) C++ ? I'm quite sure it's not.
GObject and glib in general aren't an improvement over anything, and both are largely shunned by the c-using community.
Re: C Craft: C is the desert island language.
#73You 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.
Not strictly true, it is quite possible to statically resolve many uses of function pointers.
Re: C Craft: C is the desert island language.
#74> 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 don't know for Java (luckily haven't been using it much) but for C I dislike typedefs. I need to know what data I'm working with. A typedef hides that information from me behind a shiny but uninformative name.
I mostly agree, except for function pointers. The C idiom of typedefing a function-pointer type results in code that looks more readable to me (e.g. prototypes of functions that take a function-pointer parameter have "typename varname" syntax) compared to the somewhat odd syntax you get if you scatter around function-pointer types inline.
Re: C Craft: C is the desert island language.
#75Desert island language, as in "like trying to build a hut, and manage your hunting and gathering with the Swiss Army knife that happened to be in your pocket"? I agree that for Torvalds work it is the only sane choice. But I'm not writing kernels.
I didn't get the reference either. It fits my ego better to think of it as the Desert Eagle[1] language, I think. Or at least my subconscious seems to think so, I just misread the title of this story as such.
Re: C Craft: C is the desert island language.
#76Earlier quoted context omitted.
"just to point out that my OCD tic to wrap to 80 characters has absolutely zero place in Xcode. Or Java." Dude. Are you still using CGA? Unless for your IDE you're running emacs on your wristwatch or phone there's no place for that shit in the real world, and you have no excuse. Ditch that green cathode ray tube, here, have 50c and go buy yourself a real monitor. :D
It is fascinating to see people having 24+" monitors -- and seeing ca 30 lines of code on their screen, because of the real estate eaten by their IDEs. To add maiming to injury, these guys write in modern Cobol (a.k.a Java). Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe. (I love my iPad, but It'll be iPad 3 before it is half as nice for browsing code [edit:…
"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?
Re: C Craft: C is the desert island language.
#77> 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…
Given that Java doesn't have typedefs how would you reduce the verbosity of : ConcurrentHashMap foo = new ConcurrentHashMap ();
Doesn't Java have any kind of type inference for variables yet?
C# allows you to say
var foo = new Dictionary();
Re: C Craft: C is the desert island language.
#78Earlier 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.
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.
Re: C Craft: C is the desert island language.
#79Earlier 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.
Personally, I find "thisVariableIsTheLoopIndex" to be a terrible loop index variable name. But "i" isn't great either. "index" seems to be closer to the sweet spot to me. Or "fooIndex" and "barIndex" if loops over foo and bar collections are both in play. That beats the hell out or trying to parse "i" and j" as indexes over two collections.
The simple rule is that the larger the scope of the variable the longer the name - i.e. the more widely references to the var occur, the further they are from the definition, the more descriptive the name has to be.
Re: C Craft: C is the desert island language.
#80Earlier quoted context omitted.
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.
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.
Close. Which is what I don't like about the samples that I have seen in his Go language. Code like "Fmt.PrintF" seems a step backwards to me.