Re: [dev] Interesting post about X11

On Tue, Jun 22, 2010 at 7:46 PM, Aled Gest <himselfe_AT_gmail.com> wrote:
>> 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've yet to see evidence of that in Scheme's case. If you can provide
> links to practical examples, of tools that are cleanly and efficiently
> written in Scheme, that aren't purely academic in purpose, and don't
> come with 30 pages of waffle about how great Scheme is, I'd be happy
> to take a look.
>
> I have to warn you though, the last time somebody on this mailing list
> linked to something they purported to be a quick unbiased no BS
> introduction to Lisp, I got bored after the first few pages of the
> author stating he wasn't going to chime on about how great Lisp was,
> while chiming on about how great Lisp was. I'm a 'kinesthetic' kind of
> person, academic waffle bores me.
>
>> 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.
>
> No, I dislike the C standard library because it's badly designed with
> a poorly thought out API.
>
>> 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.
>
> I guess it's a question of competence. Competent programmers don't see
> efficiency as a cost, incompetent programmers and business managers
> who have no interest in producing good quality code do. The software
> industry as it stands today is a testament to the laziness and
> downright incompetence of a large proportion of programmers.
>
> Being in the mindset of producing efficient code fosters creativity
> and ingenuity, which is beneficial to all aspects of software
> development. It's incredibly short-sighted to think that faster more
> powerful hardware means there's less need to pay attention to what
> your code does and how it behaves.
>
> Wasted resources are wasted resources, and that translates to wasted
> money. Any cost you save by being lazy is lost by inefficient use of
> resources.

Yes, wasting resources is a Bad Thing, by the strict definition of
'waste' -- cost with no benefit. But if you use more of one
inexpensive resource in order to reduce the use of another expensive
resource and achieve a net gain in the process, that's not waste,
that's smart.

>
>> It has nothing to do with developers making software slower because
>> hardware is faster. You can't really believe that!
>
> I believe developers are getting lazier, as hardware becomes faster, yes.
>
>> 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.
>
> Quaint anecdotes about days gone by when you were the project leader
> for anything and everything we could possibly discuss aside, at no
> point did I suggest that TCL was suitable for large projects. TCL is
> bloated and horribly inefficient, the point I was making was that
> while I find TCL to be a useful tool for cheaply and quickly achieving
> particular goals, I in no way think that it's a be-all end all
> language that should be used for everything by everyone. And yes, TCL
> has many syntactical quirks that result in messy code, but in my
> honest opinion it's less messy than Lisp based languages like Scheme,
> because there is less superfluous punctuation.

How much Lisp/Scheme have you written?

>
>> 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.
>
> So you say.
>
>> 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?
>
> If foo + bar is in the middle of a bigger line then:
>
> Ctrl+shift+right-arrow-3-times, del
>
> If it's at the end of the line:
>
> Ctrl+shift+end

Note the 'if's in what you said above. There are a lot more examples
that will involve a lot more ifs when editing C, none when editing
Scheme.

>
> Most decent GUI based text editors support those key combinations, I
> can't speak for console based text editors because I don't do much
> programing with console based text editors. At the end of the day if
> you really wanted to you could write (foo + bar) in C and it wouldn't
> punish you for it.
>
> Text editing problems are problems to be solved by writing better text
> editors, not by imposing superfluous constraints on languages.

Superfluous? The regular and simple syntax of Scheme and Lisp is one
of the factors that allows the language to easily take full advantage
of the von Neumann architecture: programs that write and execute
programs. (TCL actually has this virtue, too, because there's some
Lisp influence in its design, though it's not nearly as clean as
Scheme.) The ease of editing is a side-effect of this, a property of
Lisp that has been there since the language was invented by John
McCarthy in the early 1960s, long before text editors were a gleam in
anyone's eye. So you've got the cart before the horse -- the simple
editing is a consequence of a long-standing property of the language;
there were no contraints, superfluous or otherwise, imposed on Scheme
to make it simple to edit.

 It
> wouldn't be too hard to make a text editor that deletes expressions
> between the cursor and <punctuation symbol>, for example ctrl+k to
> delete |foo + bar; -- '|' being the cursor and ';' being the
> punctuation symbol.
>
>> 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.
>
> Operating systems have a purpose, a wholly separate purpose to text
> editors.  Text editors are not operating systems, and operating
> systems are not text editors. Tools don't have to be monoliths or
> behemoths to be useful.

I never said that. I said, in effect, that complex tools are sometimes
useful, even essential. Yes, simplicity is a virtue, but sometimes you
can't have it, either because it's inherently impossible or it simply
hasn't been done.

You have been professing to be allergic to anything big and
complicated ("Emacs, being all but a
small operating system in itself, goes against the very idea of
simplicity, but each to their own.") but I was pointing out to you
that you use operating systems, which are big and complicated. You do
because you can't compute without one. Do you use gcc? Big and
complicated. With editors, you have more choice. I choose emacs
because it's useful to me, it works well on today's hardware even
though it's huge (here again, we have the trade-off that you hate; I'm
willing to burn some extra cycles and some extra memory, courtesy the
super-computer on my desk, to save me time and effort, allowing me to
work on the real problem I'm trying to solve; that's a characteristic
of a good tool -- giving you leverage in order to accomplish something
good that you wouldn't otherwise be able to do) so on a cost-benefit
basis, it works well for me. Quite evidently, you don't feel that way.
So use something small and simple, if it makes you feel better. But if
it makes you less productive, I'd argue that that's a bad trade.

>
>> 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.
>
> You joined a conversation in which one participant was suggesting that
> people should use Scheme for pretty much everything. I've yet to see
> practical rationale that validates this suggestion.

The only thing that has a chance of convincing you, and I think it's a
very slim one, is if you actually spent some time doing Scheme
development. I doubt that a "practical rationale" exists that would
move you at all.

What you are hearing from Scheme advocates comes from experience with
the language and developing in it. It's hard to describe its virtues
in the abstract (again, pun intended). It's a bit like Supreme Court
Justice Potter Stewart's comment about pornography -- "it's hard to
define, but I know it when I see it". All I can say to you is that
I've been doing this for a very long time, I've written code in just
about every language you can think of (except Perl, which looks like
something that came out of a broken modem to me; didn't Paul Graham
say that it looks like a cartoon character cursing?), and I am more
productive in Scheme than any other language (one reason is that Jerry
and Guy Steele found a very small basis set; I almost never consult
documentation when writing Scheme -- the small set of core principles
are in my head; that's not true of C, particularly when writing
declarations). There's also the 80-20 rule to consider. If one
develops in Scheme and finds that the result is too slow, there's
always the escape to C for the critical inner-loop stuff.

Having said that, my guess is that your experience would be different
than mine. We've already agreed that we see things very differently
and, as I've said above, my guess is that even if you made a
good-faith attempt to gain some Scheme experience, you'd still hate
it. There's nothing wrong with that -- there's lots of work in the
world for people who want to be close to the hardware and feel the
electrons buzzing around them. But I do suggest that you to think more
about the net productivity of computer + human rather than just the
computer; you'll accomplish a lot more as a software developer if you
do.

>
>> Given your opinions and the way you seem to think about
>> things, I doubt that I will convince you of anything and vice-versa.
>
> I completely agree with you there. Our perspective on things and our
> interpretation of the meaning of words appears to differ quite a bit.
>
>
Received on Wed Jun 23 2010 - 14:33:41 UTC