Slashdot Mirror

I think Parrot is a good candidate for that purpose but I think we're going to be waiting for a while longer yet.

[Python and Ruby] make releases like clockwork...

Rakudo (Perl 6 on Parrot) is part of the monthly Parrot release cycle. We've released a new stable version of Rakudo with Parrot every month since November 2006 -- including a new version yesterday.

Maybe Parrot would fit your wishes? Once it is finished.

I wholeheartedly agree with Brendan that we should at any cost stop JavaScript in particulat and Ecmascript in general from being as painful as Java in any way possible. However what we should do is not only improving all of the ECMA-262 derivatives but to make a systematical progress towards better flexibility and interoperability of various scripting approaches in the future. Take for example the wonderful project by Mehmet Yavuz Selim Soyturk called PJS which is an important step in the direction to allow the Parrot virtual machine, designed to run Perl, Tcl, Javascript, Ruby, Lua, Scheme, Befunge, Lisp, PHP, Python, Perl 6, APL, Java, .NET, et al., to run on JavaScript, so all of those languages could be used together to enhance your browsing experience on the Web. For this to be even remotely plausible the JavaScript must be as flexible and as fast as possible because it would basically mean running high-level language code compiled to the Parrot intermediate representation (PIR, or IMC), that converted to the Parrot assembly language, assembled, linked, converted to Parrot bytecode and then execuded on the Parrot virtual machine or PVM which would itself be a large JavaScript interpreted script running in a Web browser, running in the operating system... You get the picture. A logical step forward would be to include PVM in all of the major browsers to run the Parrot bytecode natively and efficiently in the browser. There are already plans to include PVM interpreter in Firefox which means it will be available as a viable target for scriping dynamic html pages for all of its derivatives like Camino, Galeon and Konqueror. Hopefully the commercial browsers would follow (the Artistic license is not anti-commercial like GPL so there should be no legal problems with the integration). I really look forward to the future of perfect interoperability when every single Web page could potentially run scripts written in literally dozens of programming languages simultaneously. One day we will experience that synergy thanks to people like Brendan Eich,Mehmet Yavuz Selim Soyturk, Larry Wall, et al. if they only agree to work together on one common solution to the big mess of Web scripts that we have today. Let's all hope they will.

With there finally being a nice Javascript implementation that cleanly and efficiently sends to bytecode, I'm wondering if the dynamically-typed-specs in the Parrotcode project could be of some assistance. The ECMAscript implementation they're already working on still has a long way to go, and this would be one way to help consolidate development efforts -- plus get some additional motivation behind both projects.

That was Coverity. We've found the results very useful for Parrot. You have to be smart about how you interpret the results and how you fix actual bugs, but their tools did reveal many dubious constructs and actual bugs.

The web development landscape is changing, document based storage (eg: couchDB) will change the way we architect web apps. Frameworks and memcached are more like stopgap solutions, no language suitable for web development really needs a framework. A class loader and a well designed templating system are a mornings work -- frameworks only add unnecessary bloat and convoluted APIs.

Considering the web (unfortunately) runs on PHP and Google are offering Python, I'd say Microsoft can sleep soundly while they crank out their copycat^w"innovative" .NET version. Personally I'd prefer Java to Python but the ideal would be parrot with decent langauge support (Microsoft already have their DLR).

As for the privacy concerns, sure that's a big issue. OTOH, I trust Google far more than I trust Microsoft.

This seems to overlap/compete with Parrot. Of course Sun are expected to promote their own JVM. I don't see Perl going JVM though.

I'm very happy to see something productive out of the Parrot community. They've promised some great things, and we've been waiting a long time to use their offerings. Some people in the community (see article below) have started to doubt the Parrot project's usefulness, but maybe this cool Perl6 development will make them re-think their stance.

Will Parrot ever truly deliver? (http://pinderkent.blogsavy.com/archives/124)

Earlier today I was reading an article about Parrot. Parrot is, as stated on the projects Web site, a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.

So Parrot does sound like an interesting piece of technology. Its understandable how a common runtime for scripting languages could prove beneficial. But will it ever be a platform suitable for serious, production usage? I have my doubts.

Parrot has been under active development for quite some time now. The initial 0.0.1 release was made on September 10, 2001. During 2007, weve seen a release every month or so. So a lot of effort has been put into Parrot over the past six years. It has surpassed one of the major stumbling blocks with many Open Source projects, in that it has managed to build at least some development momentum. Unfortunately for its supporters, Parrot has never really seemed to catch on. I think there are a number of reasons for this.

Stability is probably the first problem. I dont mean stability in terms of the runtime crashing, or anything of that sort. Im talking about concept stability. There has always seemed to be a relatively large amount of change between releases. While this is good, in that there are improvements being made and new ideas being implemented, this causes problems for users who want to build reliably upon Parrot. Individuals and businesses often do not, or cannot, invest the time and effort to track a continually-moving target like Parrot.

The language implementations for Parrot, while many in number, have been of limited use. Looking at the status messages of some of the most promising and practical language implementations shows why this might be the case. Such messages include:

• Incomplete - but all examples and test cases are working. (Amber for Parrot)
• Most of the samples work. (BASIC/compiler)
• Has been broken for a long time. (BASIC/interpreter)
• Parser is pretty complete. Generates PIR for basic Ruby programs (Cardinal, Ruby CVS Head 1.9 implementation)
• Functioning, all samples working, lacks IO routines (Cola)
• Working for some simple forms. Due to some broken features, most of the bootstrapping code has been commented out. (Common Lisp)
• Functioning for handcrafted test cases. Loading frozen state is currently broken. Far from complete. (Parrot m4)
• This project has been abandoned. Any takers? (Pint, an experimental PHP implementation)
• Passes nearly 25% of tcls (lightly converted) test suite, using a Test::More like harness. (Tcl)

So while there are many interesting language implementation projects for smaller or more obscure languages that have reached further stages of completion, the ones that were most likely to be of practical use seem to be lacking. Now, this is understandable. Maintaining a suitably complete Ruby, Python, Perl or Tcl implementati

I'm very happy to see something productive out of the Parrot community. They've promised some great things, and we've been waiting a long time to use their offerings. Some people in the community (see article below) have started to doubt the Parrot project's usefulness, but maybe this cool Perl6 development will make them re-think their stance.

Will Parrot ever truly deliver? (http://pinderkent.blogsavy.com/archives/124)

Earlier today I was reading an article about Parrot. Parrot is, as stated on the projects Web site, a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.

So Parrot does sound like an interesting piece of technology. Its understandable how a common runtime for scripting languages could prove beneficial. But will it ever be a platform suitable for serious, production usage? I have my doubts.

Parrot has been under active development for quite some time now. The initial 0.0.1 release was made on September 10, 2001. During 2007, weve seen a release every month or so. So a lot of effort has been put into Parrot over the past six years. It has surpassed one of the major stumbling blocks with many Open Source projects, in that it has managed to build at least some development momentum. Unfortunately for its supporters, Parrot has never really seemed to catch on. I think there are a number of reasons for this.

Stability is probably the first problem. I dont mean stability in terms of the runtime crashing, or anything of that sort. Im talking about concept stability. There has always seemed to be a relatively large amount of change between releases. While this is good, in that there are improvements being made and new ideas being implemented, this causes problems for users who want to build reliably upon Parrot. Individuals and businesses often do not, or cannot, invest the time and effort to track a continually-moving target like Parrot.

The language implementations for Parrot, while many in number, have been of limited use. Looking at the status messages of some of the most promising and practical language implementations shows why this might be the case. Such messages include:

• Incomplete - but all examples and test cases are working. (Amber for Parrot)
• Most of the samples work. (BASIC/compiler)
• Has been broken for a long time. (BASIC/interpreter)
• Parser is pretty complete. Generates PIR for basic Ruby programs (Cardinal, Ruby CVS Head 1.9 implementation)
• Functioning, all samples working, lacks IO routines (Cola)
• Working for some simple forms. Due to some broken features, most of the bootstrapping code has been commented out. (Common Lisp)
• Functioning for handcrafted test cases. Loading frozen state is currently broken. Far from complete. (Parrot m4)
• This project has been abandoned. Any takers? (Pint, an experimental PHP implementation)
• Passes nearly 25% of tcls (lightly converted) test suite, using a Test::More like harness. (Tcl)

So while there are many interesting language implementation projects for smaller or more obscure languages that have reached further stages of completion, the ones that were most likely to be of practical use seem to be lacking. Now, this is understandable. Maintaining a suitably complete Ruby, Python, Perl or Tcl implementati

I'm very happy to see something productive out of the Parrot community. They've promised some great things, and we've been waiting a long time to use their offerings. Some people in the community (see article below) have started to doubt the Parrot project's usefulness, but maybe this cool Perl6 development will make them re-think their stance.

Will Parrot ever truly deliver? (http://pinderkent.blogsavy.com/archives/124)

Earlier today I was reading an article about Parrot. Parrot is, as stated on the projects Web site, a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.

So Parrot does sound like an interesting piece of technology. Its understandable how a common runtime for scripting languages could prove beneficial. But will it ever be a platform suitable for serious, production usage? I have my doubts.

Parrot has been under active development for quite some time now. The initial 0.0.1 release was made on September 10, 2001. During 2007, weve seen a release every month or so. So a lot of effort has been put into Parrot over the past six years. It has surpassed one of the major stumbling blocks with many Open Source projects, in that it has managed to build at least some development momentum. Unfortunately for its supporters, Parrot has never really seemed to catch on. I think there are a number of reasons for this.

Stability is probably the first problem. I dont mean stability in terms of the runtime crashing, or anything of that sort. Im talking about concept stability. There has always seemed to be a relatively large amount of change between releases. While this is good, in that there are improvements being made and new ideas being implemented, this causes problems for users who want to build reliably upon Parrot. Individuals and businesses often do not, or cannot, invest the time and effort to track a continually-moving target like Parrot.

The language implementations for Parrot, while many in number, have been of limited use. Looking at the status messages of some of the most promising and practical language implementations shows why this might be the case. Such messages include:

• Incomplete - but all examples and test cases are working. (Amber for Parrot)
• Most of the samples work. (BASIC/compiler)
• Has been broken for a long time. (BASIC/interpreter)
• Parser is pretty complete. Generates PIR for basic Ruby programs (Cardinal, Ruby CVS Head 1.9 implementation)
• Functioning, all samples working, lacks IO routines (Cola)
• Working for some simple forms. Due to some broken features, most of the bootstrapping code has been commented out. (Common Lisp)
• Functioning for handcrafted test cases. Loading frozen state is currently broken. Far from complete. (Parrot m4)
• This project has been abandoned. Any takers? (Pint, an experimental PHP implementation)
• Passes nearly 25% of tcls (lightly converted) test suite, using a Test::More like harness. (Tcl)

So while there are many interesting language implementation projects for smaller or more obscure languages that have reached further stages of completion, the ones that were most likely to be of practical use seem to be lacking. Now, this is understandable. Maintaining a suitably complete Ruby, Python, Perl or Tcl implementati

Bah! See, I answer my own questions. how to make native calls.

I love perl. Everything is documented, you just have to know where to look :-)

And to answer some of my questions... here is the FM. The docs actually define a bit about how namespaces (should?) work as well as other things I left out on my list like threading.

The specific niche for Parrot is as a VM for a register machine which works well with dynamic languages. Java is a very statically typed language, and the JVM is written to suit that (and I believe it's a stack machine, but don't quote me on that). Forth is a stack machine. CLR is a stack machine and mostly suited to statically typed languages.

Plus, Parrot and Perl6 aren't as tightly bound together as some may think. Perl6 runs on Pugs, which is written in Haskell. It's going to run on Parrot. It should also run on the JVM and CLR, but probably not as well as on Parrot. It may even run on top of Neko some day, as there's been talk of targeting that VM. It'll also be able to be compiled down to machine language, which is quite difficult to do with Perl5.

Parrot can be the target for more than Perl6. As Parrot is written and refined, several language implementations are being written and refined along with it as test cases. This helps iron out edge cases and corner cases, and helps drive the selection of features necessary to properly support those languages without a lot of extra fluff.

ABC, Tcl, brainfuck (called "bf"), a subset of Python, a subset of PHP, APL, a C compiler, Ruby, a subset of Common Lisp, a .Net to PIR translator, a couple of Scheme implementations, a Forth interpreter, Lua, Perl5, an Infocom ZMachine, and more are in different states of readiness at the moment. The goal is to standardize how to implement dynamic languages on Parrot and to standardize how to call into and out of languages on Parrot. Those will allow Perl6 and other languages to interact more cleanly than is possible with Perl5. Two languages implemented on Parrot will even be able to call subroutines written in each other.

ParrotCode has far more information about the Parrot project.

Good grief, ever hear of Pirate (Python to Parrot compiler)? partcl (tcl to parrot)? Git yo azz ovah to parrotcode an edumacate yo-self! most of Perl 6 is runnable by Pugs, which can compile Perl 6 into Haskell, Javascript or Perl 5. Now I'm a Perl 6 detractor in that I mock the way Larry can't resist throwing in every shiny thing he sees in other languages, he should have got focused and finished years ago. But I still follow the news so I must care in same way relative cares about some distant member of the family destroying their life with a drug habit. Parrot has many cool ideas in and of itself, educational to study it

Up until the last year or two, there wasn't much progress (or at least *visible* progress) on Perl 6. If you look now though, there's a fair bit of tangible work being completed, e.g. Parrot 0.5 was just released, along with the Parrot Roadmap.

As with many OSS projects, the main impediment at the moment is not having enough man hours available to complete the work. But I think it's fairly obvious it's not complete vapourware.

If Perl 6 does everything it says it will, and happens to get it's timing right, it could be huge. It might be the first OSS language to take the sort of status the Java has now, and COBOL used to have. Or it could be of little use to anyone. As I said earlier, I don't think anyone really knows.

By the time Perl6 gets out, if it ever does, nobody will care about it because the open source market will be dominated by Mono.

Not everyone wants to suckle at the teat of Microsoft hanging out of a Novell uniform.

At this rate, the perl crew might be better served by just compiling down to MSIL and leveraging Mono for cross-language compilation.

Ideas are cheap. Let's see your code. You can find my Perl 6 code all over the Internet. Start with Parrot.

I think "scripting language" refers to the idea that what you write in the program happens in that order.

I don't understand what you mean by this. All of these languages have flow control.

That's not like C or Java, when what happens when the program runs is what is inside the main function (or static method). And that happens only after you turned your text file into something else.

PIR on Parrot runs what's inside the function annotated as :main, but it does so whether the file is text or processed bytecode. Besides that, I could write a C or Java interpreter if I really wanted to which could work on source code.

What? No. There are no limitations in the C implementation of the Python 2 runtime environment that are not also in the C implementation of the Perl 5 runtime environment. Both of the languages have a lot of similar characteristics. Both were developed at around the same time, with Perl starting a few years earlier. Perl 4 came out in 1991, Perl 5 in 1993, Python 1 came out in 1994.

The "Perl engine" only runs Perl code. It does not run any other languages.

You can run Python from within Perl though using both runtimes:

http://search.cpan.org/~neilw/Inline-Python-0.20/Python.pod

And perhaps one day you can run both scripts interchangeably if Parrot achieves is goals:

http://www.parrotcode.org/

In the meantime, if you want to write in a dynamic language you can run Python in the JVM or IronPython in the CLR. Then you can use a single runtime to call into Java or C# or Javascript or Ruby or VisualBasic. You can not do this with Perl 5, it is extremely unlikely that Perl 5 will every be supported outside of it's single C implementation. These limitations in the Perl 5 runtime are why your Perl community has been doing a from-scratch rewrite of Perl these last 7 years or so ...

I happen to think that Python and Ruby (fine scripting languages that they are) make poor replacements for PHP. Haxe or Pike are better but not as widely available.

From a hosting perspective, I'd like everyone to target parrot and we can have done with it.

Just merge C, Ruby, & COBOL syntax into one compiler.
Now coders can start migrating away from Cobol without the hassle of rewriting entire programs. They can do it one line at a time, as they get to it.

Now if we could just merge Java, & Perl in there you'd really have something.

...and it need not be said.

Between Pyrex and Psyco, there's really very, very few applications that a language like Python isn't appropriate for. Premature optimization is the far more common programmer sin these days than choosing a language that's "too slow." Except for a few, specific application domains (that only a minority of coders are writing) dynamic languages like python are an excellent choice on today's hardware. And if you need it to be faster, just profile, find the couple of spots that matter, and pull out Pyrex.. or even the C/Python API if it makes you feel manlier. :-)

Plus, with things like PyPy + LLVM, Parrot, and IronPython emerging, things are only going to get better.. don't be the last one on the dynamic boat!

My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages.

My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages.

You'd never guess it from the moronic comments here but mixing dynamic languages will be common one day, until then:

http://parrotcode.org/
http://nekovm.org/

This is great! Now Linux development can equally support the Big Three: Java, .NET (Mono), and the P-languages (plus one R)! The next step ... get it all to run on Parrot! Convergence like none other, bwa ha ha huh!

This might be good though because people would get under the hood and decide the whole thing is just garbage and we should just compile java apps to Parrot instead.

All languages that aren't built on parrot slow it's development and are therefor evil.

Egad! The old joke is coming true!

Umm, no. I love Python as much as the next guy, but I also know that it doesn't have a JIT compiler. Neither do Perl or Ruby. In fact, they're quite slow for many tasks. Parrot may bring these optimizations to these languages, but it hasn't yet.

If these languages are faster, it's because their extreme rapid development frees you up to think of better algorithms. I certainly had a couple cases recently in which the Python code I wrote was much better than it would have been in Java, C++, or C because it was so quick to go through several design iterations. In fact, even if I had determined in the end that Python was too slow, it would have saved a lot of development effort and yielded a better product to use it as a prototyping tool before moving to a faster language.

The argument you gave applies to Java and C#.

If you don't mind working with an alpha version (in terms of features supported), you can try Pugs right now. It's pretty impressive and should be even better with the next release.

There's no official release date nor an official estimate, but when Pugs and Parrot meet in the middle (hopefully within the next couple of releases), things will start moving much more quickly. A feature-complete beta is probably not any closer than a year away, give or take the million things that can go wrong with any big open source project.

Umm... that already exists in the form of Parrot's NCI, or Native Call Interface. It's been used to bind, among other things, SDL to Parrot.

This is interesting because it already supports (albeit incompletely) more languages than .Net and is a whole hell of a lot newer

I'm all for another multi-language VM, especially if it's built from the ground up for dynamic typing, but you're joking about the languages, right?

I count 33 Parrot Languages (including duplicates) but only 15 that have ANY tests (even ones that fail).

Of all the lists that I checked, the only one that short was the one for the Mono Project (and they list 13)...

I mean, it's certainly fair to claim that Parrot is newer, if by newer you mean "still not done" (at the current rate, we might see .NET 3 before Parrot 1.0), or "released a beta most recently" (0.4 came out JUST after .NET 2 went gold). But to say it has more languages is just ignorant.

This is interesting because it already supports (albeit incompletely) more languages than .Net and is a whole hell of a lot newer

I'm all for another multi-language VM, especially if it's built from the ground up for dynamic typing, but you're joking about the languages, right?

I count 33 Parrot Languages (including duplicates) but only 15 that have ANY tests (even ones that fail).

Of all the lists that I checked, the only one that short was the one for the Mono Project (and they list 13)...

I mean, it's certainly fair to claim that Parrot is newer, if by newer you mean "still not done" (at the current rate, we might see .NET 3 before Parrot 1.0), or "released a beta most recently" (0.4 came out JUST after .NET 2 went gold). But to say it has more languages is just ignorant.

The virtual machine that will run Perl 6 is Parrot, an innovative register-based JITed VM optimized for dynamic languages.
It can also run a subset of Python (compiled with Pirate), Ruby, Tcl, brainf*ck, Ook!, Common LISP, BASIC, Lua, m4 and a few others, all of which are more or less incomplete.

More details on the Parrot site and the Wikipedia page on the Parrot VM.

If you like that sort of things, you can help!

The virtual machine that will run Perl 6 is Parrot, an innovative register-based JITed VM optimized for dynamic languages.
It can also run a subset of Python (compiled with Pirate), Ruby, Tcl, brainf*ck, Ook!, Common LISP, BASIC, Lua, m4 and a few others, all of which are more or less incomplete.

More details on the Parrot site and the Wikipedia page on the Parrot VM.

If you like that sort of things, you can help!

The virtual machine that will run Perl 6 is Parrot, an innovative register-based JITed VM optimized for dynamic languages.
It can also run a subset of Python (compiled with Pirate), Ruby, Tcl, brainf*ck, Ook!, Common LISP, BASIC, Lua, m4 and a few others, all of which are more or less incomplete.

More details on the Parrot site and the Wikipedia page on the Parrot VM.

If you like that sort of things, you can help!

(By the way did I mention that with some special modules like weave it already is pretty simple to inline C/C++ code in Python and I am experimenting with that for scientific computing and so far I am pretty impressed, it surely beats Java in my benchmarks.)

It may not seem like a big deal to some, but being able to write more or less equally capable code in VB.NET, C#, J#, C++, Python, or a long list of other languages really does increase adoption.

That's why indeed .NET looks very interesting, but it STILL remains a microsoft product.

Personally I'm still hoping the parrot will come along soon.

Well, pigeons is an improvement over snakes. On the other hand, as a camel devotee, I think your parrot idea has much to commend it ...

I suspect that you intended your question (what is the difference between... etc) to be rhetorical, however it really isn't; rather, it just suggests a lack of knowledge of the subject matter. Can't speak much about Ruby, but similarities amongst the other three are few and far between.

Anyway, others have answered your questions, however it may be worth pointing out that Parrot http://www.parrotcode.org/ is designed to be just that; a VM for execution of interpreted bytecode, with Perl6 (such as it is) already on board and Python, Scheme, TCL, Ruby and others in mind for the future.

That, uh, is the final plan for perl 6; to be written in perl 6.

It'll compile to parrot bytecode.

Of course, if you just want to mess with perl 6 before it's (completely) written in perl 6, hit Pugs.

Anyways, Python is a cool language. I'm helping out with a Python-derivative language called Boo, check it out here.
Better work on something useful.

It's fine for small stuff, scripts and little apps, but anything larger and you're lost in a sea of interpreted code.
Wrong. Better inform yourself before you try again.
FYI, you can still code for Python and compile ...
I know, but you seemed to have missed that bit.
Anyways, Python is a cool language. I'm helping out with a Python-derivative language called Boo, check it out here.
Better work on something useful.

It was an April fool's joke.

However...

http://www.parrotcode.org/

I was contrasting the current, typical use of Java as an application programming language against its hypothetical use in a Java VM as OS context. In a typical contempary scenario, finding a java 'sploit avails the cracker naught, since he then still has to crack the OS. Contrariwise, on a system where the OS is unified with the Java VM, there is no limit to the damage an exploit can do.

To summarise: one of the main reasons Java is so secure is that it has the system OS as a second line of defence. Unify OS and VM and that advantage is lost.

It HAS been tested in earnest. Applets are an example of an area where the Java security model is in effect.

On the one hand, applets are a very specific and specialised case. The malware artist not only ha t get past java, he also needs to defeat any browser security measures and there is still the OS to contend with.

On the other, current JVMs rely, as you yourself said, upon the OS for a lot of facilities. When those features are migrated into the VM, the complexity increases, and there's no guarantee that security is maintained.

Whoa! Hold up there! The protection is not in the language. It's in the platform. The Java Language is independent from its platform, and provides very little in the way of security features.

And yet I seem to recall you saying that "it is much easier to add this protection in Java than in any other langauge". Perhaps you meant to say that "the Java RTE has features that enable programs which compile into Java bytecode to better implement such protection".

We can use the term "Java" loosely (as we have been) or we can be precise. I don't mind which as long as we both follow the same rules.

If Java is the OS, it WOULD be handling security.

You mean "if the Java Run Time Engine is the OS". We're being precise, remember?

You can have an OS *never* have a root exploit, or even a critical exploit. Java can do that.

Never happen in the real world. That's my prediction.

Think, with all the J2EE servers running out there, and all the webbrowsers with Java installed, how many have experienced major flaws in the Java architecture or VM? The answer is a resounding ONE.

Yes. For a JVM insulated from the bare metal by at least two levels of abstraction, that's not bad going. It's still unproven as a full on, standalone operating system.

And Java's is secure even if the programmer DOESN'T check buffer lengths. "ArrayOutOfBoundsException: Element 100002 does not exist."

You mean the Java Runtime Environment, surely?

As I said above, we're not talking about the Java Language. We're talking about the Java Platform. You have to make a distinction between the two or you'll fall into the same trap you just did. :-)

Let he who is without sin cast the first stone, that's what I say :P

But I'll tell ya what: Let's conduct the remainder of this in terms of Perl 6 and Parrot. I'm a Perl fan, sh that'll factor out my admitted bias against Java, and since all you were originally arguing for was managed code, Parrot should do as well as the JVM. Also, I can write "Perl" to mean "Perl" and "Parrot" to mean "Parrot". Does that sound fair?

skip to: page content | links on this page | site navigation | footer (site information)

We need your support - Please mirror this site. Donate Now.

Welcome to GeeksUnite.net -->

About the Site Content Who is Chip? About A & C Open Source perl Parrot

CONTRIBUTE NOW to the Chip Salzenberg Defense Fund...

MIRROR THIS SITE
Spread the word. This can be any one of us.

To email us the url, get the latest info or just say "Hi" info@geeksunite.net

Come back frequently for the latest site and case updates.
Last updated 6/29/2005.

Join our mailing list info@geeksunite.net

PA Code by Case Subject Search & Seizure
Return of Property
Misappropriation
Trade Secrets
Harvesting/Open Proxies
Related Link

Case Documents The OMITTED Letter The Search Warrant Plaintiff DefendantInterveners
Timeline of Events

Please Contribute. Thank you for spending time on our site. It will be updated frequently. Please come back.

None of the views expressed in the website constitute the views of the Armstrong & Carosella PC law firm, or any
principals or employees, or agents or experts who have been retained in any capacity in connection with the case.
Information on this site is for educational purposes. Case Caption: Health Market Science, Inc. v Charles H. Salzenberg, Jr..
Court of Common Pleas of Montgomery County, Pennsylvania. Case Number: 05-11918

Chip Salzenberg Defense Fund
Please mirror this site. Learn from it and protect yourself.
We need your financial assistance to continue the fight.
Donate Now.


OMITTED from the Company's Pleadings,
UN-INVESTIGATED by the Detective,
it caused IMMEDIATE ACTION by the CEO,
READ the LETTER that started it all!

Why 23 million telecommuters need to be worried about this case
Or: How your life can land into the "wrong hands".

Twenty-three million telecommuters (IATC 2003) access their employer's network from home. Some use their own personal computers, while others use a computer their employer assigned to them by their employer. Some bring their laptop to and from work. Do you? Should a dispute arise between you and your employer, you may be exposed to the legal tactics and strategies used by Chip's employer.

The company can file a police report, show logs of your network activity, convince the often insufficiently sophisticated police that your behavior is suspicious and claim they are in "fear" of the loss of their property and/or trade secrets and potentially millions of dollars of profits . If you're a programmer, that is your job description permits you to "appropriate" huge source code downloads with only even less uploads - exposing you to a "claim" of theft of your company's confidential and proprietary information and trade secrets . All the while you are having an exchage with the CEO by

Further considering that Perl, PHP and python are so widely installed (even by average users) and that there are undeniable and compelling reasons favoring managed code for application development... are you saying we should all run parrot?

Good idea, but i think Parrot is designed for dynamically-typed lanuages (perl, python, ruby), wheras java, c# are statically typed.

Why your own virtual machine? Why not compile to JVM/.NET?
http://www.parrotcode.org/faq/