Darren Cook [EMAIL PROTECTED] writes:
Stefan, judging by this site (which I posted some links from
yesterday) your intuition is correct:
http://shootout.alioth.debian.org/
To clarify: I don't really like these non-scientific benchmarks (in
many cases I assume no one or only really few
Don Dailey [EMAIL PROTECTED] writes:
I thinks it's very difficult to outperform C since C really is just
about at the level of assembly language.
No, in special cases it's not that hard to outperform C, because the
language spec dictates some not so efficient details. C has an ABI and
it's
Dave Dyer [EMAIL PROTECTED] writes:
The biggest underlying reason is the multiple constraints on
memory management;
But these constraints are not absolute truths. At least not in Common
Lisp: The language spec is not as constrained as described here and
the compilers add some additional
terry mcintyre [EMAIL PROTECTED] writes:
Any of those with recent Lisp experience have any opinions about
multicore capabilities?
Multithreading is not available in ANSI CL, but most implementations
support multithreading in some ways. AFAIK SBCL, Corman Lisp, OpenMCL
and some more have true
Benjamin Teuber [EMAIL PROTECTED] writes:
Man, we really need a complete Common Lisp Go Framework which also
has some fast low-level code to show all these C gurus its true
power :)
I think so, too. :)
I don't want to say CL is the one and only language (for me surely it
is), I only try to
Dave Dyer [EMAIL PROTECTED] writes:
Languages like SQL and Prolog don't specify algorithms, they
describe the desired result.
Take a look as Haskell -- it's a very high level language but
functional, so you are describing algorithms in it. Yet the compiler
has so much knowledge (because of a
Nick Apperson [EMAIL PROTECTED] writes:
Java certainly supports both modes, but what I said is true. If you
are executing a loop repeatedly the actual code gets converted into
machine language that represents the actual code. It is not parsing
bytecodes anymore at this point.
It's a bit
Stuart A. Yeates [EMAIL PROTECTED] writes:
There are some languages (such as Perl) which have language features
which absolutely precludes JIT as we know it.
Your example doesn't convince me: Your Perl example may be compiled
(but maybe the resulting code is a bit more complex than a direct
Don Dailey [EMAIL PROTECTED] writes:
To me, the ideal language will let you seamlessly step down to high
performance coding in something just as efficient as C but be able
to use much higher level language features without getting in the
way of performance
Hmmm... you are just describing
Colin Kern [EMAIL PROTECTED] writes:
I think the reason for Ruby being so much slower is because it is an
interpreted language rather than a compiled language.
It's not the main problem (interpreted languages are slower than those
compiled to native code, but than even Java and C# are
Nick Apperson [EMAIL PROTECTED] writes:
Java and C# are both compiled at some point if the same loop is
At some point everything has to be translated to machine code. But
Java, C#, Ruby etc. are doing this at execution time -- that what most
people call a interpreter.
You are right, the
[EMAIL PROTECTED] (William Harold Newman) writes:
Still, though, sometimes useful things resist elegant implementation
in CL. For example:
* I doubt CL can be customized to support a thread library nearly
as gracefully as languages designed around threading from the
ground up.
All
Chris Fant [EMAIL PROTECTED] writes:
I would like some language recommendations.
So I would suggest Common Lisp: The programmable programming
language. I think it's the single most flexible language -- you get
everything, from imperative over object-oriented to functional and
declarative
Nick Apperson [EMAIL PROTECTED] writes:
Reference counting and copy on write.
Do you know that there's much more to garbage collection than
reference counting and that reference counting has some major
drawbacks? There are even hard real time capable garbage collectors
out there.
But I'll be
Nick Apperson [EMAIL PROTECTED] writes:
And I don't htink I missed the point about productivity. I've heard
that argument time and again. That is fine. I personally find that
with the STL in C++ and with the ability to write my own templates,
I can write algorithms in fewer lines of code
Don Dailey [EMAIL PROTECTED] writes:
I must be a dinosaur - at least a minimalist - but I don't
understand the big deal about library support that has been
mentioned a lot here.
For Go library support isn't very important -- just one argument more
in favor of more exotic languages, that make
Bob Myers [EMAIL PROTECTED] writes:
Many of those complaining about XML don't seem to really know too
much about it.
The problem with XML is, that most people using it don't know anything
about it and possible alternatives, using XML for everything, even
when there are better alternatives
Robin Kramer [EMAIL PROTECTED] writes:
So if there was any language which allows a programmer to port their
code to be compileable and executable on a wide variety of systems
it is C.
Hey, are C and Java are all you guys know about?
What about Ada? I'd say it's much easier to write portable
Dmitry Kamenetsky [EMAIL PROTECTED] writes:
The forums that I really like are the TopCoder forums
(http://forums.topcoder.com/). I like them for these reasons:
And really everything of these reason are features of good E-Mail
clients (except the +/- voting). So with the right client you get
Antoine de Maricourt [EMAIL PROTECTED] writes:
I can develop very quickly 'quick and dirty' code to test new ideas
in C++, and recode it in a very clean / organized / modular / robust
... code later if needed. This ability is not coming from the
programming langage itself...
I beg to differ.
20 matches
Mail list logo
