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

61–70 of 116 posts

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

#61

Post by dexen »

cdavid wrote: post #34
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 don't think it is an issue of technology (typedef, etc...) as much as an application target issue. Using short names in a language without any kind of namespace support can only work for a certain type of applications and developmenent organization. C really shines for low-level programming: while something like Linux Kernel is extremely complex, it has relatively simple needs as far as interface goes. The public i…

> But something as fundamental as a lack of any namespace in C really hurts when you need to handle very large applications which cannot be easily split in very well defined components with small interfaces.

There is a degree of namespacing in C. Each compilation unit introduces own, anonymous (cannot be addressed/indicated directly) namespace. Symbols defined `static' (``having static linkage'', actually) reside only in it, and are not visible outside of that namespace. Symbols with external linkage are the API of the namespace. It may sound strange, but it's perfectly OK to have symbols with same name in several namespaces, as long as they are static (residing only in it); no conflict because they are not addressible from outside. In a way, a C's compilation unit is similar to C++'s class -- static (C) / private (C++) elements are visible only from this compilation unit (C) / class (C++).

So yes, you can easily split any C application into well defined components with small APIs, without risk of collision between names of private symbols. You only need to ensure unique naming among the `public' API symbols.

Linker use and linkage is a lost art those days, eh ;-(

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

#62

Post by nadam »

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.substring(1, str2.length()); }

Is it really more concise in C? How do you tell the caller to free the memory of the returned string?

And if you compare C to Ruby, Python, Scala, Clojure etc... then it is no question that C is not a concise language for most tasks.

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

#63

Post by [deleted] »

nkurz wrote: post #50
angusgr wrote: post #37

Earlier quoted context omitted.

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

[deleted]

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

#64

Post by roel_v »

Stormbringer wrote: post #49
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…

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 template overload ever could.

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

#65

Post by roel_v »

gcv wrote: post #2

I love the link to OTCC (the Obfuscated Tiny C Compiler, http://bellard.org/otcc/ ). It frankly blows my mind.

I was quite disappointed though that most of the obfuscation comes from the use of the preprocessor. I can make any program in any language look hard if I can rewrite it with an m4 macro before running it.

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

#66

Post by roel_v »

blub wrote: post #44
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…

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

"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 (or rather, can be used in such a way).

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

#67

Post by roel_v »

leon_ wrote: post #43
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…

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.

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

#68

Post by cafard »

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.

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

#69

Post by ElliotH »

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

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

#70

Post by cdavid »

dexen wrote: post #61
cdavid wrote: post #34

Earlier quoted context omitted.

I don't think it is an issue of technology (typedef, etc...) as much as an application target issue. Using short names in a language without any kind of namespace support can only work for a certain type of applications and developmenent organization. C really shines for low-level programming: while something like Linux Kernel is extremely complex, it has relatively simple needs as far as interface goes. The public i…

> But something as fundamental as a lack of any namespace in C really hurts when you need to handle very large applications which cannot be easily split in very well defined components with small interfaces. There is a degree of namespacing in C. Each compilation unit introduces own, anonymous (cannot be addressed/indicated directly) namespace. Symbols defined `static' (``having static linkage'', actually) reside onl…

I know very well about the use of static within compilation unit, but I was referring to "public API" (more exactly: API between components of your application).

This is especially excruciating once you need to use various libraries outside your control.

Post reply on HN