> 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.
> 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.
> 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
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. 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 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.
> 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 Tue Jun 22 2010 - 23:46:09 UTC
This archive was generated by hypermail 2.2.0 : Tue Jun 22 2010 - 23:48:02 UTC