When asked if there was a language that was the best for every situation, he replied with a simple 'No, that's silly'. When asked what other languages beside C he likes best, he said he admires languages like LISP. Overall he was very humble and concise.
>>9
It ain't Lisp, so it's crap. But rest assured, even were it to be a Lisp, then it would be shit.
Name:
Anonymous2011-11-29 23:25
dubs
Name:
Anonymous2011-11-29 23:32
>Q: Outside the C family of languages, what language(s) do you like the best? What in particular makes them interesting to you?
>Ritchie: I have to admire languages like Lisp. But, just as in the earlier question about a "simple" language, an astonishingly simple language grows in practice into something that can be fearsome.
OP: OMG DENNIS RICHIE WANTED TO HAVE LISTHPS BABBYS!!
>>1 Why do you dislike Dennis?
His C/C++ is hard to use: it crashed easily, leaks memory and requires writing a YACC parser for metaprogramming, while the "++*X++" crud is worthy of APL or J.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-30 2:01
>C/C++ is hard to use
Its worse-is-better, every language which is easier or more powerful abstractly, loses very hard on low-level performance vs C, making C a final instance for speed/memory vs ease of use tradeoff, just one step above assembler(which can be inlined into C).
Using plain C for everything will be painful, so either very good C libraries are made/used/imported or the programs are written in higher-level language using some C-library to get extra speed. The rest of the speed/memory curve is filled with language which are either too hard to use or have steep performance costs so they're not used beyond toy programs. C wins either way, since nothing can compete with optimized C compilers for the #1 performance spot it takes and Asm went out of fashion after systems became more complex than a ZX spectrum.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-30 2:07
The freedom C gives to make those pointer hacks/raw memory accesses without bound checks and various worse-is-better approaches also make it possible to optimize a program to near-assembler speed.
>>12
Recall that the earlier question was regarding C itself. He said that while C is simple at its core it can grow monstrously, and this trait is shared by LISP.
"Gosling: Probably the most pervasive mistake is not doing a tasteful job of object-oriented programming."
Name:
Anonymous2011-11-30 9:13
check 'em
Name:
Anonymous2011-11-30 9:18
>>15 every language which is easier or more powerful abstractly, loses very hard on low-level performance vs C
No, if it runs on a Lisp machine, that has dynamic typing support.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-30 9:25
>>23
I'm sure if we make C run on a Lisp machine the implementation would outperform Lisp.
>>24
A Lisp Machine's CPU's instruction set is in some ways similar to that of modern VMs' instruction sets (JVM, .NET CIL), thus high-level languages would obtain optimal speed on such architectures. There is a C compiler for Lisp Machines (written in Lisp, of course, although not CL, but a LispM dialect) and it compiles to some crude Lisp which compiles rather straightforwardly to the machine's language (which is high-level enough that it can be decompiled). So no, you would be wrong. Even if you had the compiler output directly to assembly, it would still be somewhat wrong as the memory architecture was designed around (type)tagged data, which doesn't make it C's best friend. On modern machines, such as the x86, C performs best as such machines were designed with C in mind. Turing completeness may let you implement any language in another, but that doesn't mean that some languages are native/near-native to an architecture, and other languages would incur more overhead.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-30 9:57
>and it compiles to some crude Lisp
>which compiles rather straightforwardly to the machine's language
A bad compiler does not make C slow. It just a way of poorly interpreting what C does in lisp
>>25
That is well and good, but one architecture is more efficient in the sense of the amount of real world time that has passed than the other. Efficiency is not relational - it is absolute, and is measured in objective time.
>>26
It's not a bad compiler and it still compiles to something much closer to the machine than the source language. If you want to get more details, just google for it, there's an open source version of it floating around, possibly even in the public domain.
I could try to convince you here that C is really not suitable for that particular architecture, but I think you'd have more fun just installing an emulator and finding out for yourself exactly what the instruction set was.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-30 10:39
Lets see:
All modern architectures | Lisp machine
Assembler is the fastest absolute speed |Lisp asm will have the fastest execution speed
C compiles to optimized assembler |C compiles to Lisp(instead of optimizied assembler)
C outperforms everything,except handcoded asm|C->Lisp->asm is slower than Lisp->asm
Nothing magical
>>29 C outperforms everything,except handcoded asm|C->Lisp->asm is slower than Lisp->asm
You mean that Lisp outperforms C on a machine designed specifically for Lisp? I am shocked.
But seriously, are you trying to say that the fact that C is slower is a disadvantage? Because if you want to write C, don't use a Lisp machine.
Name:
Anonymous2011-11-30 12:33
Lisp is shit.
Name:
Anonymous2011-11-30 14:19
>>24
>I'm sure if we make C run on a Lisp machine the implementation would outperform Lisp.
It wont. Because that would be emulation and Lisp machine's user-space security relies on compiler, instead of memory protection.
Name:
Anonymous2011-11-30 14:20
>>32
And I doubt that C/C++ even outperform Java on JVM.
The fastest LISP implementation of an algorithm on a LISP architecture is going to run slower than the fastest C implementation on a standard architecture. This is a false comparison.
>>35
That's not really what we're talking about. He is responding to people that say that high-level languages would run better on an architecture designed for them. We're talking about C's performance on different CPUs, not Lisp's. And yes, those are two very different discussions.
>>35
It's interesting that someone with strong opinions about the lack of safety of C and C++ would then turn around and shit on the idea of hardware-supported VMs of better languages. "It won't be more efficient!!!!" Because debugging core dumps is so efficient...