Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Perl Programming

Perl Features of the Future - Part 2 22

Kevin writes "This story is a follow up to yesterday's part 1 (hence the name) on the changes in Perl 6. Damian Conway (design team member): "There will be some learning involved, but it isn't like learning an entirely new language," he said. "It's more like adding a few new words to your vocabulary." It seems the perl intrepreter is getting overhauled as well."
This discussion has been archived. No new comments can be posted.

Perl Features of the Future - Part 2

Comments Filter:
  • Sad... (Score:2, Interesting)

    by superdoo ( 13097 )
    Does anyone else think it's sad that we've got a Perl story on Slashdot and the souce is a Yahoo! page?
  • The parrot interpreter reminds me so much of the CLR. I know mono has a C# compiler, but do they also have the equivalent of the MS CLR? If not then parrrot could fill that hole (well if it were going to come into existence in the next few years).
  • by AT ( 21754 )
    While parrot sounds interesting, I'd like to it compared to other bytecode interpreters like the JVM and .NET's CLR. How similar/different are they? Is parrot more suited to scripting tasks? Does it have a robust security model like Java/.NET? Does it have any neat features that the others are missing?
    • Re:Parrot (Score:4, Informative)

      by bcrowell ( 177657 ) on Friday February 14, 2003 @02:47PM (#5303936) Homepage
      Look here [parrotcode.org] for information.

      I'd like to it compared to other bytecode interpreters like the JVM and .NET's CLR. How similar/different are they?
      One big difference is that it's register-oriented rather than stack oriented. It has some fixed number of registers (32 IIRC), each of which can hold a Perl scalar value, i.e. a string, number, or reference. The register design apparently makes it faster than stack-based designs.

      The thing I'm really looking forward to is that it promises to be a well designed, well implemented, portable, free-as-in-speech approach to software distribution. This is in contrast to Java, for instance, which has lots of really horrible proprietary implementations and only an incomplete free-as-in-speech implementation (gcj).

      • There are, if memory serves, 32 integer registers, 32 "number" registers, 32 string registers, and 32 "Parrot Magic Cookie" or PMC registers which deal with more complex data.
    • Re:Parrot (Score:3, Informative)

      by chromatic ( 9471 )

      Parrot has much better support for dynamic languages -- it supports anonymous subroutines, closures, run-time compilation, and other nice features.

    • Just to add to the other two posts. Parrot also seems to be much easier to develop for, people have been able to knock out protype test languages in no time. Speedwise it seems to be better. As for the security model it runs purely as a VM (if desired) so yeah it has the same level of security; if you can trust your OS not to let VMs escape the box then programs on the VM are secure.
  • I wonder if it would be possible for Larry Wall/The Perl Foundation/someone to apply for grant money to work on Perl 6, like a university professor might.
  • This quote surprised me a little bit.

    "Like so many others in the IT industry, all three of us [Conway, Sugalski and Wall] have been looking for work," he noted.

    In fact, this bothers me a lot. The company I work for, along with an extremely huge number of other corporations, have benefitted imensely from Perl. Oracle and many other products have custom Perl builds integrated with their products. Why is it that Larry Wall should have to be looking for work? Shouldn't he and the others be quite well off from the enormous benefit that he has provided the technology industry?

    This is the biggest thing that scares me about open source. I don't want to sound anti-capitalistic here, but how many companies are reaping the benefits of the hard work Larry and other open source developers put into their excellent projects, but don't give a dime to those developers? How many members of the contributing Perl Foundation were corporate sponsors?

    I advocate open source languages and products all the time, but I can see a danger. That danger comes from folks like those at Lindows. They take stuff that others have freely contributed, sell it, retire early in the Bahamas, and the developers who made it possible wind up serving lattes in a second job to support their families.

    I can see open sourcing and donating useful utilities (I'm in the process of doing so this week), but I can't see myself putting in the time and energy into designing something as complex as an operating system kernel or programming language for free. Yes, the potential for peer recognition and hero status among geeks is tremendous, but the frustration of seeing someone else profit from my selfless contribution would take away the sweetness. Sorry, I'd rather devote those free hours to my kids or to a worthwhile charity. The rewards from those activities are even more valuable than alpha geek status.

    • GPL to some extent helps. Another important area would be "in house development projects", most software isn't written by software companies. If corporations open sourced their internal systems they could use each other's stuff. How different is the software used to test steel quality from company to company? Why can't insurance companies open source their membership systems (though not the data)? Government & academic programming are also promising since both can work on systems directly for the public benefit. Finally the examples of Oracle, etc... you mentioned are important. As the Linux kernel, and the open source browsers have shown for profit companies will help open source efforts where the open source software does some but not everything they need. Oracle might very well be willing to help Perl.

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...