Re: [dev] Interesting post about X11

On 23 June 2010 01:46, 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 agree, many people writing about Lisp like to frequently point out
how great it is. I am no exception.
Much of what _I_ like about Lisp is also true for Lua however. I am
new here, so I don't really know how familiar the topic is with you
people. If you are tired of hearing about it, please move along,
nothing to see here.

- In Lua, functions are first class 'objects', in the sense that you
can store a function in a variable and pass it as an argument and so
on. (There is no 'object orientation' per se, although with a minor
amount of boilerplate you can produce something with comparable
functionality). This goes hand in hand with closures, which Lua also
supports.

- As far as (complex) datastructures go, you are limited to (hash)
tables, which are passed by reference.

If that has made you curious, check out
http://en.wikipedia.org/wiki/Lua_%28programming_language%29#Features

Two great bonusses:
1. The Lua community is much less full of itself than the Lisp community.
2. You should like the syntax, very readable.

Unfortunately, Lua is rarely used as a standalone language, which I
don't really understand. It is much cleaner, leaner (and faster) than
Python for instance.

 (Disclaimer: I implemented 95% of the software for my BSc thesis in Lua)

>> 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 Wed Jun 23 2010 - 00:33:01 UTC