Slashdot Mirror
Parrot Updates
BorrisYeltsin writes: "A couple of updates for Parrot are in a recent This Week on Perl 6, most imporantly Parrot 0.03 is out! Get it here , the release notes are here. Also Adam Turoff has got together the Parrot FAQ version 0.2 which addresses some of the more common questions about Parrot and Perl 6."
polymorphic support rocks!
gr!
The parrot has voomed
The complete developerWorks "Cultured Perl" series:
-
A programmer's Linux-oriented setup
-
Application configuration with Perl
-
Automating UNIX system administration with Perl
-
Debugging Perl with ease
-
The elegance of JAPH
-
Genetic algorithms applied with Perl
-
One-liners 101
-
Parsing with Perl modules
-
Perl 5.6 for C and Java programmers
-
Reading and writing Excel files with Perl
-
Review of Programming Perl, Third Edition
-
Save it with Perl
-
Small observations about the big picture
-
Writing Perl programs that speak English
Another good developerWorks resource is this long list of well-written Linux Tutorials.the faq isnt done yet - click on a link at the top and go no where. the author of it forgot to post link tags throughout the document linking it to the toc at the top
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
7. What language is Parrot written in?
C
8. For the love of god, man, why?!?!?!?
Because it's the best we've got.
9. That's sad.
So true. Regardless, C's available pretty much everywhere. Perl 5's in C, so we can potentially build any place perl 5 builds.
April Fool's joke can become reality. Remember not to make bad jokes next April. :)
Read more here
:)
Seems like a cool thing, I don't know much about it though.
-Vic
Parrot 0.0.3 was released way back on the 11th of dec, nearly three weeks ago.
If you want *new* news on perl/parrot, the latest parrot in CVS is now "fully-functional" (interpret that however you want.)
Software Wars
Anyone pining for fjords?
If you're interested in Parrot, get the version from cvs, and get on the mailing list. There's a hell of a lot of interesting and cool stuff thats gone in since 0.0.3, not least of which is JIT on a few platforms (linux among them). Just check out the mailing list for details.
Oh, and if you run an unusual system, then get in contact with the parrot team! They need more exotic systems to get parrot building on!/p
This post will enter the public domain 70 years after my death, unless Disney buys another extension.
On a different topic, what about compatibility? Their FAQ says that, for instance, localtime will no longer return year-1900. Doesn't this break old code? They say there will be an automated Perl 5->Perl 6 converter, but it isn't going to fix stuff like year-1900...or is it?
Find free books.
if this was some big software company, this would probably be version 3.0. (internet explorer anyone?)
A large number of perl web sites have been spammed with this. I consider the manner in which it's been done quite rude, as it has in no way been personalised, and is very "spam" like in appearance (i.e. it's saying that DeveloperWork's articles are of the highest quality - well they would, wouldn't they?).
I'm not disputing the quality of the articles there, just pointing out that this has gone to several places, and even been posted on a few sites. I didn't post it on the one I admin because it was totally impersonal.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
the FAQ has a nice light humor about it. i feel like after reading the FAQ that the maintainers like what they are doing and know what they are doing. well, of course they do! it just makes it feels more so.
bah. start over
- Java is not the only stack based interpreter out there - and is far from being a good example of one. Even ignoring FORTH which is a full blown language based around the idea, there's the UCSD p-System, and many propriety systems based on the same concept, most 8 bit computers during the eighties where implementations of other languages existed ran versions based on VMs because of processor limitations. Virtual machines are not that popular, so it's relatively rare to see them, and even rarer to see them entirely open.
- A stack based system has architectural advantages over a register based system. It may be the FAQ author considered them, but it'd be nice to actually see acknowledgement rather than an assumption that such advantages are easily explained away. Register systems have a finite structure which, ultimately, will limit the overall design of the end product and intrude into how efficient it can be. Stack based systems have no such limitations - a stack is a stack.
-
The 68000 emulator on the Mac is somehow proof that register based VMs are the way to go? I'd make a sentence involving the words "Smoking", "Guy", "Is", "Crack" and "This" but I suspect it'd get modded down as flamebait. Look, the 68000 emulator is nice but it's designed like that because it had to emulate another real world machine, not because that's the best way of doing a VM. And it had the considerable advantage that the PowerPC was designed to make such emulation fast anyway, Motorola/Apple/IBM put it together as a replacement for the 68000 and emulation of 68000 instructions without crippling the CPU itself was high on their agenda. Ever run UAE on an Intel CPU? You need to get into Pentium territory to get it to look like a damned A500 (7.1MHz 16-bit external data bus 68000). And yeah, the custom chip emulation is half the trouble, but it's not the whole story. It's slow. Dreadfully, painfully, slow.
Maybe all these issues were answered, but if you're going to put together a FAQ, a "Yeah, I thought of it, but those ideas suck, mine's much better, but I'm not telling you why, indeed, I'm going to use the worst possible examples to demonstrate how little research I did into this" answer isn't terribly inspiring.Adam might want to have a gander at gForth, which is a stack based system written in C, and runs a hell of a lot faster, in my experience, than any CPU emulator I've seen, 68000 or anything else.
You are not alone. This is not normal. None of this is normal.
"Minimal" probably refers to the size of the included library of built-in functions, not to the size of the amount of the language itself that has been implemented.
P.S.: I was going to suggest Unlambda (see link) as an example of something scheme-like yet even more minimal than scheme-- but then i discover that the Unlambda programming language is being extended to include syntactic sugar that allows you to specify church numerals using ordianary decimal numbers!! That, and the help files now explicitly tell you how to do a loop! Dammit, just when i was thinking Perl 6 was the greatest blasphemy of bloat i had ever seen, i find out that Unlambda is being adjusted to actually allow for the possibility someone actually might want to write a program in it... the whole world's going mad, i tell you..
see this link
hi your gay
Take a look at Gemulator 2000. It emulates either a 68000-based Macintosh, Atari ST or Amiga - and it is a free download. There's another company that makes an excellent 68000-based Macintosh emulator for x86 - Ardi. These emulators show what is truly possible with JIT-based emulation. UAE is dreadfully slow by comparison.
The 68000 chip would be a wonderful virtual machine - GCC already targets the chip so you would not need to write a new compiler suite from scratch.
As a side note, I wish people would divorce the notion of "Abstract Virtual Machines = Garbage Collection." An architectural neutral binary distribution format is the most important characteristic of a VM. Garbage collection just slows down the runtime.
> 11. Why your own virtual machine? Why not
> compile to JVM/.NET?
> Those VMs are designed for statically typed
> languages. That's fine, since Java, C#, and
> lots of other languages are statically typed.
> Perl isn't. For a variety of reasons, it means
> that perl would run more slowly there than on
> an interpreter geared towards dynamic
> languages.
What a windbag you are.
Java pulls the pants down on Perl all the time.
And lets it rip.
First, let me admit a bias: I am madly in love with an APL like language called K. It has destroyed some unreasonable language biases I had in the past by being simply an amazing language. I have become used to the hyper operator concept, even though in K functions are called verbs and the hyper decorations are called adverbs.
/: is read each right
/ is read over and +/x is 6, or ': is read each pair and +': is 3 5.
My question is about how hyperness is applied to hyperness and how you make hyperness apply to only one side of the operator. Here are how you do things like this in K; are these possible in the new Perl? If not, these would be monumental omissions.
' is read each
\: is read each left
Given the lists x:1 2 3 and y:10 20 30 and value z:100
x+'y is 11 22 33
x+\:z is 101 102 103
z+/:y is 110 120 130
but these can all be done implicitly, so you really do not need the decorations: x+y, x+z, and z+y are fine. This allows you walk down only a single list, while aggregating results.
x+\:y is (11 21 31; 12 22 32; 13; 23 33)
x+/:y is (11 12 13; 21 22 23; 31 32 33)
Then you can also walk down the left then right sides of list by \:/:(left each right each).
You can walk down a list unarily:
There are other adverbs and they can be combined to modify each other arbitrarily. This winds up being an incredibly powerway to write programs. It removes the programer from the burden of flow control and compacts code enormously. Think of removing all the loops from your code and replacing them with a couple charcters, instead.
Good lord, people. Get a more constructive hobby.
max
... if you can find a career field as lucrative as the tech industry currently is.
And it seems as if you could do with a more constructive hobby than bashing the Slashdot community? Perhaps, maybe, next time you could try contributing to the discussion. Or if you don't know about the topic, read the level 5 posts and learn. But, don't come in here with ignorance bashing those who know what they're talking about.
Perl is emphatically not an object-oriented language. Perl's OO features were crudely hacked in after-the-fact. This unfortunate compromise is the equivalent of trying to bolt an internal-combustion engine onto a stagecoach instead of designing an automobile from the ground up.
Too many simple tasks are pointlessly complicated. Take the simple example of creating an array whose elements are arrays. Not only does the developer need to use additional inner brackets for each element, but they must also remember to use the unique @{$a[1]} syntax when referencing. Why all the extra steps? Who knows.
Perl is notoriously impossible read and maintain. Walk into any bar frequented after-hours by veteran developers and you'll hear story after story being swapped about having to decipher brain-crushing lines of text like :" (my @parsed =$URL =~ m@(\w+)://([^/:]+)(:\d*)?([^#]*)@) || return undef;". This unreadability is in part the result of the fact that:
Perl attempts to be all things to all people and ends up being second-rate at everything.Perl is widely known as the "duct tape of the internet", and it performs superbly in this role. However, just as you cannot build a house out of duct tape alone, so attempting to turn a language that was originally developed for scrpiting brief, handy utilities into a do-all, be-all programming language will only result in the buggy, bloated, "write-only" mess that Perl has become.
Subroutine signatures, orthogonals, method access, data inheritance: this list could go on and on. But there is no real need. Its is now clear that Perl is doomed. At this very moment, Perl 6.0 is being cobbled together, with bulletins about the myriad upcoming features of the new version being issued with titles referring to the Biblical Book of the Apocalypse, the favorite text of messianic streetcorner lunatics. There is no better indicator of the deranged states of mind of the developers behind Perl than this unfortunate choice of imagery. Software developers with any interest in future employment/relevance should sieze this opportunity to attain fluency in Ruby or Python and donate their Perl books to the History Department of their local University.
Foxbase was bought by MS, it's beyond saving. Borland used to own the other two, who owns the rights now is anybody's guess.
It would be nice to see PDox/DOS and dBase/DOS reworked as Apache modules, gawd there's so much code out there. Instant business applicability for mailing list managers.
The death of business languages started with object oriented Paradox/WinBlozMe. That died a quick and well deserved death. dBase mutated into that Kylix thingie, who but a programmer is going to mess with that?
Big unmet needs are out there, mebbe Parrot will keep them in mind, but I kinda doubt it. Oh Dr. Pauker, where art thou?
In fact, from a pure language standpoint, FORTH is superior. It's a tad more difficult than C, though, and requires a more liberal view of the programming arts to master. And before you start going off about how a lot of FORTH machines are implemented in C, yes, they are, no denying it - C isn't a useless language at all, and there are compilers for it on almost every platform.... but pure FORTH vs pure C (popularity and number of libraries aside)? No contest.
A very neat thing would be to support the Parrot interpreter in web browsers.
It would be a nice replacement for Java. I'd just love to write client-side web applications in Perl.
{{.sig}}
Foxpro, not Foxbase.
Foxbase was bought by MS, it's beyond saving. Borland used to own the other two, who owns the rights now is anybody's guess.
For the last time, FoxPRO.
Meanwhile, small businesses, nonprofits, foundations, and charities are crying out for a language that can handle their needs. Do you make so much money that billing at $200 to $400 an hour beneath your standard of living?
Oh, I know. It violates the Richard Stallman GNU Purity & Poverty Vow. Let's go down the tubes like VA Linux rather than engage in crass capitalistic commercialism that actually satifies needs. It's the computing equivalent of Catholic priests with their weird celibacy vow.
I liked FoxBase, it produced small, fast, easy to debug programs that an end user could not crash. Other clones included dBXL and Clipper, two more great implementations of the dBase language.
Once more, FoxBASE. Seems I've been around a lot longer than you.
Sorry, perl. You got to change you name to Jerl or Pava or something.
I assume we're not talking about the next stage of evolution in brightly coloured birds...
Cheers, Ian
The Java VM is not a "stack based interpreter". First of all, it's not an interpreter. More importantly, the Java byte codes are restricted in such a way that they are trivially converted into a register machine. In fact, the "restricted stack" approach that both JVM and CLR take has all the efficiency advantages of register machines and all the compactness and simplicity of stack machines. Perl6's method is likely much inferior.
Interesting as these detailed implementation aspects are, I'd like to take a moment to step back and look at the potential of, er, Parrot-like developments.
.NET and Java unless it includes a VM. As we know, cross-hardware platform distribution issues are already affecting PPC and ARM users and this will get worse as small non-x86 devices spread.
.NET VMs, which brings me on to my next point.
.class files. However, comments (and layout) are not stored in the bytecode and this is starting to emerge as a significant problem for advanced development tools. For a brief illustration, consider a problem with IBM's new Eclipse IDE. Eclipse extracts Javadoc-style comments from source code that describe methods, parameters and other API aspects. It makes these available as tool-tip-like hints when you start to code a call to a particular method. However, commercial code is not distributed as source but as class files with accompanying Javadoc-generated HTML files. Although, between the two, all the information that Eclipse needs is there in principle, in practice it is hard for it to put the pieces back together and use them.
.NET, Perl 5 and Python have some limited features in this area, mostly to do with loading code dynamically and supporting development tools, but they are awkward and ugly in the extreme. There is demonstrably huge potential for a mainstream language with this level of flexibility - any sophisticated business will be able to come up with examples like those above.
Linux as a platform won't continue to grow relative to
Linus should therefore make a New Year resolution be to 'anoint' a VM as the future target platform and encourage libraries to be built around it. Parrot could be this VM, but from this point of view Parrot doesn't offer any fundamental technical advantage over the Java or
While code distribution requirements alone are sufficient to justify a 'Linux VM', there is another very interesting potential benefit which I haven't seen discussed yet. This applies specifically to Open Source and the principles behind it. This is that a VM could be implemented where the source code and compiled code were semantically equivalent. This means, of course, that all that ever needs to be distributed is the 'compiled' form and, by its very nature, this code is always open.
This is almost the case with Java bytecode, in that decompilers such as JAD can (usually) produce editable code from compiled
Perhaps a better example of sourcecode equivalence goes back to the old days of home computers with interpreted BASIC. Most people will remember that BASIC code was 'tokenized', including keywords, blank lines, punctuation and comments, in a way that could be both edited and executed. Unfortunately, the spread of this useful model was halted when PCs became big enough for 'real' compilers to run.
What's needed, therefore, is a more sophisticated version of the old tokenized program representation, and such systems have been developed for Scheme (and FORTH, I think), usually known as Abstract Syntax Tree interpreters, in contrast to bytecode interpreters like Parrot's current implementation. There may be some middle ground here - I have a few pointers to research in this area, such as Anton Ertl's work.
Now, having solved Linux's portability problem and given a big boost to open source, we could perhaps rest there with some satisfaction. However, I'd argue that there's one more important requirement to address and this time it will be one that is familiar to programmers already, if mostly only those working with languages like LISP and Scheme. This is the provision of dynamic reflective capabilities, meaning the ability to treat programs as data.
They say that any large C application includes an interpreter for a higher-level language. In finance, we see applications supporting the entry of complex formulas; in CAD/CAM people build parts which are themselves programmable such as a parameterizable aircraft undercarriage. These features turn users into programmers, but programmers working with a high-level, specialized language.
LISP is a much better language to build such applications (which is why a lot of AutoCAD is in LISP) since LISP programs are themselves data structures that can be added and played with at run-time. Java,
So, to wrap up, it looks like others have left the goalposts wide open for us and there is a significant opportunity to exploit. It will be interesting to see whether this Parrot can do more than mimic other platforms.
But Perl's creators and users aren't ready to quit.
That's why there's a Perl 6. :-)