Slashdot Mirror

His point is that Perl shouldn't be in all caps. It's not an acronym. See http://www.perl.org/about/style-guide.html or http://c2.com/cgi/wiki?PerlIsNotAnAcronym.

Agreed. I hate to use the mouse when typing, but haven't yet quite managed to avoid it entirely. For the next laptop I buy a clitmouse may well be the deciding factor. Unfortunately, I hear that IBM holds a patent on them.

Can I get any advice? Is Ruby really "more powerful than Perl and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?

No, it is not more powerful than Perl. But than again, nothing is. The points is not what is more powerful per se, but rather which is more powerful in your hands and which one best fits your own brain. At this point it is extremely important to mention Parrot: "The amazing project [...] to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few)."

Perl, Python and Ruby, while not the only ones, are certainly the most important languages for the Parrot development. Parrot will not be considered ready until all of them are fully supported, and at this point Parrot will be their main target Virtual Machine, running each of them and allowing them to interoperate. At this point it won't matter which of those languages you personally use, because whatever you choose you will still have access to all of the libraries and module, class and object, of each of them.

Few years ago I will tell you: "go for Perl because of CPAN." Now my advice woule be: "go for whatever you please, for in few years it won't really matter. We will be able to work on the same project, write the same application. I will write my part in Perl 6, you will write yours in Ruby, someone will write in Python and another one in Scheme. We will all subclass our classes, invoke our methods, use our objects, and we will produce a single, monolithic Parrot application anyway."

Just imagine picking up some fresh, young and cutting-edge language designed weeks ago--or even designing your own language--and having every module from CPAN available at once, working just fine using your new language syntax. This is the future Perl, Python and Ruby. Interoperation instead of competition.

Can I get any advice? Is Ruby really "more powerful than Perl and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?

No, it is not more powerful than Perl. But than again, nothing is. The points is not what is more powerful per se, but rather which is more powerful in your hands and which one best fits your own brain. At this point it is extremely important to mention Parrot: "The amazing project [...] to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few)."

Perl, Python and Ruby, while not the only ones, are certainly the most important languages for the Parrot development. Parrot will not be considered ready until all of them are fully supported, and at this point Parrot will be their main target Virtual Machine, running each of them and allowing them to interoperate. At this point it won't matter which of those languages you personally use, because whatever you choose you will still have access to all of the libraries and module, class and object, of each of them.

Few years ago I will tell you: "go for Perl because of CPAN." Now my advice woule be: "go for whatever you please, for in few years it won't really matter. We will be able to work on the same project, write the same application. I will write my part in Perl 6, you will write yours in Ruby, someone will write in Python and another one in Scheme. We will all subclass our classes, invoke our methods, use our objects, and we will produce a single, monolithic Parrot application anyway."

Just imagine picking up some fresh, young and cutting-edge language designed weeks ago--or even designing your own language--and having every module from CPAN available at once, working just fine using your new language syntax. This is the future Perl, Python and Ruby. Interoperation instead of competition.

The above program doesn't print "x is false" because its else is in fact paired with if (y) instead of if (x) which the indentation might falsely suggest. In C else is always paired with the immediately preceding if. This is one of the most important yet subtle forms of deceptive control flow which might be used in vote-counting logic.

Not every language has this problem, though. Python solves this "dangling else" problem by making the indentation significant, so else always matches the if above, indented with the same amount of whitespace. Perl on the other hand solves this problem by making curlies mandatory, so there is no if ($x) $a++ but always if ($x) { $a++ } (but there is also an even shorter $a++ if $x). Perl 6 will still have the curlies mandatory but the parentheses will be optional: if $x { $a++ } (with much more interesting improvements, see Synopsis 4: Blocks and Statements: "And there's a new elsunless in Perl 6--except that it's spelled elsif not.")

But getting back to the point, if I was really serious about inserting a backdoor in the voting code I would just make few "mistakes" with buffer overflows with all of the important cheating code hidden safely in my exploit, leaving nothing more in the source code than an ordinary bug, like using gets() or strcpy(). When inspected, it would look completely innocent, like a stupid mistake of a lazy programmer, not like an evil backdoor of someone planning to change the election outcome.

Does Parrot use References Counting (limited by virtual memory)? or
Does Parrot use Mark-Sweep Collection or Copying Collection (limited by physical memory)?

Unlike Perl 5 today, Parrot will not use reference counting. This is one of important difficulties which the Ponie project has to overcome. Please let me quote the most relevant parts of Parrot documentation.

Parrot FAQ:

You're not using reference counting. Why not?

Reference counting has three big issues.

1. Code complexity
2. Every single place where an object is referenced, and every single place where a reference is dropped, must properly alter the refcount of the objects being manipulated. One mistake and an object (and everything it references, directly or indirectly) lives forever or dies prematurely. Since a lot of code references objects, that's a lot of places to scatter reference counting code. While some of it can be automated, that's a lot of discipline that has to be maintained.
3. It's enough of a problem to track down garbage collection systems as it is, and when your garbage collection system is scattered across your entire source base, and possibly across all your extensions, it's a massive annoyance. More sophisticated garbage collection systems, on the other hand, involve much less code. It is, granted, trickier code, but it's a small chunk of code, contained in one spot. Once you get that one chunk correct, you don't have to bother with the garbage collector any more.
4. Cost
5. For reference counting to work right, you need to twiddle reference counts every time an object is referenced, or unreferenced. This generally includes even short-lived objects that will exist only briefly before dying. The cost of a reference counting scheme is directly linked to the number of times code references, or unreferences, objects. A tracing system of one sort or another (and there are many) has an average-case cost that's based on the number of live objects.
6. There are a number of hidden costs in a reference-counting scheme. Since the code to manipulate the reference counts must be scattered throughout the interpreter, the interpreter code is less dense than it would be without reference counts. That means that more of the processor's cache is dedicated to reference count code, code that is ultimately just interpreter bookkeeping, and not dedicated to running your program. The data is also less dense, as there has to be a reference count embedded in it. Once again, that means more cache used for each object during normal running, and lower cache density.
7. A tracing collector, on the other hand, has much denser code, since all it's doing is running through active objects in a tight loop. If done right, the entire tracing system will fit nicely in a processor's L1 cache, which is about as tight as you can get. The data being accessed is also done in a linear fashion, at least in part, which lends itself well to processor's prefetch mechanisms where they exist. The garbage collection data can also be put in a separate area and designed in a way that's much tighter and more cache-dense.
8. Having said that, the worst-case performance for a tracing garbage collecting system is worse than that of a reference counting system. Luckily the pathological cases are quite rare, and there are a number of fairly good techniques to deal with those. Refcounting schemes are also more deterministic than tracing systems, which can be an advantage in some cases. Making a tracing collector deterministic can be somewhat expensive.
9. Self-referential structures live forever
10. Or nearly forever. Since the only time an object is destroyed is when its refcount drops to zero, data in a self-referential structure

Volunteers needed :)

The Perl equivalent is Class::DBI. This is quite a good module for working with databases, as it can save you from writing a lot of code. This article discusses the power of Class::DBI combined with the Template Toolkit, the best pure-MVC templating system there is. Maypole is a system built around these two modules that lets you create a complete Web-based database interface in as little as ten lines of code! Another Maypole article is here.

where do I find the "don't suck" feature?

Found it!

Actually it looks like this feature may be coming back soon. See Section and Topic Exclusion Working Again on use.perl.org.

It seems they've been busy coding :)

Maypole is a Perl framework for MVC-oriented web applications, similar to Jakarta's Struts. Maypole is designed to minimize coding requirements for creating simple web interfaces to databases, while remaining flexible enough to support enterprise web applications.

how do you know it has anything to do with Google?

You don't need to know that. Here's how I solved it when I first heard about it in July.

#!/usr/bin/perl

use Net::DNS;

my $res = Net::DNS::Resolver->new;

my $e = '2718281828459045235360287471352662497757247093699 9'
.'59574966967627724076630353547594571382178525 166427'
.'427466391932003059921817413596629043572 90033429526'
.'0595630738132328627943490763233829 8807531952510190'
.'11573834187930702154089149934 884167509244761460668';

foreach (0 .. length $e) {
my $n = substr $e, $_, 10;
my $q = $res->search("$n.com");

if ($q) {
print $n, "\n";
last;
}
}

The best method I've seen is taking e and use DNS to find the look for domains that resolve: see http://use.perl.org/~davorg/journal/19837

perl macros
Other things they are thinking about

but I do not think that they are going to make another lisp or scheme. They are writing perl and the perl6 language feels very different from scheme or lisp programs.

On the approach of perl6 to language design, I find the approach taken in apocalypses and exegesis to be quite good in explaining what they are thinking about and what they want to implement, and are on par with the essays and responses that you have archieved on your site. They too are taking the slow road to implementation, with emphasis on each and every aspect of the language, from VM to syntax.

While groups like ll1 and langsmiths have quite interesting languages, most of them do not provide a consistent and integrated approach to all problems, (most explores some interesting ideas to the limit, but does not look at other aspects or is founded on a consistant approach.)
I do not see many interesting new ideas in the common-lisp world, or in the scheme world. (the RnRS process seems to be dead for some time.) and the language you mentioned (Goo) does not seem to offer the kind of ideas that you look for in a next generation language.

From what I know, Arc, and perl6 seems to be the only? initiatives that promices to go forward on implementing a better general purpose language and Arc is the only one from the lisp family, and that is the reason for many of us are anxious to know more about Arc.

My gut feeling is that you may not have to worry about the ecosystem that has grown around current successful languages, but rather, about the people that you want to reach with your language, and if languages like perl are able to claim all the features that we claim to be what makes lisp different, then you might as well expect a lesser mindshare in the target group.

(I believe that it is not just these features alone that makes lisp what it is but the whole language, the way it is designed, the freedom it gives, and the way you can think in it, etc. but you still need to advance and you still need to attract the people who will be able to appreciate it, and adding all the features that you have outlined in you essays (including macros) to perl or python for that matter, wont make them lisp. (it may make them better languages, but not lisp.))

-I think you are going to find perl6 targeted towards the same segment of people that Arc is targeted to-

I would really like to see some articles on what you have implemented in Arc, and why they were done so, or what you are thinking would be nice to do, I request this because it gives us a better and deeper understanding of many facets of the language on following through the discussions or articles that details why some thing was done a particular way. It makes the language a lot more transparent and a lot less imposing if I can find some discussions or articles on the approach taken.
you do not have to think of it as a dead line but more as an ongoing discussion or a philosophical argument if that will help it.

What I find strange is that it seems to be ok for some licenses to add restrictions not in the GPL, but not for others.

The GPL (in section 6) disallows posing additional restrictions on
redistribution etc. of GPLed software (including combined works consisting of some GPLed and some non-GPLed software). This means that software under a license that poses restrictions that are not in the GPL can be combined with GPLed software, but the result may not be redistributed.

Now consider, the Artistic License, Version 2.0. This is listed under GPL-compatible licenses.

Consider, also, the XFree86 License, Version 1.1. This license is listed under GPL-incompatible free software licenses.

The XFree86 License 1.1 is deemed incompatible, because it requires that the software includes an acknowledgment of XFree86 in the same place as other such acknowledgments.

The Artistic License 2.0 allows redistribution of a modified version only if it is clearly marked as such. The GPL contains no such requirement to my knowledge.

So, the question is, why is the AL2.0 considered GPL compatible, but not the XF1.1?

You must mean the IBM TrackPoint/ClitMouse.

So I was right, or almost anyway. I just googled on 'clitmouse' and found no end of references to it.

Apparently, it is a standard term (although don't analyse the word itself too hard) and I've even turned up the very first reference to it in back in 1998.

I always found it to be superior to a mouse or touch pad in every way, especially for a touch typist like myself who doesn't like to break the rythm by moving my hand away from the keyboard.

If anyone hasn't seen one of these, there is a picture here. I don't really care what they're called, but I wish they were more common.

If all software was free, why would anyone bother developing it?

Gee, I can't think of anyone who would develop software without getting paid for it...

But seriously, there are several reasons people would write software whose price is 0:

• People want better software to do $WHATEVER (for values of $WHATEVER that make money, which is most of them), so they write it
• People want to get a job as a programmer so they write a software package to prove they aren't total code monkeys
• People like fame; they like being admired and appreciated
• An industry consortium decides they need an open, standard, free way to do $WHATEVER
• Some people have a political motivation to undermine proprietary software (we may not have that same motivation; but it is a real driving force for some people)
• Some people like to help others (ditto)
• Your company might want to make your product universally (or nearly so) used in order to be able to charge money for training, certification, etc.
• I mentioned 15 high-profile products that are competitive with best-of-breed and are available for $0 (and not all of it is Free as in speech). All of them were written because one of the above bullet points (or one I forgot) applied.

There are lots of motivations for people's actions besides money.

Since distributing the code indicates acceptance of the license, it doesn't matter what comes out of your mouth. The action of distribution trumps your statements. It's like me saying I did not type this sentence.

I don't see how distributing code automatically indicates acceptance of a particular license to do so. After all, Perl is licensed under both the GPL and the Artistic License. If I distribute it without supplying a specific license document, which license am I automatically accepting? Both? In SCO's case, however, they do appear to be complying with the GPL (despite their arguments about it) so they may be able to argue that the Judge should ignore what comes out of their lawyer's mouths. I'm not sure what effect that would have on their other cases though. :)

Yes, I'm quite aware of the practical problems with the existing stem cell lines.

Until you actually visit FreeBSD.
Or visit Ximian
Or PERL.
Or PHP.

Why not bitch about WINE, Transmeta or any of the others that are just the corporate/official logo?

Umm, how 'bout this for Perl and this for Python. You should have looked harder.

SUN has done an amazing job in extending Java even to include generics without breaking backwards compatability. Yes it did not lead to the solution that is technically and internally the most efficient (it would have required changes to the JVM), but the developer is not affected. Internally it is solved by typecasts, but who cares?

I care. To me, Java has two arguments in its favor vs Python: execution speed and jobs available.

The former is being eroded. Really, the only application I can think of where Python's execution speed worries me is for a 3D engine I'd like to do. But with psyco, I found that the Python version of lesson 10 of the nehe opengl tutorial gets 140 frames-per-second to Java's/LWJGL's 180 (though not 'out of the box', I had to level the playing field by turning on the same opengl features for both versions). I'm still leaning slightly towards Java for this project, as I wonder that the performance gap won't become more pronounced with a real game engine that does more than just feed polygons to my graphics card.

As for jobs, I'm deciding whether I would really want another Java job. Java's not fun for me, but I digress.

Getting back to Sun, they broke backward compatibility from 1.3 to 1.4 for assertions. Why did they not do the same for generics when it would have improved performance? You'd think they would have, since there have been stories circulating of .NET's superior performance (true or not). I think generics were rushed into Java to compete with C#. The JVM was left alone, not to preserve backward compatibility (which Sun has broken before), but because there was no time to add this feature and still ship Java 1.5 in a short enough time-frame to preserve Java's waning mind-share.

".NET is years behind and plans to bring similar features only in 2007 (generics)."

Incorrect. C# has generics right now.

Also, I like that C# can allocate stuff on the stack and allows 'unsafe' code to use pointer arithmetic. These are all boons to performance, and performance is why you use C# or Java (buzzword-compliance notwithstanding). If you want to innovate or be spookily productive you use something else.

Jeez, how many times am I going to see this claim repeated over and over? Perl and Python ARE NOT INTERPRETED LANGUAGES! They both compile to a bytecode (intermediate) language which is then interpreted, just like Java/C#, and thus share the same advantages you mentioned. Python I know was a bytecode compiled language from its very beginning, it was never an interpreted language, and Python at least has Psycho, which is a kind of just-in-time compiler for Python bytecode, which can convert a lot of Python code (but not all) into native x86 instructions.

Care to provide some links? From what I can find, Python is interpreted, Perl is interpreted, and Ruby is interpreted. Now perhaps they mean something different when they things like, "Ruby is the interpreted scripting language," or, "Python is an interpreted, interactive, object-oriented programming language," but to me that says "interpreted". That the interpreter may JIT compile the script into a faster bytecode during runtime does not necessarily make the languages non-interpreted. Java and C# need to be explicitly compiled. Python, Perl, and Ruby do not.

So, care to back up your statements?

On the other hand, if all you need is perl modules (no external libraries) then you can use the CPAN module itself to reach out to CPAN, get the perl code, and test it right there on your system. nearly all the time, it just plain works. That is amazing (to me, anyway).

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

Lucky PHP guys.. Too bad that support for compiling Perl code into executables is almost non-working.. The only viable alternative I know of is using Stunnix Perl-Obfus for obfuscation/scrambling, and turning output into executable with PAR or Perl2Exe. Does anybody knows a better alternative?

Pratical Extration and Reporting Language

Though I agree it's definitely Perl, not PERL, but it's name did originaly come from an acronym.

reading a fellow perl monger's log over at use.perl.org how Advogato suddenly dropped of the earth, now winer.

blogs aren't for free ... so I'm not supprised. but it does raise the question why users cannot set up/mirror blogs on their own domains?

reading a fellow perl monger's log over at use.perl.org how Advogato suddenly dropped of the earth, now winer.

blogs aren't for free ... so I'm not supprised. but it does raise the question why users cannot set up/mirror blogs on their own domains?

You obviously didn't read the web page I pointed to.

PHP 4 has a === operator. It works the same way as ==, except that it additionally requires both sides to have the same type. This sounds initially like the perfect solution -- just use === wherever you would otherwise have used ==. Unfortunately, you lose the convenience of being able to treat numbers and strings interchangeably: it is no longer the case that 3 === "3".

About modules. So paying more is a solution? Meanwhile in Perl I just use the use statement to pull in any module I want. Even compiled modules (check out PDL, a whole bunch of matrix code written in FORTRAN). And I don't have to be administrator. I can install modules in my home directory, and/or make my own:

use lib "$ENV{'HOME'}/Perl";
use MyModule;

I can't see why you think PHP's all-associative arrays are so great. To me it sounds like another attempt to simplify without thinking of the consequences and instead making the result complex and ambiguous. What happens when you mix up normal indexed array operations (e.g $a[1] = 20) with associative operations (e.g $a['george'] = 5) ? I thought PHP was meant to be a simple language that everyone can dive into and start using. But things like this are not obvious, even to a seasoned (although now unemployed) Perl professional such as myself. Perl seperates lists from hashes. I see no reason why PHP should combine them. All I can imagine is some half-wit thinking Hey! What if all arrays are associative? That'd make everything so much simpler! Um, no mate. It doesn't.

Every job has its requirements; being a good programmer is being able to use the tools you have to solve the problem in a way that fits the requirements. Being a great programmer is knowing which tool is right for the job - and which isn't - and when they may have to look for something else.

*g* -- I like parrot -- In fact I want Parrot to become the FreeSoftware VM :)

I checked, and I've got documented evidence of this. On April 25 last year, I reported that earthlink.net was showing up as the top search result for queries involving various religious words, including "Bear Valley Bible Institute." The Church of Scientology (which owns Earthlink) was clearly engaging in something to distort the page rank of earthlink. I had noticed this for a long time before I recorded it.

On that same day, I reported the problem to Google via their feedback mechanism. I note today that the problem is gone.

Now if I can just do something about the "Church Of Christ at eBay Low Priced Church Of Christ. Huge Selection! (aff)" ads I keep getting on Google, I'll be happy... ;)

This one puzzles me because it's so geeky and yet so tastefully done. It's like someone spending $100K to hire an artist, do preprint work, and print up a large poster just to say, "We Code in Perl".

iirc Apple built a *lot* of software with Pascal. The main alternatives were BASIC and 6502 / 68000 assembler, as C had not caught on in a critical mass sort of way (talking late 70s-mid 80s here.)

Perhaps the equivalent today would be the profitless spending of $$$ to build websites declaring your affection for a certain system or language.

Perl is actually dual-licensed under both the Artistic and the GPL, as stated here.

One word: Perl. Compared to C/C++ it is poetry. Introduce her to a friendly llama. If she gets stuck, introduce her to some monks who have shown willingness to help out a beginnger. What you'll find is that they are especially kind if you explain who you are, what you're up against and why you want to do what you want to do.

Beginning programmers took quickly to Perl because "it allows you to express yourself naturally." For instance, the automatic conversion between string and numeric types is what non-programmers expect:

the string "3" doesn't mean 51; it means 3. And if you add "4" to it, you expect to get "7" back.

In this article you'll find an interview with Simon Cozens about this very issue. There are experiences about theaching perl as a first language that will surprise you.

Cozens firmly believes that Perl should be a first programming language. "Oh, absolutely! It's ideal because it's a real-world language, unlike one designed specifically for teaching, such as BASIC (Visual or otherwise). It's a high-level language that deals naturally with natural concepts like strings and lines of text, unlike something like C; and it allows easy data and text manipulation without a tortuous syntax, unlike something like Python or Tcl. In fact, I don't know if there's a better first programming language."

Hey! Look everybody! Larry Wall has invented a language called Perl! It's great for extracting reports from text.

Randall put this out like almost 3 years ago. And frankly I find HLA more confusing than as or nasm.

qw{ ... } gets a synonym: ... . For those still living without the blessings of Unicode, that can also be written: << ... >>.
. . .
zip has an infix synonym, the Unicode operator ¦.

and since "it should not be difficult to do", we can assume you'll write the tools to do it, right? let us know where we can pick those up from. thanks.

Why is "?:" spelled "??::" ?
Because "?:" is a logical (short-circuit; control flow) operator. The newer spelling makes it look more like "&&" and "||".
Why is "&&" different from "and"? Ditto for "||" and "or", etc.
Precedence, my friend, precedence. That already exists in perl 5. The spelled-out operators have much lower precedence than && and friends -- so you can say
if( $a = shift and $a=~m/foo/ ) { ... }
conveniently. ($a gets the shifted value, not the boolean AND of the shifted value and the match).
"." is now "~"?
Well, three good ones out of four ain't bad... IMHO this is dumb. The reason is that "->" is now "." (saving some keystrokes, I suppose) -- but I'd rather leave both operators as-is.
Charwise operators?
Yes, excellent stuff! I believe that this is actually driven by the PDL application -- there, you have large arrays (e.g. several million entries) and want to do vast vectorized operations on them. Currently PDL uses the perl 5 bitwise operators for vectorized ops -- but that's not a perfect fit, since sometimes you do actually want bitwise operations.

Interestingly enough, "</perl>" is valid Perl. You would have to find another delimiter. Good luck.

Programmers will be able to extend he syntax of programming languages,

Again, nothing new.

And also here.

Well... You are technically correct. I am only wondering whether talking about "syntax" in the context of Lisp isn't a little exaggeration. The true power of Lisp seems to be the apparent lack of syntax as we usually understand it and writing parsed trees by hand, to make writing bad code impossible.

and programs will be stored as XML documents so that programmers can represent and process data and meta-data uniformly.

There is no way in hell that would ever happen. Ever.

I agree. What people forget is that you can not win against entropy. By redefining problem in a different way you are not necessarily solving it.

Very true. Let us not forget the Conservation of Cruft Principle.

Does anyone even remember now KISS principal?

I don't think we've met.

> >Programmers will be able to extend the syntax of programming languages,
>Again, nothing new.

And also here.

>>It's a very insightful and thought-provoking read. Is this going to be the next generation of extensible programming?
>No.

I agree. What people forget is that you can not win against entropy. By redefining problem in a different way you are not necessarily solving it. Does anyone even remember now KISS principal?

An interesting article written by a professor at the University of Toronto argues that next-generation programming systems will combine compilers, linkers, debuggers, and that other tools will be plugin frameworks, rather than monolithic applications.

This is not the next generation of programming systems but rather the present one for pretty much everyone except for those using Microsoft tools.

Programmers will be able to extend the syntax of programming languages,

Again, nothing new.

and programs will be stored as XML documents so that programmers can represent and process data and meta-data uniformly.

There is no way in hell that would ever happen. Ever.

It's a very insightful and thought-provoking read. Is this going to be the next generation of extensible programming?

No.

Now, I will read the entire article, but somehow, I am not holding my breath...

Above in PDF

Sample of an AppleScript in English and Japanese

WikiPedia

Current Apple info

Some discussion on it circa 1994

Note, this should not be confused with OSA (Open Scripting Architecture) dialects, like JavascriptOSA, which are different.

Aside from this, the most linguistically extendable language would probably be Perl (especially Perl 6). Having been written by a linguist, I imagine the most awareness of the linguistic aspects of coding in a different lanugage would be.

I mean really, "coding in another language" doesn't mean replacing "for" loops with "pour" loops, it means taking advantage of concepts (like word genders and verb conjugation) that are specific to that language. Programming "in a French way" could lead to constructs, algorithms, and phrasing very different from "standard C".

I disagree. Any language which removes basic assumptions made by lower-level languages (e.g. that my int won't become a string when I'm not looking) will "slow" the language.

You may disagree, but as far as I know, even though Perl 6 removes those very assumptions by default, one is still free to explicitely impose them nonetheless, is one not?

As an example of what I mean

my int $x=1;
my int $y=2;
my int $z = $x + $y;

What's the result? In your model, we would agree that the reuslt must be an integer, and specifically 1, but that's (woefully), not the case. You can't know that another thread hasn't womped the contents of $x and replaced it with a high level object that is "sort of 1" by the time the third statement executes.

I was under the impression that in Perl 6 (or in "my model," if you will) int means a promise to the compiler that you are not going to store anything which is not integer and Perl's optimizer can use Parrot's Ixx register or some compact representation in the case of arrays.

Worse,

my int $x = foo();
my int $y = bar();
my int $z = $x + $y;

Here, we don't even know if we're dealing with integer addition! If $x is a URI, then hold on to your seat and enjoy the ride, but you're not going to be sure of the result.

We know, for you have used explicit int (not Int, mind you). Please read Apocalypse 2 by Larry Wall:

"[...] there will also be lowercase intrinsic types, such as int, num, str and ref. Use of the lowercase typename implies you aren't intending to do anything fancy OO-wise with the values, or store any run-time properties, and thus Perl should feel free to store them compactly. (As a limiting case, objects of type bit can be stored in one bit.)"

I am not aware of any changes to this decision but I might not be up to date with everything posted on the mailing lists. Could you please quote the relevant portion of some later text you are basing your knowledge on? Thank you. And excuse me if I had spread misinformation.

Everyone is right here. There is no one language which is best for everyone. Perl 5, Perl 6, Ruby, Python, Lisp, Scheme... They are all going to target Parrot so we will be able to choose our favourite language and still work together instantiating our objects and even inheriting from each other's classes crossing the cross-language boundaries.

Wow! What a wonderful and innovative idea, totally unlike anything anyone has done before!

JVM is not exactly language-independent. It is not very well suited for dynamically typed languages such as Perl 5, Perl 6, Ruby, Python and in fact even for languages like Lisp and Scheme. Thought, with few exceptions like immutable strings or some uninheritable base classes, JVM is quite a nice environment for statically typed languages with simple single-inheritance object models like Java.

The Microsoft .Net on the other hand is not very platform-independent and I don't think it ever will be, while still supporting mostly statically typed languages. Besides, it didn't even exist at the beginning of Parrot project...

In any case, none of them runs Perl 5, Perl 6, Ruby, Python, Lisp and Scheme which I was talking about. So yes, Parrot is in fact totally unlike anything anyone has done before. Very true.

As long as you only want to write in slow interpreted languages, it's not a bad idea. Personally when I use Lisp I compile it to native code, and it runs FAST. When I use ML I compile it to native code, and it runs FAST. When I use Perl... I spend several minutes twiddling my thumbs. No thanks.

There is no such a thing as slow language. The only way in which a language per se can be slow is the parsing time. Of course Perl 6 having unprecedentedly rich (and even self-modifying) syntax will always be much harder to parse than Lisp which is basically a manually written parsed tree. However, you will always be able to compile it once and store Parrot bytecode or native binary. Even without compiling it to a native binary, there is JIT engine which can run critical parts of the bytecode as single assembly instructions on harware registers if you give enough hints to the compiler. See the files in parrot/jit directory in the CVS. It is really worth reading.

Well, if you want a innovative language (rather than a pragmatic one), Haskell should definitely not be left out. Granted, it may be a little hard to use if you just want to write real-life programs (quite a lot of computer-science stuff are involved just for mutable state), but its interestingness beats OCAML and even Lisp if you are getting tired of 20 slightly different imperative languages. The language is also well supported in the free software community.

Haskell is very interesting indeed. And there are already plans to write a Haskell compiler targetting Parrot. (The relative interestingness is a very subjective matter, though.) There is already a Scheme compiler written by Juergen Boemmels and Jeffrey Goff (version 0.0.11 is "Functioning, as far as implemented. Lists and functions are working but many functions are missing implementation.") so Lisp, OCAML and Haskell compiler writers will have some interesting prior art to base their compilers on. I really look forward to having as many languages targetting Parrot as possible. The very recent ONLamp article, Building a Parrot Compiler (It's not just for Perl 6 anymore) by Dan Sugalski, is a great start for anyone planning to write a Parrot-targetting compiler. That's pretty amazing that three years ago Parrot was only an April Fool's joke...

Of course, I'm not disparaging Larry's work here. Perl is a good and pragmatic language, and I'm glad to find it getting rid of the historical ugly parts..

As a sidenote I might add that Perl 6 will support the functional paradigm. It is just not the only paradigm it will support.