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

101–110 of 116 posts

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

#101

Post by roel_v »

blub wrote: post #83
roel_v wrote: post #66

Earlier quoted context omitted.

"Neither is object-oriented" And thus the discussion devolves into a pissing contest over whose programming language is the most object oriented... Look, one can reasonable agree to disagree on the definition of 'object-oriented', but I don't see how you can seriously state that C++ is not object-oriented. According to the most broadly accepted superset of what constitutes 'object-oriented', C++ is object-oriented (o…

You're right, I meant that it's not strictly object-oriented, it supports multiple paradigms, with OOP being one of them. :)

Yes, that I agree with.

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

#102

Post by roel_v »

antirez wrote: post #94
roel_v wrote: post #64

Earlier quoted context omitted.

"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.

Fair enough, but I'm still interested in examples of subtle programmer errors with templates.

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

#103

Post by beagle3 »

jbooth wrote: post #100
beagle3 wrote: post #98

Earlier quoted context omitted.

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

> Are you claiming there's a java language requirement that array indices are named with more than one letter?

No, but it _is_ common practice to name things with long names, rather than one letter, even if they are loop indices. E.g., in the FLTK source code, most objects inside a short loop are called "o", e.g., things like

   for (Widget o = window->first(); o; o = o->next()) {
     o->activate();
     o->show();
   }
I think that is extremely readable, 'o' in my mind stands for object in the same way that 'i' stands for index. Have you ever seen Java code in the wild that follows such a convention? I haven't -- it's always things like theWidget or even theChosenWidget instead.

> I like go and Rob Pike's reputation speaks for itself but don't put words in the guy's mouth

Please don't put anything in my mouth. I'm paraphrasing pike, you may disagree with the paraphrasing, but I was referring to, http://www.lysator.liu.se/c/pikestyle.html , specifically the section titled "Variable names". It's about C, and predates Go by some 18 years (and Java by 6). Not any "pet language" of mine.

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

#104

Post by ElliotH »

msg wrote: post #91
ElliotH wrote: post #69

Earlier quoted context omitted.

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...

There are other methods on Integer and such - it was a contrived example because I was too lazy to read the docs.

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

#105

Post by cafard »

forgotAgain wrote: post #87
cafard wrote: post #68

Desert 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.

It's along the lines of "if you were stuck on a desert island and could only have one whatever, which would it be?" So if you had to choose one programming language to do all of your work in, which language would it be?

Actually, I understood. I used to listen to Desert Island Disks 15 or 20 years ago--a local NPR affiliate's version.

One programming language? As I recall DI Disks let one pick 10 pieces of music, and threw in the Bible, all of Shakespeare, and a luxury of your choosing. But I suppose that if one were not distracted by King James, King Lear, or a luxury, the sensible thing would be to follow in steps of Wall, Ousterhout, Van Rossum, and Matz: use C and create an extensible scripting language.

(edit: spelling)

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

#106

Post by jbooth »

beagle3 wrote: post #103
jbooth wrote: post #100

Earlier quoted context omitted.

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

> Are you claiming there's a java language requirement that array indices are named with more than one letter? No, but it _is_ common practice to name things with long names, rather than one letter, even if they are loop indices. E.g., in the FLTK source code, most objects inside a short loop are called "o", e.g., things like for (Widget o = window->first(); o; o = o->next()) { o->activate(); o->show(); } I think tha…

Ok, well I was talking about type systems. You were talking about the fact that it's dumb to have long variable names for loop indices.

I agree. Everyone on earth agrees with you. I don't know if I've ever in my whole career seen a >1 character loop index variable name. Congrats.

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

#107

Post by nradov »

chittis wrote: post #5
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…

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

Just declare a new class with a short name that extends ConcurrentHashMap.

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

#108

Post by blub »

rdtsc wrote: post #95
blub wrote: post #48

Earlier quoted context omitted.

"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 i…

Templates again... Have you used them? In my current project we've used data structure and algorithm templates from the QTL (similar to STL) instead of inventing our own buggy versions.

Then we've used templates to stream arbitrary data-types into an IPC socket.

Finally, we've also used templates to create a generic repository class and to create a specialized compare function for multiple types of containers.

All of these resulted in lesser lines of code without complicating the code base. This kind of template code is nothing fancy and brings real benefits. Now it's your turn to tell me how templates have complicated your projects. Please use real-world examples.

By the way, we're not all true C++ experts in the team and yes, some of us prefer different coding styles. You know what we did? At the beginning we created a coding guidelines/standards document that outlines what is acceptable to use in the project. Problem solved. What you describe - "can't all necessarily read and understand each others' code" - is a dysfunctional team and a management failure.

"it should'be be between C and C++ only"

Ok, we can compare Python + C++ with Python + C, but C++ wins there too. e.g: PyQt/PySide.

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

#109

Post by blub »

rdtsc wrote: post #96
blub wrote: post #52

Earlier quoted context omitted.

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

An extreme example doesn't prove much and there are many languages that successfully balance readability with LOC. e.g: Python, JS.

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

#110

Post by danssig »

Peaker wrote: post #90
danssig wrote: post #82

Earlier quoted context omitted.

>that C is superior to full-blown C++ Couldn't disagree more. C++ has a much better type system than C. For many C++ programmers (myself among them) C++ was less about OO and more about giving C programmers the ability to create new types that have the powers of the built in types. I can have strings with proper string schematics instead of an array of chars that is null terminated by convention (i.e. can't be type e…

That's indeed a great feature of C++. And there are more great features (auto-destructors/RAII, better "const", parameterized types). But I find other features/interactions in C++ are unnecessary and even harmful (inheritance and virtuals, typedef of references, C++'s useless implementation of checked exceptions). Templates are implemented pretty badly (Haskell's type-classes a.k.a the discarded "Concepts" could have…

Good points. I would say that it's better to have too much, so long as I can ignore the bad parts (e.g. checked exceptions) than not enough as in C.

I also disagree about exceptions. It does make control flow trickier to follow, but the problem with C is that to really have all failure cases covered you have to put every single function in an if statement. Anything and everything can fail.

Post reply on HN