I think people that call java interpretted are somewhat misinformed. You certianly can interpret it or any other language for that matter... but that is not what is usually done. It is usually run through a JIT *compiler* so that it is compiled. Interpretted is very different. I've written both compilers and interpretters. The way I alway differentiated is this: if actual machine language that represents the program is getting executed then it is compiled if machine language that is parsing bytecodes or sourcecode or anything else like that is getting run then it is interpretted.
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. You are right to call me out on my weakly typed "bullshit" as you say. I really meant dynamically typed languages are going to be slower all else equal. Besides, C in an exception because while it is weakly typed, all the operations are undefined which is totally different from python or ruby which handles these cases. As far as your analysis of relative speeds... I would say that at the end of the day, if you are a perfect programmer you can obviously obtain the best results with assembly (but who has the time... granted I did back in the day). But, practically speaking, C++ is just as fast (and for most coders faster since they don't know how to optimize for their chip). C has only one feature I know of that could potentially allow it to be faster (the restrict keyword). While C++ has several features that allow for more speed in certain circumstances than C (this is not to say that you can't easily make a C++ way slower as evidenced by most C++ programmers out there). As far as ruby and python though... These languages are much more difficult for a compiler to effectively optimize. In theory, a perfect compiler given enough time would optimize all languages to the same machine code if the program does the same thing. In reality however, in python and ruby the programmer specifies less information to the compiler which in turn makes it considerably harder for the compiler to optimize. But yes, in theory these languages could be much much faster. In reality... it is not going to happen until we are all obsolete anyway because frankly compilers will have to understand the program and a very high level to do the necessary optimizations. But, to be fair, I totally agree that compiling python or ruby would give you noticable speed gains. And as always, speed comparisons are only useful in context. In terms of go programming.... if you are prototyping use whatever the hell you want. If you are finishing something off, don't waste my time with any of those slow languages (that includes java and c#). - Nick On Nov 22, 2007 1:44 AM, Stefan Nobis <[EMAIL PROTECTED]> wrote: > "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 interpreters of Java and C# have got quite some > good optimizations, like the JIT (one could say: interpreter > cache). Python and Ruby lack these optimizations today. > > > But, compiling weakly typed languages is unlikely to give a big > > performance boost and could even hurt it a bit by making large code > > Bullshit. C is weakly typed, Python and Ruby have a dynamic type > system. Two completley different things. > > And there are languages like Smalltalk or Scheme or Common Lisp with > dynamic type systems that are compiled to native machine code. And > there are big performance boost compared to the interpreted code and > you can get a performance comparable to C and fast than Java or C# > with these languages. > > So this is quite possible to do for Python or Ruby, but it seems there > is not enough interest or man-power or knowledge in those communities > to do it today. It's that simple. > > -- > Until the next mail..., > Stefan. > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
