On 23 June 2010 01:46, Aled Gest <himse...@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. > >
