gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Re: Re: darcs vs tla


From: Dustin Sallings
Subject: Re: [Gnu-arch-users] Re: Re: Re: darcs vs tla
Date: Thu, 11 Nov 2004 15:24:20 -0800


On Nov 11, 2004, at 14:25, Matthew Palmer wrote:

        I'm not sure about this.  python doesn't seem to have more reserved
words than C. Then you have the special characters: = + * / [] {} () : ^ % # " """ ' (many of which are the same as many other languages).

But do those tokens do significantly more than what they do in C?

IN some cases, yeah, quite a bit. For example, how many lines of the equivalent of this (contrived because I'm too lazy to look for anything better) example in C?

# Create a hash table mapping all of the md5s of the word list to the words in the list
        ht = dict([ (md5.md5(word).hexdigest(), word) for word in words])

(oh, and the best part is I checked my work in an interactive python interpreter...but that's a different argument)

Seeing code doing a lot of list management, memory management, checking the result of everything it's telling something to do just to ensure that it does it, etc... makes it very difficult to tell what the code is actually *supposed* to be doing.

Then you
start piling the whole standard library on top, which is where a lot of the
productivity gains come from (hey, I don't have to hand-code a lot of
<whatever>, I'm so much quicker), and suddenly there's a lot more to learn to say you're a Python guru over what you need to learn to become a C guru.

I don't really buy that. I'm pretty sure there's still stuff in the UNIX C APIs I've not quite figured out how to use, but higher level systems tend to be a little more straight-forward to me. For example, it took me a good bit of experimentation to figure out how to use kqueue/kevent. There are a huge number of possibilities wrapped into one function. The difference between setting up an event to watch and watching for the event looks something like this:

        kevent(kq, &dir_watcher, 1, &out_list, 0, NULL);
        kevent(kq, NULL, 0, &out_list, 1, NULL);

I suppose that looks pretty easy, but I had to read quite a bit and experiment quite a bit to figure out how to effectively use that one function call. There are quite a few more.

        You're looking at it the wrong way.  I don't think anybody's
suggesting there's a language that people can't make ugly code in, but
it's been my experience that well-written code in a high level language is far easier to read than well-written code in a lower level language.

Your standards for "well-written" just aren't high enough for the
lower-level language.

        Or, more specifically.  It's easier to understand what five lines of
well written text means than twenty lines of well written text.

That's why it's easier to read Perl than C? Because you can stuff more into a line? I find Perl an absolute pest to read because there's 10 ways of
stating anything, despite any size gains made from doing so.

Again, I pretty much exclude perl from any ``well-written'' arguments. Yes, I've seen well-written perl that was readable enough, but the fact that there are so many accepted ways of doing things prevents it from scaling to lots of developers unless there are strict standards on what's acceptable.

The obfuscated code contests show that you can fit a lot of C code into a small space, but that alone isn't what makes it more readable. It's that the best, easiest, most obvious way to do something for both the writer and the reader are short enough that you can understand what's going on more quickly because you have to read less.

--
Dustin Sallings





reply via email to

[Prev in Thread] Current Thread [Next in Thread]