A language should not limit you, some people might like it, i don't.
No need to waste time on this, if you believe those languages can do
things that you say, write a simple but competitive ray/pathtracer. No
need to use sse or any fancy stuff, just bare compiler with its standard
library, compare with those out there. If it outperforms the ones out
there, i will be the first one to switch, why would i stay? I know C++'s
shortcomings more than those language fans that actually don't code but
talk :)
On Thu, 14 Oct 2010 13:59:07 +0300, retard <r...@tard.com.invalid> wrote:
Thu, 14 Oct 2010 13:28:27 +0300, so wrote:
What's your definition of a "system language"? Being able to write
operating systems, OS drivers, kernel mode applications, embedded small
footprint applications, server applications, games, simulations, HPC?
If you only need one of these domains in your project, why should you
care about the rest - the right tool for the job, right?
It is right, right (and only) tool in those domains, and as you can see
it is kind of a large area.
None of those languages are the right tool in those areas, are they?
I'm just saying that a single tool doesn't need to excel in all those
domains. Pick one problem and one language / set of languages for the
solution. Server programming and C# -- why not? I've even done that
commercially (nothing big, but anyway). Games in Scala -- doesn't sound
bad. It depends so much on the language's implementation.
I'm guessing your definition is the one that makes functional languages
or imperative languages with different syntax from C/C+++ look bad and
C/C
++ shine. Your agenda is to crush all competition because the retarded
competitors think *differently* and that's dangerous!
I said i like Haskell, also python... i am not an OOP fan. I don't have
an agenda to crash any competition. How did you get here beyond me...
Look, i said things like "OS" "C audience", "high performance", "system
language". Is that really hard to get?
'High performance' and 'system language' are both badly defined. From
historical perspective something that *was* fast 30 years ago can't
nowadays compete with sofware written in the slower languages. In the
Java world the same binary might run faster on a more recent VM, but this
isn't the case with proprietary native executables. There's no single
answer to the question.
For example, is LLVM a good tool for high performance code? Does it have
lots of potential? I think it does. I think it's one of the best tools
for the job -- even funnier, the Glasgow Haskell is using LLVM as its
backend.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
