I came across this on the web:
http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
Which I don't think anyone has mentioned in comp.lang.lisp
(at least I didn't see it in Google)
--
~jrm
Joe Marshall <·············@comcast.net> writes:
> I came across this on the web:
>
> http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
>
> Which I don't think anyone has mentioned in comp.lang.lisp
> (at least I didn't see it in Google)
A good start toward Greenspun's Tenth Law, I'd say...
--
__Pascal_Bourguignon__
http://www.informatimago.com/
> A good start toward Greenspun's Tenth Law, I'd say...
Yep. A lot of the stuff in modern C++ is very remniscent of
Greenspun's Tenth law. However, thanks to de-facto standards like
Boost, its not buggy or poorly specified :) I'd say that its a good
thing --- more people get exposed to powerful language features.
Recent developments have really exposed the need for a couple of
Lisp-y features, especially type inference, lambdas, and macros. The
sheer number of people trying use the template mechanism to get these
features shows that the demand is definately there.
C++, though, is reaching a point where these high-level features are
ceasing to make sense. The limit seems to be lambdas. Boost implements
lambdas and closures (and they work just fine) but the syntax is
hairy, and the compiler messages are indecipherable. Worst of all,
performance could be affected. C++ compilers (because of the strict
object layout guarantees) just don't have the leeway to optimize that
Lisp-style compilers do. This is one of the principle reasons that the
STL can be awkward. It doesn't use any dynamic dispatch. This means
that STL arrays can be as fast as C arrays, but also makes the
interface more complex. In comparison, Dylan's[1] arrays have the same
performance as native C arrays, but have a nice generic interface
because the compiler can recognize when the generic dispatch is not
necessary and get rid of it.
[1] I say Dylan because (a) I've benchmarked it against the STL, and
(b) I don't know if CMUCL can get the same level of performance using
CLOS.
Joe Marshall wrote:
> I came across this on the web:
>
> http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
>
> Which I don't think anyone has mentioned in comp.lang.lisp
> (at least I didn't see it in Google)
Then The Road to Lisp Survey had a scoop a few months ago:
http://alu.cliki.net/Brandon%20Corfman
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application