Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sun Hires Two Key Python Developers

kdawson posted more than 6 years ago | from the money-where-their-mouth-is dept.

Sun Microsystems 173

sspringer writes to let us know about Sun's continuing push to support scripting languages other than Java on its Java virtual machine. Sun just hired two key Python developers: Ted Leung, a long-time Python developer at the Open Source Applications Foundation, and Frank Wierzbicki, who is lead implementer of the Jython project. They will both work on Jython, which enables Python to run on the JVM. Last month Sun's CEO said the company wants to "take the J off the JVM and just make it a VM."

cancel ×

173 comments

Sorry! There are no comments related to the filter you selected.

Python Developers? (5, Funny)

techpawn (969834) | more than 6 years ago | (#22634440)

Got my hopes up! I thought you meant John Cleese and Terry Gilliam had new work at Sun...

Re:Python Developers? (5, Funny)

stoofa (524247) | more than 6 years ago | (#22634488)

Sun statement: We have hired a key Python developer, Ted Leung Frank Wierzbicki... We have hired TWO key Python developers - I'll start again. Amongst our Python developers are such key people as..."

Re:Python Developers? (4, Funny)

ricebowl (999467) | more than 6 years ago | (#22634512)

Got my hopes up! I thought you meant John Cleese and Terry Gilliam had new work at Sun...

Have you followed Gilliam's career? Almost everything the guy works on is cursed, usually with multiply-redundant curses in case one of them fails...unless you want Sun to die you don't want him working there. The poor fella.

On the other hand it would be nice to see the giant foot falling from the sky to crush any run-time errors.

Re:Python Developers? (1)

techpawn (969834) | more than 6 years ago | (#22634558)

What would you prefer Michael Palin and Eric Idle? I'm not sure they're any good with Java.

Re:Python Developers? (0)

Anonymous Coward | more than 6 years ago | (#22638036)

It depends how you mean cursed. If you meant brilliantly original and to hell with what the mainstream thinks then yes.

Terry Gilliam is one of my favourite directors.

Re:Python Developers? (1)

rubycodez (864176) | more than 6 years ago | (#22635398)

salesman: 'ow about o'r java desktop running a java virtual machine wi' jython accessin' from a java portal server, that's not got much java in it.

woman: I don't want *any* java!

chorus: jav jav jav jav jav jav jav jav, crufty java, bloated java!

Re:Python Developers? (0)

Anonymous Coward | more than 6 years ago | (#22636016)

John Cleese did work for Sun, back in 2005. He was a "keynote speaker" (read entertainment) for one of their last live NC (Network Computing) events. I think it was NC05Q3.

Re:Python Developers? (3, Funny)

Hythlodaeus (411441) | more than 6 years ago | (#22637658)

No, they're clearly working on the Parrot VM (which is just resting.)

What happened to Tcl? (4, Interesting)

Ed Avis (5917) | more than 6 years ago | (#22634442)

John Ousterhout used to work for Sun and they had a golden opportunity to push Tcl a bit more and integrate it with Java... but they never did much with Tcl and he eventually left. It's a shame, because I rather liked Tcl with its absurdly minimal syntax.

I'm glad he didn't (2, Informative)

Viol8 (599362) | more than 6 years ago | (#22634562)

Tcl with its confused mixture of command line style shell script and C syntax made for a horrid language to both read and code in. IMO the only reason it was ever popular was because Tk was a very advanced GUI toolkit for its day but this isn't 1993 anymore, things have moved on and there are many better solutions

Re:I'm glad he didn't (2, Insightful)

Ed Avis (5917) | more than 6 years ago | (#22634616)

The syntax is not confused: quite the opposite. It is consistent and very minimal. One command per line, lists separated by spaces, "" quotes with variable interpolation, {} quotes without interpolation, [] to call a function, $ gets the value of a variable, and that's pretty much it.

Re:I'm glad he didn't (2, Informative)

Viol8 (599362) | more than 6 years ago | (#22634646)

Perhaps confused was the wrong word. Hard to read would be a better way of putting it, of which the seperation by spaces was the prime cause. Also I remember it being extremely fussy about where you put the procedure delimiters though perhaps they changed that in later versions.

Re:I'm glad he didn't (1)

rockhome (97505) | more than 6 years ago | (#22634880)

How is it harder to read than Python?

At least Tcl isn't as freaky about indentation. Fortran 90 did away with indent-specific formatting.

Re:I'm glad he didn't (1)

jgrahn (181062) | more than 6 years ago | (#22637596)

The syntax is not confused: quite the opposite. It is consistent and very minimal.

That's the problem for me. I prefer a richer (less minimal) language, so that my programs can be minimal.

I have only hacked a single major Tcl program, and it was not enjoyable. It felt like badly designed C code, only with a more verbose syntax ... and no type checking.

Re:I'm glad he didn't (1)

glop (181086) | more than 6 years ago | (#22635060)

Actually, Tk is still cool. Python has Tkinter which is just plain natural, easy and pretty. I remember that Tk in Tcl was just what you describe but the Tkinter binding just gives a pythonic feel (i.e. clean syntax, readable etc.).

I used it the other day for the first time on my EEE PC and it was really easy to write. If I had tried it earlier I would probably have written more GUI code for my scripts in the past 10 years. Hindsight is a wonderful thing...

Tcl is a bit on an anti LISP. In Lisp everything is a function whereas in Tcl everything is a command. This creates an opportunity to increase aspirin sales ;-)

Re:I'm glad he didn't (0)

Anonymous Coward | more than 6 years ago | (#22635936)

"C syntax"? You obviously have Tcl confused with something else.

As for things moving on, Tk has moved on, too. It is quite the modern toolkit what with the ability to do themes and native widgets and whatnot.

The biggest problem Tcl has, IMO, is that its concepts are a bit too advanced for people who are only familiar with traditional languages to grasp. If all you've done is C and visual-whatever languages you've got some unlearning to do before you can really take advantage of Tcl.

Re:What happened to Tcl? (3, Informative)

morgan_greywolf (835522) | more than 6 years ago | (#22634592)

John Ousterhout used to work for Sun and they had a golden opportunity to push Tcl a bit more and integrate it with Java... but they never did much with Tcl and he eventually left. It's a shame, because I rather liked Tcl with its absurdly minimal syntax.
Aside from a few niches (mostly, strangely enough, in the realm of scientific computing), Tcl never quite became very mainstream. Sure, it sits quietly on almost every Linux and BSD distro, and sure there are a few things here and there written Tcl or Tcl/Tk, and almost every seasoned Unix developer knows at least a bit of Tcl, the mainstream audience has been eaten by Python and Perl, for the most part. Probably something to do with that 'absurdly minimal syntax', though I guess that still doesn't explain Perl. ;)

Re:What happened to Tcl? (3, Informative)

Otter (3800) | more than 6 years ago | (#22634748)

There was a time when Tcl/Tk was the least excruciating way of making a simple GUI application on Unix. Once decent toolkits (and, eventually, excellent toolkits) became available, Tcl's main selling point was lost.

Re:What happened to Tcl? (5, Informative)

korbin_dallas (783372) | more than 6 years ago | (#22635252)

Wrong.

Tcl biggest selling point now is the packaging and deployement.

I've written apps in a lot of languages, and deployed them all. Absolutely nothing beats Tcl for cross platform deployments. I got a starkit for ppc405, wrote my app on x86. A simple script packaged it all up in less than 2Mb.
Another few lines, and I had a win32, linux and ppc405 single file executable(for each) ready to go.

We also use java, which requires a separate 20Mb JRE install, whether its in your distro or not, you still need it, and the right version. Oh and Java 1.5 and Java 1.6 jar classes are incompatible, HAHA. And how many of you out there have a JRE for ppc405 (not a Mac, but a older series used in embedded systems)? Tcl is deployed on far more architectures.

The 8.4 and later versions are very fast and lightweight.

Making a gui in Tk is fine and simple, and well, you're gonna make a gui in Tk if you use Perl, Python, Ruby anyway.

All those other tools could learn from the Tcl packaging design.

Re:What happened to Tcl? (1, Informative)

Anonymous Coward | more than 6 years ago | (#22636874)

Oh and Java 1.5 and Java 1.6 jar classes are incompatible
What kind of shit are you on? Jar is, and always has been a .zip file.

So you must mean .class files?

Now please tell me a platform that you take an app written for a new release, and use on an older release without special compiler commands telling it to use the old release, and avoiding all the new stuff. Ohh, wait that is just USING THE FUCKING OLD RELEASE.

No Java 5 shit does not work on Java 1.4. No Windows XP applications don't run on Windows 2000.
But Java 1.4 apps run fine on Java 5, and Java 6. Just like Windows 98 & 2000 apps run on XP. Unless the developer does something fucking retarded like use a private API.

JRE install, whether its in your distro or not, you still need it, and the right version
Did some stupid fuckwit use a private API, I bet they did. Only one thing has been deprecated and REMOVED from the API, that is System.getEnv. It was re-added in the Java 5 as Sun released they fucked up.

I'm not claiming that TCL does not have advantages over Java, such as its smaller runtime and the fact it has been ported all over the place, but please don't just make shit up when you want to bash Java. I know it is hard to bring out the "Java is slow" line anymore as no one believes it, but making up new shit, well it is just low.

Re:What happened to Tcl? (1, Informative)

Anonymous Coward | more than 6 years ago | (#22636930)

"...you're gonna make a gui in Tk if you use Perl, Python, Ruby anyway."

No, I moved on to wxWidgets in my Python. I prefer the platform native look and feel and richer widget set it gives though Tk is (has?) starting to improve in that direction.

Re:What happened to Tcl? (4, Funny)

Bogtha (906264) | more than 6 years ago | (#22634836)

What happened to Tcl? Well judging from the look of it, I'd say it was run over by a car, then hit by a train, then had a nasty encounter with stampeding bison, then got a nasty infection from a facehugger, then beaten up by Ripley and was then promptly nuked from orbit. It's for the best, it was in a great deal of pain and nobody wants to live like that.

Seriously though, that's one ugly language. I always got the impression it's what the inventor of Brainfuck would create if he were actually being serious.

Re:What happened to Tcl? (2, Funny)

foobarbaz (21227) | more than 6 years ago | (#22635230)

What happened was it starting sucking and never stopped.

Re:What happened to Tcl? (1)

ChristTrekker (91442) | more than 6 years ago | (#22635602)

Tcl, good grief... We have people at my company that don't know anything but Tcl, thus we get web apps on our intranet written in it. Angels and ministers of grace, defend us!

Re:What happened to Tcl? (1)

Ed Avis (5917) | more than 6 years ago | (#22635994)

Web apps in Tcl... yes why not [openacs.org] ?

Someone who knows nothing but Tcl, mind you, is likely to be a bad Tcl programmer. This remains true for any value of Tcl.

Re:What happened to Tcl? (1)

blueberry_tx (1247942) | more than 6 years ago | (#22636104)

The problem with TCL is that it is a single pass parser, not a normal expression (recursive descent) parser like other languages. This makes it the programmers job to worry about interpolation. A real pain, getting all the evals right. Just like shell programming, but then I work with people who love KSH, bash, etc. I've never understood that masochistic behavior.

Re:What happened to Tcl? (1)

dwarfking (95773) | more than 6 years ago | (#22635950)

As I heard the story (n-hand so take with a grain of salt), Sun hired Ousterhout because they wanted a language platform they could control and use against Microsoft. However, Ousterhout insisted that TCL remain with its open license.

When Gosling and crew showed off Oak (later Java), Sun realized they had what they needed, a completely home grown system they could own and control.

Java became the favorite child, TCL was ignored (so was SELF, another language Sun was interested in). So Ousterhout left Sun and formed Scriptics.

So basically it was because Sun wasn't allowed dominating control over TCL that they didn't keep backing it.

Disclaimer: I'm a fan of both Java and TCL. I particularly like TCL's Starkit [equi4.com] system of a self contained executable that is drag-and-drop deployable without requiring a runtime install.

Inevitable, and very welcome (4, Insightful)

kripkenstein (913150) | more than 6 years ago | (#22634450)

The only innovation that I credit to Microsoft in all its decades of existence is that of the CLR (.NET) being focused on language-independence, and also on Microsoft pushing hard for projects like IronPython to run well. There is really no reason to have to write language bindings all the time; a library written in one language should be accessible to all others. In the long run, this is going to make whatever platform allows that capability far more competitive. Therefore Sun has no option but to go in this direction, especially given the popularity of dynamic languages in recent years.

Actually FOSS might have done language-interoperation in other ways: given that the source code is available, we might have had automated tools to generate bindings automatically (actually this is happening now, with GObject-introspection, which is relevant so far to C, Vala and Python). But this hasn't happened in an extremely useful way thus far.

Note that this is just one reason for having a single VM for all languages. Security, optimization, etc. are others. In summary, kudos to Sun. Better late than never.

A niggle re:Inevitable, and very welcome (4, Insightful)

davecb (6526) | more than 6 years ago | (#22634534)

Note that this is just one reason for having a single VM for all languages. Security, optimization, etc. are others.

Actually, I'd like to see multiple implementations of a class of (J)VMs, in addition to kripkenstein's point about mutiple languages targeting it/them. This would lead to a rapid shake-out of bugs and disfeatures.

--dave

A VM is just another PLATFORM! (4, Interesting)

StCredZero (169093) | more than 6 years ago | (#22635274)

A VM should just be treated as just another Platform! It's a virtual CPU, and instruction set architecture. Taking this further, a language and a set of libraries packaged with a VM should also be considered a Platform just as Windows XP or Ubuntu 7.10 is a Platform. This is precisely why Java version hell exists! You should not update platforms willy-nilly. You should not take a platform and bundle it with an application! If you are smart, you should either make everything supremely backwards compatible (Windows) or supremely upgradeable (Debian based Linux) or make a clean (and well organized) break that provides dramatic benefits (Mac OS X).

Sun didn't get it. Dot-Net got it because they were able to use hindsight to fill in the gaps where Sun didn't. The truth is, VMs and portable languages don't make operating systems irrelevant. They just (partially) virtualize the OS on top of the native one. The sooner VM language people realize this, and all of the pitfalls, the sooner things will get better! (Many already get things right. Python and Ruby seem to get this.)

A VM is a tradeoff (1)

davecb (6526) | more than 6 years ago | (#22635648)

As StCredZero said, a VM is a platform and a target of development environments.

However, it doesn't need to have a single implementation, any more than the i86 platform does, so I encourage people to create multiple implementations of a given VM ABI and target different languages toward it.

This, like building on different hardware, exposes bugs with great enthusiasm, which fairly rapidly yield code quality and stability, visible as a falling bug rate.

In effect, it's a way to trade more bugs now for fewer later (;-)).

--dave

Re:Inevitable, and very welcome (1)

SolitaryMan (538416) | more than 6 years ago | (#22634574)

Also, I think many people would love to be able to develop small apps for mobile phones using Python. This opens a whole new market for this language! Very welcome change, indeed!

Re:Inevitable, and very welcome (2, Interesting)

Bogtha (906264) | more than 6 years ago | (#22634876)

Actually, Python has been appearing on phones for quite a while, notably Nokia Series 60. I'm not sure, but it might also be possible to use Jython with J2ME devices.

Re:Inevitable, and very welcome (5, Informative)

benjymouse (756774) | more than 6 years ago | (#22634710)

Yes, and Microsofts strong focus on multiple languages from the onset also gives the CLR/DLR some clear advantages over the JVM.

The CLR was built around a the notion of a Common Type System (CTS) which means that different languages can share actual objects without having to wrap them. Wrapping cost performance (wrapping and unwrapping when passing between languages). But wrapping is also inherently language-pair oriented, i.e. between 2 pairs of languages such as Java and Jython. Other dynamic language cannot inherently use Jython objects but must also wrap the "canonical" java objects. It is not that it is impossible to achieve on the JVM platform, it's just that Microsoft has a much more mature VM and type system for this kind of job.

Take Java generics. The JVM type system have no notion of "template" or "generics", hence the generics in Java are implemented through the dreaded type erasure. But that means that no other language (e.g. Scala) can share generic types with Java. Contrast that with the CLR where generics are 1st class type citizens, both in their generic form and when all type parameters has been fully bound.

Interestingly, the CLR/CTS seems to have been developed seperately from (but coordinated with) C#. The CLR type system can actually represent types which you cannot describe using C# or VB.NET. The CTS is "bigger" and more generalized if you will. The Java VM was always just aimed at serving the Java bytecode. This is something that is going to haunt the JVM now when they are going all multi-language and dynamic.

Re:Inevitable, and very welcome (4, Informative)

Headius (5562) | more than 6 years ago | (#22634970)

Generics are basically no help at all to dynamic languages, so I think that's a red herring. And in fact, it makes implementing interop with dynamic languages much more difficult, since it's an additional class of types you have to be able to deal with and recognize. Ask the IronPython and IronRuby guys about the syntax they've had to come up with to support manipulating generics from within Python or Ruby.

The only problem the JVM has, as far as I can see, is that it's got this whole "Java" thing wrapped around it. The JVM itself is much better suited to all sorts of languages, if only we can punch a hole through the Java exterior. And that's exactly what we're going to do, by adding dynamic invocation support in (hopefully) JDK7 and a host of other features like tail calls, tuples, value objects, continuations, and so on in OpenJDK subprojects like the Multi-Language VM.

If anything, the CLR is a much more difficult platform to develop dynamic languages for due to its strict static-typed nature. You have to do some really unpleasant tricks to get the CLR to run a dynamic language fast, and that costs a lot of development time and hassle. DLR hopes to make some of that happen across all languages, but at the end of the day the CLR is just not as advanced a VM as the JVM.

At any rate, it's going to be an interesting couple of years.

Re:Inevitable, and very welcome (1, Informative)

Anonymous Coward | more than 6 years ago | (#22636098)

For the record, Scala interops with Java generics seamlessly in 2.7.0. Just because generics are implemented via erasure doesn't mean the compiler doesn't still insert marker symbols into the bytecode. In fact, without these it would be impossible even for Java to work with its own generic libraries.

Re:Inevitable, and very welcome (1)

neuromancer23 (1122449) | more than 6 years ago | (#22635498)

>> The only innovation that I credit to Microsoft in all its decades of existence is that of the CLR (.NET)

Uhh... Actually they stole that one too. Multiple languages were available for the JVM way before the CLR even existed:

http://www.robert-tolksdorf.de/vmlanguages.html [robert-tolksdorf.de]

Support for multiple languages on the JVM has been around since 5/23/95 (the initial release date of the java platform to the public).

Re:Inevitable, and very welcome (1)

jhines (82154) | more than 6 years ago | (#22635744)

VAX/VMS had this in their libraries, with a clear API, and calling conventions from all languages. One could mix and match languages as needed.

Re:Inevitable, and very welcome (2, Informative)

wuzzeb (216420) | more than 6 years ago | (#22637022)

Actually FOSS might have done language-interoperation in other ways: given that the source code is available, we might have had automated tools to generate bindings automatically

Actually, you should check out SWIG [swig.org] . It has been around since 1995... open source has had automated tools to generate bindings for a long time now. The main problem with this approach is that C does not give enough information. The biggest problem is memory management. most scripting languages are garbage collected, but there is not enough information in C headers for SWIG to know where memory is allocated, and so on.

Essentially, using SWIG comes down to letting SWIG wrap everything just from the headers, except you need to tell SWIG about memory management.... which functions allocate memory that should be garbage collected, which functions take ownership of memory so the object should be removed from garbage collection, and so on....

Re:Inevitable, and very welcome (1)

kripkenstein (913150) | more than 6 years ago | (#22637514)

I'm familiar with SWIG; it's a nice tool. But it isn't as immediate as things can be in a language-independent VM. So while SWIG makes things far easier, it doesn't make things trivial.

Re:Inevitable, and very welcome (1)

rdean400 (322321) | more than 6 years ago | (#22637726)

Actually the JVM was multi-language before Microsoft ever released the CLR. The fact that the CLR had multi-language flexibility as a selling point doesn't change this fact.

Cool! (0)

davecb (6526) | more than 6 years ago | (#22634490)

Can they develop some more of Monty?
I haven't seen anything new from him
for a long time.

--dave

everything, including the sun, came from??? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22634496)

given freely as a gift to man'kind'. let yOUR conscience be yOUR guide. you can be more helpful than you might have imagined. there are still some choices. if they do not suit you, consider the likely results of continuing to follow the corepirate nazi hypenosys story LIEn, whereas anything of relevance is replaced almost instantly with pr ?firm? scriptdead mindphuking propaganda or 'celebrity' trivia 'foam'. meanwhile; don't forget to get a little more oxygen on yOUR brain, & look up in the sky from time to time, starting early in the day. there's lots going on up there.

http://news.yahoo.com/s/ap/20071229/ap_on_sc/ye_climate_records;_ylt=A0WTcVgednZHP2gB9wms0NUE [yahoo.com]
http://news.yahoo.com/s/afp/20080108/ts_alt_afp/ushealthfrancemortality;_ylt=A9G_RngbRIVHsYAAfCas0NUE [yahoo.com]
http://www.nytimes.com/2007/12/31/opinion/31mon1.html?em&ex=1199336400&en=c4b5414371631707&ei=5087%0A [nytimes.com]

is it time to get real yet? A LOT of energy is being squandered in attempts to keep US in the dark. in the end (give or take a few 1000 years), the creators will prevail (world without end, etc...), as it has always been. the process of gaining yOUR release from the current hostage situation may not be what you might think it is. butt of course, most of US don't know, or care what a precarious/fatal situation we're in. for example; the insidious attempts by the felonious corepirate nazi execrable to block the suns' light, interfering with a requirement (sunlight) for us to stay healthy/alive. it's likely not good for yOUR health/memories 'else they'd be bragging about it? we're intending for the whoreabully deceptive (they'll do ANYTHING for a bit more monIE/power) felons to give up/fail even further, in attempting to control the 'weather', as well as a # of other things/events.

http://video.google.com/videosearch?hl=en&q=video+cloud+spraying [google.com]

dictator style micro management has never worked (for very long). it's an illness. tie that with life0cidal aggression & softwar gangster style bullying, & what do we have? a greed/fear/ego based recipe for disaster. meanwhile, you can help to stop the bleeding (loss of life & limb);

http://www.cnn.com/2007/POLITICS/12/28/vermont.banning.bush.ap/index.html [cnn.com]

the bleeding must be stopped before any healing can begin. jailing a couple of corepirate nazi hired goons would send a clear message to the rest of the world from US. any truthful look at the 'scorecard' would reveal that we are a society in decline/deep doo-doo, despite all of the scriptdead pr ?firm? generated drum beating & flag waving propaganda that we are constantly bombarded with. is it time to get real yet? please consider carefully ALL of yOUR other 'options'. the creators will prevail. as it has always been.

corepirate nazi execrable costs outweigh benefits
(Score:-)mynuts won, the king is a fink)
by ourselves on everyday 24/7

as there are no benefits, just more&more death/debt & disruption. fortunately there's an 'army' of light bringers, coming yOUR way. the little ones/innocents must/will be protected. after the big flash, ALL of yOUR imaginary 'borders' may blur a bit? for each of the creators' innocents harmed in any way, there is a debt that must/will be repaid by you/us, as the perpetrators/minions of unprecedented evile, will not be available. 'vote' with (what's left in) yOUR wallet, & by your behaviors. help bring an end to unprecedented evile's manifestation through yOUR owned felonious corepirate nazi glowbull warmongering execrable. some of US should consider ourselves somewhat fortunate to be among those scheduled to survive after the big flash/implementation of the creators' wwwildly popular planet/population rescue initiative/mandate. it's right in the manual, 'world without end', etc.... as we all ?know?, change is inevitable, & denying/ignoring gravity, logic, morality, etc..., is only possible, on a temporary basis. concern about the course of events that will occur should the life0cidal execrable fail to be intervened upon is in order. 'do not be dismayed' (also from the manual). however, it's ok/recommended, to not attempt to live under/accept, fauxking nazi felon greed/fear/ego based pr ?firm? scriptdead mindphuking hypenosys.

consult with/trust in yOUR creators. providing more than enough of everything for everyone (without any distracting/spiritdead personal gain motives), whilst badtolling unprecedented evile, using an unlimited supply of newclear power, since/until forever. see you there?

"If my people, which are called by my name, shall humble themselves, and pray, and seek my face, and turn from their wicked ways; then will I hear from heaven, and will forgive their sin, and will heal their land."

meanwhile, the life0cidal philistines continue on their path of death, debt, & disruption for most of US. gov. bush denies health care for the little ones;

http://www.cnn.com/2007/POLITICS/10/03/bush.veto/index.html [cnn.com]

whilst demanding/extorting billions to paint more targets on the bigger kids;

http://www.cnn.com/2007/POLITICS/12/12/bush.war.funding/index.html [cnn.com]

& pretending that it isn't happening here;

http://www.timesonline.co.uk/tol/news/world/us_and_americas/article3086937.ece [timesonline.co.uk]
all is not lost/forgotten/forgiven

(yOUR elected) president al gore (deciding not to wait for the much anticipated 'lonesome al answers yOUR questions' interview here on /.) continues to attempt to shed some light on yOUR foibles. talk about reverse polarity;

http://www.timesonline.co.uk/tol/news/environment/article3046116.ece [timesonline.co.uk]

Let's take off the 'V' as well! (0)

obstalesgone (1231810) | more than 6 years ago | (#22634498)

JVM? VM? I already have machines that run Java and Python. What do I need a virtual one for?

Re:Let's take off the 'V' as well! (0, Troll)

zdzichu (100333) | more than 6 years ago | (#22634546)

Simple, take one of Azul's Java CPUs [azulsystems.com] .

Re:Let's take off the 'V' as well! (-1, Troll)

Yetihehe (971185) | more than 6 years ago | (#22634560)

You need virtual machines for security. If you for example don't want for one program to be able to spy on another's workings.

Re:Let's take off the 'V' as well! (2, Informative)

Viol8 (599362) | more than 6 years ago | (#22634626)

Eh? What OS you using , DOS 3.2? Thats easily implemented using file permissions and access control. Well , on unix anyway, can't vouch for Windows. If you don't believe me try and strace a running process you don't have permissions for.

Re:Let's take off the 'V' as well! (0)

Anonymous Coward | more than 6 years ago | (#22634694)

Wow, you really know your stuff!

Re:Let's take off the 'V' as well! (2, Informative)

CastrTroy (595695) | more than 6 years ago | (#22634762)

It allows you to specify per-application permissions, without creating a new user for each application. So you can run something as yourself, from your browser, but give it no access to the file system. You could give an application access to the file system, but no access to the network. Running under a VM lets you have a lot more fine-tuned control over what the application can and can't do. It also does it in a way that's completely platform independant. So even if you are using DOS 3.2 (assuming the VM runs on that platform), then the permissions you set, will work.

Re:Let's take off the 'V' as well! (0)

Anonymous Coward | more than 6 years ago | (#22635080)

You still don't need a virtual machine. Under linux, just type:
man 2 ptrace

Ptrace gives you a way to intercept all system-calls, so you can make any process as secure as you want.

Mod parent up (4, Insightful)

Viol8 (599362) | more than 6 years ago | (#22634606)

Indeed. The craze for virtualising runtime code has got way out of hand. Its fine if you want binaries to run unmodified cross platform , but it makes no sense whatsoever for anything else. These days people use Java because of the language and the libraries itself, not the JVM. In fact most java developers I know would be quite happy never to see the JVM again and just use a standard compiler , never mind JIT. I certainly don't understand the reason for using a runtime VM to run executables when a standard binary would suffice , which means I simply don't see the point of .NET either.

Re:Mod parent up (1)

CastrTroy (595695) | more than 6 years ago | (#22634808)

Running under a VM is really nice for debugging purposes. Changing the code in mid-run, and continuing on executing the code saves a lot of time. Also, you can actually rewind from an exception in .Net, fix the problem, and continue on debugging. Running thing's in .Net lets you get a whole lot more information about where your memory is being used, or where the performance bottlenecks are. Some of this stuff is probably possible without a VM, but having a VM adds a lot of features that you simply can perform with regular machine code.

Re:Mod parent up (0)

Anonymous Coward | more than 6 years ago | (#22634812)

Damn, you must be some kind of programming guru!

Re:Mod parent up (0)

Anonymous Coward | more than 6 years ago | (#22634938)

> certainly don't understand the reason for using a runtime VM
> to run executables when a standard binary would suffice

Which is why Vala is so cool.

Re:Mod parent up (4, Insightful)

A beautiful mind (821714) | more than 6 years ago | (#22635306)

Your post is missing the point.

What you refer to as standard binary is just code that can be made to run on the computer directly, because the CPU understands the commands, etc. A VM is the next evolutionary step in the process, because you determine what's the best assembly/native code on runtime, on the fly, instead of static source code inspection.

This means not only more portable code, but overall faster than compiled execution speeds for programs. So far the VMs have been under performing, but they are improving and at a faster rate than gcc and friends.

So yeah, there is more to it than just platform independence.

Re:Mod parent up (1)

Viol8 (599362) | more than 6 years ago | (#22636250)

"A VM is the next evolutionary step in the process, because you determine what's the best assembly/native code on runtime, on the fly, instead of static source code inspection."

If you're moving between different platforms then sure , I already said VMs are useful. But if its on a static machine architecture why bother?

Re:Mod parent up (4, Insightful)

AKAImBatman (238306) | more than 6 years ago | (#22636856)

But if its on a static machine architecture why bother?
Because there's no such thing? The performance paths of a PIV, Core Duo, Xeon, and AMD64 are all different. Should we continue compiling code for the lowest common denominator and just accept that our code isn't performing as well as it could?

And what of runtime optimizations? If the VM detects that this collection only contains objects of type X, it can do away with the casting checks on that collection. Yet if it detects an object of type Y added to the collection, it can undo the optimization on the fly. Statically compiled code can't do that. At best it can provide alternate code paths under certain conditions. Of course, additional code paths massively bloat the executables.

The JVM does these sorts of optimizations today, and thus has unparalleled performance when working with OOP code. That's why all these benchmarks show the JVM kicking ass and taking names later:

http://www.kano.net/javabench/ [kano.net]

A C compiler can still outperform a JVM under ideal conditions, but ideal conditions are becoming more scarce for C compilers. In real-world terms, the JVM is going to be able to run your average Java code far faster than your average C/C++ code.

This idea that native code is always faster than virtualized code is a myth, and an old one at that. You need to get with the times or you'll find yourself a dinosaur. (And you don't really want to be brushing up on your "Get off my lawn!" speech yet, do you? ;-))

VMs won't be the panacea of performance (2, Interesting)

microbox (704317) | more than 6 years ago | (#22636374)

This means not only more portable code, but overall faster than compiled execution speeds for programs. So far the VMs have been under performing, but they are improving and at a faster rate than gcc and friends.

I think the VMs are improving towards the speed of static compliation. Sure there are benefits such that we could potentially see faster VM code - but there's also layers and layers of cruft that comes about because of VM abstractions. I think projects like LLVM will eventually produce code faster than any VM, with architecture independence. The project is comparatively young, and I think it will have a bright future.

The JVM, and CLR kinda symbolise the heavy-weight approach of modern software design. A hello-world xaml application uses 40 megs of memory!

With per-core CPU speeds capping, I'd like to see a more cut-down approach to software development. A brand new computer might by 1000 times faster than a similar product 20 years ago, and it seems we write software that's 1000 times slower. [hubpages.com]

Re:Mod parent up (1)

Just Some Guy (3352) | more than 6 years ago | (#22635752)

I certainly don't understand the reason for using a runtime VM to run executables when a standard binary would suffice

In Python, it is trivially easy to add new methods to a class or module at runtime. The only way to compile such code statically would be to link against a Python compiler that can create the new opcodes from newly-generated source on the fly. At that point, what's the advantage over just using a VM in the first place?

Re:Mod parent up (2, Funny)

mechsoph (716782) | more than 6 years ago | (#22636124)

The only way to compile such code statically would be to link against a Python compiler that can create the new opcodes from newly-generated source on the fly.

And that's what lisp was doing about 25 years ago.

Re:Mod parent up (2, Insightful)

Just Some Guy (3352) | more than 6 years ago | (#22636204)

And that's what lisp was doing about 25 years ago.

Yep. But are there arguments for or against other than "Lisp did it"?

Re:Mod parent up (1)

mechsoph (716782) | more than 6 years ago | (#22636614)

It makes execution a lot faster than bytecode interpreting, and it makes development a lot faster than static (c-style) compilation. So yes, having a native compiler as part of the runtime is a very nice feature. In fact, lisp even lets you do things like implement a natively compiled python [common-lisp.net] without having to do any work on code generation.

Re:Mod parent up (1)

Glock27 (446276) | more than 6 years ago | (#22635810)

Indeed. The craze for virtualising runtime code has got way out of hand. Its fine if you want binaries to run unmodified cross platform , but it makes no sense whatsoever for anything else. These days people use Java because of the language and the libraries itself, not the JVM. In fact most java developers I know would be quite happy never to see the JVM again and just use a standard compiler , never mind JIT. I certainly don't understand the reason for using a runtime VM to run executables when a standard binary would suffice , which means I simply don't see the point of .NET either.

There are some nice things about running on a VM. For one thing, once you've debugged the JIT code generation, you can pretty well prove that large classes of nasty things can't happen. The other argument usually given is that doing JIT compilation presents optimization opportunities not present during static compilation.

The VMs are doing very well, considering that gcj has been under development for a long time as a traditional compiler, and often loses to the Sun JVM in testing. I do think a traditional compiler is the way to go for hard real time stuff, but you also need deterministic GC (or guaranteed no GC during RT operation). The gcj folks should probably implement the RT Java extensions as their next major effort.

I believe Project Harmony was to use a traditional compilation approach. I wonder how things are going there, I'll have to check it out..

Re:Mod parent up (1)

SanityInAnarchy (655584) | more than 6 years ago | (#22635982)

There are four good reasons to run a VM, that I know of:

  1. Reflection. It may be possible with a compiled program, but I've never seen it done, and most VMs make it much easier.
  2. Runtime optimization. Optimizing at runtime means your program can take advantage of knowledge of the actual, running system to optimize itself. Psyco took advantage of this -- it compiled multiple versions of various things (to x86 binary, I might add) and then chose one to run based on the kind of load the program was actually getting.
  3. Faster than interpreting. Take any so-called "scripting" language -- Perl, Python, Ruby, PHP, Visual Basic, JavaScript -- would you really expect a language which supports "eval" to compile to a traditional binary? But they can be compiled to bytecode, which is faster than interpreting them line by line.
  4. Higher-level library calls. Example: If Perl6 and its Parrot VM are ever finished, Python and Ruby programs will be able to use CPAN modules directly, as though they had been written in Python or Ruby. Currently, this kind of thing happens in .NET all the time. And because it's a property of the runtime, it works the same way on any platform.

That's in addition to compile-once, run-anywhere, which is a good thing anyway. In college, for instance, there was one assignment in which we were to write against a library provided by the professor. We were given a jar file, not source code. I was able to develop and test on amd64 Linux and/or ppc OS X, depending which I wanted to use at the time. It was almost certainly graded on a 32-bit x86 Windows XP.

A better question now might be, what's the point of a traditional compiler? Or, why would you prefer one over a VM with JIT?

Re:Mod parent up (1)

Viol8 (599362) | more than 6 years ago | (#22636344)

"2. Runtime optimization."

The last thing I want in a production enviroment is some runtime optimiser fiddling away under the bonnet. I want the binary to be consistant in its operation with no extranious BS going on other than the OS VM system itself. Besides which the optimiser is not going to be able to 2nd guess what the OS is going to do - it might try and optimise some pipeline calc on the fly just for the VM to be swapped out halfway through.

"A better question now might be, what's the point of a traditional compiler? Or, why would you prefer one over a VM with JIT?"

Because I don't see any good reason for having an extra layer between my program and the OS if its not required.

Re:Mod parent up (1)

SanityInAnarchy (655584) | more than 6 years ago | (#22636678)

The last thing I want in a production enviroment is some runtime optimiser fiddling away under the bonnet. I want the binary to be consistant in its operation with no extranious BS going on other than the OS VM system itself.

The thing is, it's very likely that this optimizer is better than you are.

It took me a very long time to understand and embrace this concept. It finally clicked when I read this paper [paulgraham.com] about spamfiltering. Specifically:

The statistical approach is not usually the first one people try when they write spam filters. Most hackers' first instinct is to try to write software that recognizes individual properties of spam. You look at spams and you think, the gall of these guys to try sending me mail that begins "Dear Friend" or has a subject line that's all uppercase and ends in eight exclamation points. I can filter out that stuff with about one line of code....

When I did try statistical analysis, I found immediately that it was much cleverer than I had been. It discovered, of course, that terms like "virtumundo" and "teens" were good indicators of spam. But it also discovered that "per" and "FL" and "ff0000" are good indicators of spam. In fact, "ff0000" (html for bright red) turns out to be as good an indicator of spam as any pornographic term.

I've tried a statistical spamfilter myself, and it works. It's that old principle of, at a certain point, the computer is better at it than you are -- or, at the very least, more reliably better and with so much less effort that you'd have to be insane to do it manually.

A simple example: C code. It compiles to some fairly ugly assembly, yet there are compiler optimization flags that will make it, on average, pretty decent. It's theoretically possible you could write better assembly, but it would take so obscenely much time, and the compiler is already doing it for you, so why bother? You wait until the performance is actually hurting you, and then you find a tight loop, take the smallest part of your program which the compiler didn't do quite as good a job with as you could -- and there, you write assembly.

Besides which the optimiser is not going to be able to 2nd guess what the OS is going to do - it might try and optimise some pipeline calc on the fly just for the VM to be swapped out halfway through.

It might be swapped out anyway. And by the time you're being swapped out, it doesn't really matter how fast you were running. Those few extra cycles spent in runtime optimizations aren't going to be the final straw.

The existence of swap also creates problems for having your program be entirely deterministic in its performance. If you want that, you write in C, probably mostly ASM, and you put it on a Real-Time OS.

Most people don't need things to be that consistent -- it's good enough if it is fast on average. Even things like a game -- computers are fast enough that a garbage collection cycle or a bit of runtime optimization will take place in much less than a single frame or tick.

And you're also assuming that such a VM won't communicate with the OS, or be a part of the OS. Take a look at Microsoft's Singularity [microsoft.com] for an idea of where that might go.

Because I don't see any good reason for having an extra layer between my program and the OS if its not required.

But you give no reason for that preference, other than not liking runtime optimizations.

I see no reason to have an OS at all if it's not required -- let's all write x86 assembly while we're at it! -- but it's certainly a nice thing to have.

Re:Let's take off the 'V' as well! (0)

Anonymous Coward | more than 6 years ago | (#22636160)

You think Python doesn't run on a virtual machine too?

2008 - the year of the VM shootout (2, Funny)

A beautiful mind (821714) | more than 6 years ago | (#22634508)

I guess we'll see which is better, Python's native, (J)VM or Parrot.

Re:2008 - the year of the VM shootout (1)

Constantine XVI (880691) | more than 6 years ago | (#22634992)

You forgot the .NET CLR (IronPython)

DLR (1)

drewness (85694) | more than 6 years ago | (#22637140)

IronPython runs on the .NET DLR (Dynamic Language Runtime), which is on top of the CLR. The DLR does dynamic types and dynamic dispatch, unlike the CLR. Apparently the DLR code lives in the IronPython tree for the moment, but when IronPython 2.0 is ready they're going to integrate and release the DLR into .NET along with a couple other dynamic languages.

Re:2008 - the year of the VM shootout (1)

TheLink (130905) | more than 6 years ago | (#22637294)

But parrot is dead! ;)

Re:2008 - the year of the VM shootout (0)

Anonymous Coward | more than 6 years ago | (#22637442)

I've got my money on Python running as JavaScript [codespeak.net] winning the performance crown. :-)

Nothing New... 12 years later (1)

mlwmohawk (801821) | more than 6 years ago | (#22634552)

In 1995~1996 I was working at a medical imaging company and we were exploring the idea of using Java and its about to be announced graphics interface to be the basis of our new computerized viewers. This was in the time frame of the DEC Shark, a strong ARM based thin client, and Sun's HotJava browser.

Anyway, Sun has been harping about how the "JVM" could support multiple languages. They talked about Basic and fortran, I guess with M$ pushing C# and C++ on the JVM. Java can finally justify the multi-language aspect of their VM.

Re:Nothing New... 12 years later (4, Informative)

TheRaven64 (641858) | more than 6 years ago | (#22634742)

As someone who tried to get a Smalltalk compiler to target the JVM, I can say from experience that it is a really horrible design (and .NET copied all of the worst design decisions). The VM imposes so many constraints that it's really hard to implement anything that isn't semantically almost identical to Java on it without seriously compromising the speed. A far better approach is LLVM, which allows you to layer things like garbage collection and object models on top of a common VM.

Re:Nothing New... 12 years later (4, Insightful)

Headius (5562) | more than 6 years ago | (#22634910)

It's difficult, but it's certainly not impossible. And we're working to make it easier by exposing the JVM's underpinnings. You see, the JVM is already a dynamic language VM; it just has this cumbersome static-typing wrapped around it.

Re:Nothing New... 12 years later (2, Informative)

TheRaven64 (641858) | more than 6 years ago | (#22635304)

Exactly my point. Unless your type system and dispatch semantics closely match Java, you need trampoline objects which make everything horribly slow. The dynamic call primitives in the latest proposal go a long way towards this, but there is still not enough runtime type introspection for a lot of neat language features.

wow; parrot has had an impact. (2, Interesting)

WindBourne (631190) | more than 6 years ago | (#22634572)

The only reason why Sun would hire them, now, is if they were concerned about parrot splitting the market.

Re:wow; parrot has had an impact. (5, Funny)

techpawn (969834) | more than 6 years ago | (#22634610)

is if they were concerned about parrot splitting the market.
They're pythons! The parrot's dead... 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies!'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!! 'E f-in' stuffed it!

Re:wow; parrot has had an impact. (2, Informative)

handmedowns (628517) | more than 6 years ago | (#22635026)

Actually the reason Sun hired them is they've made a commitment to get Glassfish http://glassfish.dev.java.net/ [java.net] running other higher level languages besides Ruby. So now they've got some jruby developers and jython developers. They're really trying to push their appserver platform, and with the acquisition of MySQL, they have a complete stack under their roof (SunOneWeb, Glassfish, MySQL) not to mention, OpenDS, OpenSSO, Metro, among other things.

Sun is going after the ruby and python developers because they're diversifying. Sun's biggest software competitor is IBM which directly or indirectly controls all of its products and their dependencies.

Re:wow; parrot has had an impact. (0)

Anonymous Coward | more than 6 years ago | (#22635506)

not to mention, OpenDS,
In case you hadn't heard, Sun gave the OpenDS team the boot.

Open Letter [wordpress.com]

Re:wow; parrot has had an impact. (4, Informative)

Otter (3800) | more than 6 years ago | (#22635166)

Basically, Leung lost his job, posted [sauria.com] on his blog that he was looking, someone at Sun read it and they made him an offer. I don't think this whole thing is nearly as elaborately crafted a strategy as people are making out.

Re:wow; parrot has had an impact. (1)

Sprout (26700) | more than 6 years ago | (#22637886)

Sun had been thinking about doing this for some time. My becoming available was a reason to go from thinking to acting. There will likely be other dynamic language work happening at Sun, not just Ruby and Python.

- Ted Leung

Re:wow; parrot has had an impact. (2, Funny)

fahrbot-bot (874524) | more than 6 years ago | (#22637044)

The only reason why Sun would hire them, now, ...

Actually it's because, with the current economic decline, Sun can no longer afford to hire Perl programmers... :-)

It's.... (1)

wildzeke (191754) | more than 6 years ago | (#22634600)

Cue music.

too little too late (0)

nguy (1207026) | more than 6 years ago | (#22634602)

I think Sun missed the boat on dynamic languages. For years, they had a Java-only policy for the JVM.

At this point, there are more useful libraries and tools for C Python than there are for Java. Sun's new found love for Ruby, Groovy, Bsh, and Jython mainly seems to stem from the realization that "pure" Java just didn't work out.

Re:too little too late (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22634722)

Ha, ha....when I see comments like these I am laughing so hard it hurts.

Java didn't work out??? Which universe do you live in?

We have a whole team of Java devs here, earning good salaries, working on interesting projects, being able to afford homes, cars, plasma TVs, etc. We're a multi-billion $$$ company

Number of Python / Ruby / Tcl developers employed here: 0. ZERO. Not one. NADA.

So, Java not working out, eh? Young boy, get some some education before you start spewing rubbish like this.

Re:too little too late (0)

Anonymous Coward | more than 6 years ago | (#22635302)

I think you missed the point. Sun ran for the longest time under the mindset that Java was the only programming language you will ever need. That it will be able to do everything and anything. Incorporating other languages and dropping the "J" from "JVM" is showing that they are finally acknowledging what everyone else has been harping on and have known for years.

Yes we are all fully aware that Java is the most popular language in use and that many developers make a living off the language. Although, if you are a multi-billion dollar company and do not have at least one fellow using Python in your org...that's a bit odd. I would make a good guess that you might not know your organization as well as you think.

Re:too little too late (0)

Anonymous Coward | more than 6 years ago | (#22635954)

Sure, maybe there is some junior doing some scripts in some little cubicle somewhere.

But every day 99% of our senior guys are focused on things such as ActiveMQ, OSGi, RCP, J2EE, Java EE 5.

You know, real stuff...the one corporations really use when they need to pull in a project involving 50 developers that will serve hundreds or thousands of users.

Not some little HelloWorld app with 3 script file that a kid puts together in Notepad and thinks he's a programmer now.

Re:too little too late (0)

Anonymous Coward | more than 6 years ago | (#22637116)

Can I live in your world too?

Well come for a holiday.

Sun has for some time said that other languages could play on its VM.

Alas its VM was not designed well for other languages.

Re:too little too late (4, Informative)

Headius (5562) | more than 6 years ago | (#22635008)

You're probably half right. I think it stems from a realization that Java doesn't have to be the only tool on the JVM. And to that end, we're working hard to improve the ecosystem for language development in a number of ways. Heck, some of the most interesting parts of JRuby aren't even written in Java anymore...they're generated programmatically. Java is just one way to create JVM bytecode. We need both better tools for creating bytecode for many languages, and a better way to make the JVM's dynamic underpinnings serve many languages. We're working on both.

Re:too little too late (1)

nguy (1207026) | more than 6 years ago | (#22635356)

well, yes, Sun realized that. But I realized a few years ago that I don't really need a JVM anymore. If I want safe code, I write it in Python. if I want speed, I write in Pyrex or C.

jVM+Jython+C just doesn't look compelling to me compared to Python+C, in particular since Jython lacks a lot of important Python libraries. And I don't see Sun catching upwithn two devs.

Re:too little too late (1)

BotnetZombie (1174935) | more than 6 years ago | (#22635016)

Missed the boat is perhaps too harsh - but they're definately late to it. All the same, people have been successfully using jython and jruby for some time now, even though many experience some integration problems. Speaking for myself, 3-4 years of using jython has been mostly a joy, but not completely painless.

Um, not just Jython (4, Informative)

tbray (95102) | more than 6 years ago | (#22634702)

Well, no, if you check Ted's blog [sauria.com] , you'll see that he's going to be working on Python-in-general, not just Jython.

VM Craze (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22634740)

There is a simple reason behind the JVM push or 'craze'. Good programmers are hard to find , difficult to retain, and worth their weight in gold.

So instead of finding those good programmers, why not develop a programming language that shields the programmer from themselves, and allows us to hire lots of cheap, low skilled mediocre programmers. Enter Java.

Don't worry about complex things, like overloading, algorithms, memory management, let java do it for you.

The entry level programmers can crank out huge mounds of steaming code in record time.

they don't have to worry about destroying the OS, overwriting pointers, null pointers, etc, because the virtual machine will shield them from all that.

There is still a core group of very good programmers, all being used to write more and more virtual machines, so the mediocre programmers have something to use.

Scripting? (1)

Intron (870560) | more than 6 years ago | (#22635236)

This must be some new java of which I am unaware.

Virtualization (0)

Anonymous Coward | more than 6 years ago | (#22635258)

I don't understand the whole software virtualization craze. Modern CPU's already have silicon dedicated to keeping programs and memory seperate.

Silicon can generally do anything software does, but 1000x faster.

Why devote all this energy to helping make programming simpler, at the cost of speed?

Java is great for say 'presentation' apps, that need a quick and dirty interface.

Try to do anything large with it, and the performance drags down.

Sometimes, you just HAVE to use more than a few hundred megs of RAM, and the overhead of the VM just kills performance.

Better stick with C/C++.

To the fools thinking Java didn't make it... (0)

Anonymous Coward | more than 6 years ago | (#22635328)

Java is really two things: Java the language and Java the VM.

And even tough I find that Java-the-language has many warts (bring me Scala [another interesting language targetting the JVM] with DbC and I switch asap), I does many real-world jobs.

And what about Java-the-VM? Best thing that happened to computing these last 20 years... Not a single buffer overflow in the VM since it exist (there have been buffer overflows in 3rd party C-written lib that the JVM depended upon). The VM is bullet-proof by design. A buffer overflow would be due to an implementation error in one of the VM, not in the VM technology design. The VM is simply immune to buffer overflows.

Re-read this. A thousand times: no buffer-overflows. 99% of the security issues plaguing programs written in other languages simply can't happen when you're running your program under the JVM. Last serious issue I remember affecting me was in a 3rd party, C-written, lib (zlib). Funny uh?

Speaking of security... You realize you can install the whole friggin' JVM in a user account on Un*x? No need to be root. (Last time I checked for whatever reason this was impossible under Windows, but I bet it's more Microsoft's fault than Sun's). You can install a whole f*cking JVM without needing to be root... Wild.

Well, that's just one thing, of course you get lots of pretty tools that can connect to these shiny VMs: remote profiling anyone? I mean, really, what does your language offer you? Can I easily turn on and off remote profiling of running apps written in your favorite language? Really? How easy is it?

And now think for a second: how easy would it become if suddenly your language, instead of being clumsy and hard to debug remotely, hard to profile remotely, prone to buffer-overflows, etc. was targetting an industrial grade JVM?

You start to get it? You start to understand why you are still in the stone age and others have seen the light? (Scala, for example, is an impressive 'functional OO language' that targets the JVM).

The next-big-language-that-will-be (TM) will target a bullet proof of VM or it will not be.

So back to the point: there are still fools today that think that 'Java is dead', or that 'Java didn't cut it' or, pathetically, that 'Java is slow' (these trolls needs to be hit with a cluestick)...

Well, I've got some news for you: every non-cash money transaction involves Java in the process at one point or another, Java powers most of the world's biggest sites (eBay, GMail, FedEx, ... Do I really need to list 99% of the most visited sites?), you cannot buy a Blu-Ray player without having a JVM (it's part of the Blu-Ray specs), there are entire countries where people carry Java SmartCards in their pockets (as an ID or for health care).

Talking of GMail, what does Google think of Java? That it's so convenient they want you to use that instead of messing with ugly EcmaScript for AJAXy-like development (GWT anyone? Allo? You code this using Java). Android? Want to develop apps for Android-powered phones? Better learn Java dude. The JVM concept is so sound that Google even wrote their own JVM (Dalvik... It's not called Java to bypass trademark issues, nice job Google ;)

95% of all cellphones out there have a JVM too, btw...

At the (major) bank I'm working for, we just ported a complex application to Java: tens of PCs doing Monte Carlo simulations at night. Speed? Exactly the same has what we had before (we did tests before porting the app... I knew we'd get exactly the same perfs, but some dumbass reading lame comments everywhere about 'Java-being-slow' wanted to be sure). Now we get faster development time.

Most criticism I read about the JVM is the same old song from the 90's. Yup, Java was a pain in the a*se on Linux in the 90's. Times have changed.

All the people saying that 'Java didn't make it' are fooling themselves. Wake up. Java is the biggest language success story in this industry since the last 20 years. Not only it's not changing anytime soon but moreover your cellphone, your Blu-Ray player, your various appliances, your bank, most sites you visit, says to you: "you don't like Java dude? Better get use to it".

Re:To the fools thinking Java didn't make it... (0)

Anonymous Coward | more than 6 years ago | (#22635406)

Why do you keep modding down every java advocate? Can you at least argue with them? Or is there only one proper way of doing things? Meh. I'm posting as AC to avoid an angry mob of dynamic lagnuages zealots.

Re:To the fools thinking Java didn't make it... (0, Flamebait)

SanityInAnarchy (655584) | more than 6 years ago | (#22636440)

And what about Java-the-VM? Best thing that happened to computing these last 20 years...

Without checking, I'll bet you $10 that Sun didn't invent the concept of a VM.

Not a single buffer overflow in the VM since it exist

You don't need a VM to do that.

I mean, really, what does your language offer you? Can I easily turn on and off remote profiling of running apps written in your favorite language? Really? How easy is it?

Depends on the app, but I think Ruby Waves [rubywaves.com] will do that and more.

Can you run "eval" in Java? Can you open existing classes and monkeypatch them, tweak them to your bidding?

So back to the point: there are still fools today that think that 'Java is dead', or that 'Java didn't cut it' or, pathetically, that 'Java is slow' (these trolls needs to be hit with a cluestick)...

Actually, I think that .NET is a better Java than Java. And I hate Microsoft, too, but those are the facts.

Well, I've got some news for you: <inane rambling list of things Java is run in>

By that logic, C must be the fucking grail!

you cannot buy a Blu-Ray player without having a JVM (it's part of the Blu-Ray specs)

Part of a certain version of the specs. I'm fairly sure there were early players which did not have a JVM. The one that Blu-Ray does have is not anywhere near a full-fledged desktop JVM.

Talking of GMail, what does Google think of Java? That it's so convenient they want you to use that instead of messing with ugly EcmaScript for AJAXy-like development

Wow. Between EcmaScript and Java, I'll take EcmaScript every time. The fact that you choose Java tells me that either you are a fan of static typing, or you have no idea just how powerful EcmaScript is. (I'll give you a hint -- the guy who invented it wanted to do a LISP interpreter, but his boss told him to write some C-like script. So he wrote a LISP interpreter with C-like syntax -- and that is EcmaScript.)

I should also mention: I worked on HD-DVD. Anyone I talked to about it who had worked with both said they preferred working with HD-DVD. I wonder why that is?

I will say that aside from the storage/bandwidth issue, HD-DVD was ahead technologically for most of the race. (That said, as a user, I mostly just want to watch the movie, so more storage and bandwidth makes a lot of sense.)

GWT anyone?

Yeah, I hate it.

GWT depends on browser identification. It actually serves you an entirely different script based on which browser you're running. If it doesn't recognize your browser, it serves you a non-AJAX version.

In my mind, that is broken by design, yet many people consider it to be a feature. And because of this broken design, I have to keep a Firefox window open for no reason other than to run my Google Apps.

most sites you visit

Excuse me? Are you kidding me?

The top two languages, according to a casual Google search, are PHP and ASP, in that order. So Java is at best third, unless we can find some actual statistics to pin it on. The only sites I ever notice a JSP page on are various corporate websites which are basically HTML brochures. The only site I actually use that I know is running Java is Gmail.

Now, if you're wondering why you got modded down, let me take you on a brief tour:

Re-read this. A thousand times: no buffer-overflows.

Quoted in a context where it's actually inaccurate, yet you're arrogant enough to insult our intelligence.

You can install a whole f*cking JVM without needing to be root... Wild.

Well, f*cking amazing! I can do that with really any language I can think of. I also don't see what this has to do with the other security point you were discussing -- but you had to drop the f-bomb. I'm glad you think this language is so hardcore EXTREME, but tone it down a bit. Your tone is ridiculous:

And now think for a second: how easy would it become if suddenly your language, instead of being clumsy and hard to debug remotely

Mine's actually pretty easy to debug remotely, yet you make assumptions about it.

You start to get it? You start to understand why you are still in the stone age and others have seen the light?

And seriously, you wonder why you were modded down?

I think that about sums it up. When you write a post with the tone of "I am right and the entire Industry is wrong" [thedailywtf.com] , filled with pointless profanity and actually insulting the intelligence of anyone who doesn't agree with you -- that is a post which is begging and screaming to be modded troll -- or at least, flamebait.

Come back when you can carry on a grown-up conversation.

Parrot? (1)

kbahey (102895) | more than 6 years ago | (#22635538)

This seems to overlap/compete with Parrot [parrotcode.org] . Of course Sun are expected to promote their own JVM. I don't see Perl going JVM though.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>