C Craft: C is the desert island language. • Hacker News Board

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

#111

Post by berntb » Fri, Apr 08, 2011, 10:37 AM UTC

gnosis wrote: post #92

berntb wrote: post #84

Earlier quoted context omitted.

Sigh, are you trolling or new? OK, I'll answer. The point of printing and browsing code is that it is easier and nicer than to read it on a screen (you'll have a portable with you at the cafe anyway to search, annotate, etc.) If you get lots of broken lines, it isn't readable. Point was, you lose a capability with long lines -- a nice way to go over code. This is important for many of us. Edit: Point jedsmith, write…

Broken lines? We no longer live in the days of typewriters or daisychain printers with fixed column widths. We now have these wonderful things called laser printers which can print using fonts. Fonts are resizeable. Even to the point that 150+ columns could be fit on one unbroken line. And even lines that long can be quite readable if you print in landscape.

Let me first not that printing was a little sub point.

Second, in what you quote from: easier and nicer than to read it on a screen.

So your argument seems to be that it is equally nice to read fewer lines of paper in a smaller font. Huh? Also, my eyes can't handle 4 pages on a page any more -- and your eyes won't be able to do that after 40, either.

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

#112

Post by anon_d » Fri, Apr 08, 2011, 12:27 PM UTC

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…

It's silly to expect to be able to understand text in a foreign language. If you want to read APL, learn APL; It's a great language.

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

#113

Post by rdtsc » Fri, Apr 08, 2011, 4:47 PM UTC

blub wrote: post #109

rdtsc wrote: post #96

Earlier quoted context omitted.

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

Right, I was just trying to highlight that a simple metric of LOCs is not enough. One can right cryptic code to minimize LOCs but that usually leads in harder to read and maintain code.

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

#114

Post by rdtsc » Sat, Apr 09, 2011, 9:56 AM UTC

blub wrote: post #108

rdtsc wrote: post #95

Earlier quoted context omitted.

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

> Templates again... Have you used them?

Not much and I have nothing against templates. Just used them as an example of C++ features. It could have been any one of: RTTI, nested classes, smart pointers, the rules of inheritance and access control, friends, exceptions, operator overloading, streams and so on. All of this is well described but in about 1000 pages in Stroustrup's book.

> At the beginning we created a coding guidelines/standards document that outlines what is acceptable to use in the project. Problem solved.

Well that was actually one of my points. If you need a 50 page language style guide, then I would argue there is something wrong with the language. The whole K&R book is just a couple of hundred pages.

That is why I would believe someone who says "I know C" vs someone who says "I know C++".

I guess I just don't see the advantage of learning the "++" part of C++ vis-a-vis the resulting increase in readability/productivity.

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

Well, maybe. Most Python extensions are still written in C. Python itself has a native C API. There is the ctypes library. For every Python & C++ library integration there are hundreds of Python modules with their performance critical parts written in C. The reason PySide is so nice is because they were able to hide the C++ part very well behind Python. It is certainly a development success story, but what I had in mind was the process of implementing the prototype in Python, then finding the performance critical parts and re-writing them in C.

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

#115

Post by rtaycher » Sun, Apr 10, 2011, 6:11 AM UTC

extension wrote: post #32

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…

While it can get a bit silly sometimes, I've come to really appreciate the verbosity of Obj-C method calls. Explicit parameter names make them very self-descriptive, and grouping the entire call within brackets makes structure obvious. Compare: canvas.drawImage(kittens.subImage(vec2(10,10),vec2(20,20)),vec2(30,30)) vs [canvas drawImage:[kittens subImageAt:vec2(10,10) withSize:vec2(20,20)] at:vec2(30,30)]

Yes but some of the examples of obj-c I've seen look ridiculously wordy compared with the smalltalk equivalents (even if you ignore op overloading). (setObject: forKey:) vs (at: put:). for ex.

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

#116

Post by Peaker » Tue, Apr 12, 2011, 4:51 PM UTC

danssig wrote: post #110

Peaker wrote: post #90

Earlier quoted context omitted.

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.

> Anything and everything can fail.

In my experience this is only true until you switch to a style where memory allocations (which are used in "anything and everything") are given to functions as arguments (from the top) rather than via malloc or such.

When allocations are given as arguments, the main reason for errors/failures disappears and a blissful ripple effect of failure-returning -> void-returning functions usually results.