On Thu, 2011-12-01 at 02:09 -0800, Walter Bright wrote: [...] > I understand that. Java isn't going anywhere. I was only addressing the idea > that the Java bytecode is a burden for compiler developers or not.
I disagree that Java isn't going anywhere. The hassles over the last year with Oracle are now resolving themselves as IBM influence gains ground. With the publication of the timetable and part road map for Javas 8, 9, 10 11 and 12, the Java community is hugely re-energized. The opening up of the JCP and the voting in of a couple of user groups to the executive committee has made a significant change to the management of Java. Whether this is positive we shall see. The Java bytecodes and JVM are no longer the fixed point they were. Change is now possible. Clearly a zero address stack machine has some issue, I never disagreed with you on that, but I don't see it as the infinite brick wall you were seeming to portray it as. [...] > I suspect Go's market is more the Java market than the C/C++ one. I don't think that is the complete story. Go initial market is cloud systems systems programming. To date this has been a mish mash of C, C ++ and Java with a dash of Python. Go's marketing clearly sets it up against C and somewhat against Python. They are ignoring the JVM arena (at least for now) as they don't see how to get traction there quickly enough to make things work for them. [...] > It is when they are using a Java stick to beat D with :-) :-) I still think that in the short term there is no value in D trying to address markets currently dominated by JVM or CLR. Much better to carve out a presence in an area with a lower barrier to entry. Python attacked the Perl market and made headway. It then attacked C as GUI development language and basically won. Now it is attacking the HPC data visualization arena and is winning. D needs to spot an angle and go for it. [...] > The C++ folks do the same thing. Rather than add vector operations to the > core > language, they rely on "vectorizing" compilers that reverse engineer loops > into > a higher level construct. The Fortran folk introduced "whole array operations" to avoid having to do that -- even though they did all the inferencing on loops for legacy code. Best move yet in the Fortran world, since now people write higher level code and let the code generator do all the nifty optimizations. C++ must have done the same by now: there must be good BLAS, and high level vector/matrix systems, especially with GPGPU being the driving force these days. [...] > So color me a bit weary of the abuse. I tend to let people do their own > benchmarks. It's also why I stopped publishing language comparison charts. Sad, but understandable. If you still have some of the codes, perhaps there is a way that this can be turned into something? Clearly the Alioth shootout is one possible model. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
