Re: [dev] Interesting post about X11

From: Donald Allen <donaldcallen_AT_gmail.com>
Date: Tue, 22 Jun 2010 13:55:49 -0400

On Tue, Jun 22, 2010 at 1:27 PM, Aled Gest <himselfe_AT_gmail.com> wrote:
>>  * Because manual memory management is a mess.
>>
>>  * Because some data structures and algorithms (red-black trees, for a
>>    classic example) are extremely cumbersome in C compared to other
>>    languages.
>
> Hiding complexity from a programmer does not improve the situation, it
> simply removes the requirement of the programmer having to think about
> what they're doing.
>
> Every good programmer should understand what their code does at the
> machine level, because that's what programing is about, instructing a
> machine. Adding layers of abstraction that obfuscate what's really
> happening is a bad thing imho.

But C does that, too. With C, you are writing in a language quite
removed from the actual instructions the processor executes; it's
hiding the complexity of machine code. So, if we take you at your
word, you are advocating returning to writing assembly code. As
someone who wrote his first computer program in 1960 in assembly
language on an IBM 1620, and who wrote an awful lot of assembly code
in the 1960s and 1970s, I can assure you that's not a good idea.

I also completely disagree with your opinion about hiding complexity
generally. Are you suggesting that all software should be written as a
single, main program, no functions (abstracting away complexity and
detail is a major raison d'etre of functions)? I'd be surprised if you
intended that, but that's a reasonable conclusion to draw from what
you are saying.

I've written a great deal of C and Scheme in my long career (now
retired and enjoying it immensely, thank you). There are times when
I've translated Scheme code to C, because I needed the performance
that even compiled Scheme couldn't provide. But a lot of the Scheme
code was completely satisfactory from a performance standpoint, and
the performance of C becomes less and less of an issue as the hardware
gets faster, which it continues to do. And I can assure you that
Scheme is a *hell* of a lot easier to write, and to read (despite the
parenthesis issue you raise, which I think is a non-issue), once you
grow accustomed to it. It's also much easier to edit with emacs,
because emacs can and does understand the syntactic atomic particles
of the language and can manipulate them, as a result of Scheme's
simple and regular syntax. This is not true of C.

I'd strongly urge you to read Structure and Interpretation of Computer
Programs (Sussman, Abelson, and Sussman, MIT Press). This great book
might change your mind and it's available online, free of charge:

http://mitpress.mit.edu/sicp/full-text/book/book.html

(Disclaimer: Jerry and Julie Sussman and Hal Abelson are old friends
of mine. Julie and I worked together at BBN during the Arpanet and
early Internet days, which is when we both wrote a lot of PDP-10
machine code, in my case a lot of it inside the Tenex and Tops-20
operating systems, and I spent 4 happy years in Jerry's and Hal's
group at the MIT AI Lab 10+ years ago. Having said that, there are
absolutely no ulterior motives in my recommending this book. It's one
of the classics of the computer science literature and if you haven't
read it, you should.)

/Don

>
>>  * Because adding on to C to fix its many small warts would be a mess
>>    (it can be less bad than C++ and still very bad).
>
> Do you say that because of the syntactic structure of C, or because of
> the way the standard is developed?
>
>> Not all modern languages have to be towers of complexity: Scheme and SML
>> are two very simple and elegant languages, and even Haskell 98 can
>> really be kept in your head in its entirety.
>
> I don't think any language _should_ be towers of complexity. But your
> notion of elegance seems to be quite different from mine. Personally I
> see code clarity as a component of elegance, and from a syntactic
> perspective I've yet to see any faithful Lisp dialect that competes
> with well structured C code.
>
> I realize I may be throwing my self into a fire by bringing up
> parenthesis hell, but I believe it's an important point. From a
> practical standpoint, syntactic clarity is very important, and
> syntactically Scheme, like Lisp, is a horrible mess by design.
>
> I've seen people argue that aversion to over-use of parentheses is
> simply psychological conditioning from using languages with a
> different syntax, but I disagree. Over-use of any one symbol for
> punctuation reduces the brain's ability to quickly and effortlessly
> categorize distinct sequences within text.
>
> Conversely I've seen people argue that the power of languages like
> Scheme are such that it is possible to create an entirely different
> language through meta-programing. While I have nothing against the
> concept of meta-programing, I don't see the point in choosing a
> language if for it to behave the way you want you must first mutate it
> into an entirely different language.
>
> Don't get me wrong, C is far from perfect and there are many ways I
> believe it could be improved. For example:
>
> - A powerful pre-processor that supports real scripting.
> - Better support for implementing abstract data types.
> - Greater context granularity.
> - Support for generators and concurrent programming methods.
> - Support for custom calling conventions.
> - Standardized support for passing meta information such as 'type'.
> - Support for stub functions that are guaranteed to be inlined.
>
> I believe those features, if implemented properly, would give the
> programmer greater power over what the code does, and provide greater
> ease for implementing particular models, without adding an extra layer
> of obfuscation.
>
> Of course all this is simply my opinion, we're all free to choose
> whatever programming language we wish to use. My point of contention
> comes from Robert Ransom's suggestion that people *should* be using
> Scheme for everything, without offering any practical reason for
> people to change.
>
> Regards,
> Al Gest
>
>
Received on Tue Jun 22 2010 - 17:55:49 UTC

This archive was generated by hypermail 2.2.0 : Tue Jun 22 2010 - 18:00:05 UTC