Re: [dev] Interesting post about X11

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

Indeed C does, but it does it to a lesser extent, C provides the
convenience of being a higher level language without removing the
programmers ability to control how the program performs at the machine
level. If you understand what code the C compiler produces, it's very
easy to control how the program behaves.

While I believe assembly language still has a place other than in
compiler design, and will always do, I'm not in any way suggesting
that we should all go back to programming purely in assembly and
forget about higher level conveniences.

When it comes to stuff like modularity & portability of code,
abstraction is a very good thing to have. Like most things,
abstraction has a place where it makes sense, and when used properly
it provides value to code, but from what I see languages like Lisp and
Scheme provide extreme abstraction at the cost of removing the
programmer from low level interaction.

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

No I'm not suggesting that at all. There's a difference between the
abstraction functions provide, and an entire language being
abstracted. While functions hide the details of their functionality
from the caller, those details are still available and easy to see.
Whereas with a language like scheme, those details are hidden in the
compiler or interpreter.

Admittedly even in C when people use things like the C standard
library, it's not so easy to see what the code does, but then I'm not
a fan of the C standard library either. :P

> the performance of C becomes less and less of an issue as the hardware
> gets faster, which it continues to do.

I really can't stand it when people use computers getting faster as an
excuse to be lazier, or as an argument in support of less efficient
software. I think it's quite ridiculous that it requires a quad
octa-core system with 16 exabytes of ram just to run an office
application. It's like software developers are trying to compensate
for computers getting faster, by making software run slower.

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

Perhaps to you, but I don't see it. TCL has a similar idea being a
language based on the concept of lists, but it's a hell of a lot
easier to read. I quite often use TCL to quickly prototype things or
create quick scripts to get a job done that would require more effort
in C, but I in no way believe that everything should be written in TCL
or that everybody should be writing TCL.

Of course, anything's easier to read once you get used to it, because
your brain becomes attuned to the way of thinking required to work in
a particular environment, that doesn't mean it's a good idea for
everybody to become attuned to working with scheme though.

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

If emacs can't handle the syntactic simplicity of C, perhaps you
should choose a better editing environment. Emacs, being all but a
small operating system in itself, goes against the very idea of
simplicity, but each to their own. Everybody's free to use whatever
tool they choose. If you expect others to follow suit however then you
need to give a valid reason as to *why* it is beneficial for them to
do that.
Received on Tue Jun 22 2010 - 21:14:38 UTC