On Saturday, 11 August 2012 at 18:04:29 UTC, Paulo Pinto wrote:
On Saturday, 11 August 2012 at 16:12:14 UTC, Peter Alexander
wrote:
On Saturday, 11 August 2012 at 14:45:55 UTC, Russel Winder
wrote:
On Sat, 2012-08-11 at 02:19 +0200, David Piepgrass wrote:
[…]
I hope someday to have a programming system whose features
are not limited to whatever features the language designers
saw fit to include -- a language where the users can add
their own features, all the while maintaining "native
efficiency" like D. That language would potentially allow
Rust-like code, D-like code, Ruby-like code and even ugly
C-like code.
I guess you don't want to be the one to kickstart that PL.
I've been planning to do it myself, but so far the task
seems just too big for one person.
<quasi-troll>
Isn't that language Lisp?
</quasi-troll>
You missed the native efficiency part :-)
You mean like the Common Lisp compilers that are able to beat
FORTRAN compilers
in floating point computations?
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.5725
--
Paulo
Not sure where you read that in the paper.
From the conclusion:
"We have demonstrated that the speed of compiled Common Lisp
code, though today somewhat slower than that of the best compiled
Fortran, could probably be as efficient, and in some ways
superior."
Probably is the operative word there.
Most modern Lisp implementations employ JITing one way or
another, so
you do get native code. Just not on the first run through a bit
of code.
JIT has its limits. A dynamically typed language is still
dynamically typed once compiled. Sure the JIT may be able to
deduce the types in some cases, but not all.
I do see your point, but in general it's still not as fast as
optimised C.
