> 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. > 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 > 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. > 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. 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. Emacs, being all but a small operating system in itself, goes against the very idea of simplicity, but each to their own. 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.
