Re: [dev] Interesting post about X11

On Tue, Jun 22, 2010 at 5:14 PM, Aled Gest <himselfe_AT_gmail.com> wrote:
>> 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.

No. The extent to which you employ abstraction (in the sense of how
your code is architected) is your choice in Scheme and in C. What
Scheme gives you is very clean semantics, simple syntax, and garbage
collection. Together this makes creating correct code a great deal
easier, at the cost of some performance. Sometimes the performance
cost is well worth paying in return for lower implementation cost.
Sometimes it's not (you wouldn't write a real-time operating system in
Scheme, for example).

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

I suspect that what is bugging you (pun intended) is that you want to
know the resource costs of the primitives you are using. The closer
you get to the instruction level, the better you know that. I'm
guessing that's part of why you don't like the C library. They're
presented to you as primitives, but you don't know what they cost,
because they're black boxes you're not supposed to look inside.

That's fine when you are developing performance-critical code, or
software that has to run in a resource constrained environment (I was
going to use cellphones as an example, but those things are
super-computers compared to some of the stuff I've worked on in my
time). But it's frequently not a good cost-benefit bet when writing
code for PCs or servers these days (hasn't been for a long time),
because the hardware is so powerful.

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

It has nothing to do with developers making software slower because
hardware is faster. You can't really believe that! It has everything
to do with changing cost-benefit tradeoffs. When clock-frequencies
were measured in khz, kilobytes of memory came in cabinets the size of
a refrigerator, and computers cost hundreds of thousands of dollars or
more, it was economic to pay people to slave over code, shaving a
cycle here and a cycle there, or a byte here and a byte there. As the
hardware has become more and more capable, the economics has changed
(just as cheap computing gave birth to packet-switching in place of
circuit-switching, because the wires had become more expensive than
the computing power that allowed us to share them) and now people-time
is much more expensive relative to computing resources than it used to
be. Thus we sacrifice cheap computing resources to save expensive
human resources.

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

I have written a lot of TCL (and supervised the development of one of
the first web-based stock brokerages, written in TCL (1994 and 1995),
though the choice of TCL was not mine). It has its place, but I
disagree strongly that it's easy to read, especially as code-size
grows. It is littered with $s, curly braces, square brackets, [expr 2
+ 2], bad scoping rules, and lots of other awful stuff. For small
amounts of code, TCL can be very useful and there's a lot of power in
what is available in its environment. But as code size grows, it
quickly becomes unmanageable, because of the limitations of the
language, compared to a well-designed language like Scheme or Python.
I don't think Ousterhout ever intended TCL for large projects.

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

We're not communicating well here (could be me!). Scheme/Lisp is built
from a very small number of syntactic contructs (atoms, parenthesized
expressions) that are unambiguous, whereas a language like C has a
large number of special syntactic cases and more importantly,
ambiguities. It would be very difficult, perhaps impossible, to
implement, say, Emacs' meta-ctrl-k for C. If I want to kill (+ foo
bar), I stick the point at the left paren and meta-ctrl-k does it's
thing. But what about foo + bar in C?

It's hard to describe the effect of this, but you can either take my
word for it that it's big ...... or not.

Emacs, being all but a
> small operating system in itself, goes against the very idea of
> simplicity, but each to their own.

But operating systems are extremely useful, so we use them. I'll bet
you do, too. Emacs is extremely useful and performs just fine on
modern hardware.

 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.

I don't *expect* you to do anything. We're discussing a couple of
religious issues here (programming languages and editors), mostly for
the fun of it. Given your opinions and the way you seem to think about
things, I doubt that I will convince you of anything and vice-versa.

/Don

>
>
Received on Tue Jun 22 2010 - 22:05:33 UTC