4 ms·

I for one am extremely excited for Perl6's ecosystem to grow, documentation to increase, and for the performance optimizations to reach maturity. Perl5 has raw

I for one am extremely excited for Perl6's ecosystem to grow, documentation to increase, and for the performance optimizations to reach maturity. Perl5 has raw text processing power, but Perl6 kicks that into overdrive with a much cleaner language (clean and powerful OO with a MOP), with cool goodies from a dozen other languages. I think this may be the first decent contender for the 100 year language if it becomes production worthy.

collyw 11y ago
Perl gets proper OOP, as now that OOP seems to be out of fashion! (I wish the fashion part of our industry would disappear and people would use the correct tools appropriately. OOP still has plenty of valid cases in my opinion).
- zaphar 11y ago
  OOP isn't out of fashion, per se, I don't think. Inheritance is what really went out of fashion. Part of the problem, I think, is that people use OOP and Inheritance interchangeably too much. objects are just syntax sugar for a closure or a set of curried functions. As such they are useful. It's inheritance that gave OOP a bad name.
  - raiph 11y ago
    I still recall reading ECOOP papers in the 80s that made it very clear that composition is a much better approach for most things than inheritance (and that a single inheritance mechanism is generally much simpler than a multiple inheritance one). But, while Larry Wall agreed in the sense he put emphasis on features such as roles (cf Haskell type classes) he has also said that there are some important scenarios in which inheritance (and very occasionally multiple inheritance) make coding a solution to a problem more straightforward where use of composition makes it less so, so standard Perl 6 supports both composition (eg roles) and (multiple) inheritance and the compiler (which is written in Perl 6) uses one or the other based on whichever is deemed to work best.
- tyingq 11y ago
  >>Perl gets proper OOP Curious what about Perl 5 OOP makes it not proper. Is is just the required constructor boilerplate, like bless()? Or is it the lack of enforced private methods? Neither seems like a showstopper to me...honestly curious.
  - collyw 11y ago
    Perls OOP was an afterthought and it does feel a bit of an add on rather than a core part of the language. Having said that I got my first job using Perl after learning Java at university. It actually helped me understand OOP and inheritance a lot better because it was so transparent compared to Java's OOP which seemed more of a black box - it worked but I never really knew how.
jqm 11y ago
"100 year language..." God I sure hope not. (Only if it's a lot easier to maintain than Perl 5 maybe...) I have bad feelings about Perl after having to parse and cleanup a bunch of abominably written multi-thousand line pages full of regular expressions and all manner of cleverness. I mean, I actually hated Perl so badly I believed it was the worst invention ever. Then I saw a well written project and was easily able to understand and felt slightly less negative. So it's not entirely the language, but to this day seeing 'Perl' brings negative emotions to the surface. Something like PTSD I guess. It will probably take 100 years for that to go away and me to willingly look at anything called 'Perl'.
- tyingq 11y ago
  Personally, I think a lot of the bad Perl code people have had to deal with relate back to three things. a) Many of people writing the code were sysadmins that just needed to get a job done, and didn't have much real development experience. b) Perl was also easy to get access to in cheap shared hosting environments, so it attracted other people without some development discipline. c) Perl4 did not have objects, and scoping was limited to local(). Thus, lots of spaghetti code and global vars. However, none of that would have gotten exposed to developers if their teams had decent interviewing techniques, or code review, etc. All that to say that Perl 6 shouldn't have the same propensity for bad code to end up in a real project. Any more than any other language that is. I can certainly misuse regexps, lambas and other features and write some hard to maintain Python.
- kbenson 11y ago
  Believe me, I've seen bad Perl[1]. Luckily I was already very familiar with Perl, so I was able to discern that the developer was just batty. 1: Global variables everywhere. Every function call did not pass arguments, but instead they assigned data to global variables in the immediately preceding lines, called the function, and then used those global variables. Copious use of SQL where every query was saved in a variable called $stmtA, $stmtB or $stmtC, depending on how many levels of sub-querying needed to be done in a loop. Obscure variable names in general. Zero comments. No use of modules, everything in one flat text file (for 5-10 or more flat text files), no code reuse. PHP used in the same project, to the same standard (one large sprawling multi-thousand line PHP file). This was an open source project, and to this day I wonder if possibly it was all a purposeful design decision, so they could charge for development requests.

collyw 11y ago

Perl gets proper OOP, as now that OOP seems to be out of fashion! (I wish the fashion part of our industry would disappear and people would use the correct tools appropriately. OOP still has plenty of valid cases in my opinion).

zaphar 11y ago
OOP isn't out of fashion, per se, I don't think. Inheritance is what really went out of fashion. Part of the problem, I think, is that people use OOP and Inheritance interchangeably too much. objects are just syntax sugar for a closure or a set of curried functions. As such they are useful. It's inheritance that gave OOP a bad name.
- raiph 11y ago
  I still recall reading ECOOP papers in the 80s that made it very clear that composition is a much better approach for most things than inheritance (and that a single inheritance mechanism is generally much simpler than a multiple inheritance one). But, while Larry Wall agreed in the sense he put emphasis on features such as roles (cf Haskell type classes) he has also said that there are some important scenarios in which inheritance (and very occasionally multiple inheritance) make coding a solution to a problem more straightforward where use of composition makes it less so, so standard Perl 6 supports both composition (eg roles) and (multiple) inheritance and the compiler (which is written in Perl 6) uses one or the other based on whichever is deemed to work best.
tyingq 11y ago
>>Perl gets proper OOP Curious what about Perl 5 OOP makes it not proper. Is is just the required constructor boilerplate, like bless()? Or is it the lack of enforced private methods? Neither seems like a showstopper to me...honestly curious.
- collyw 11y ago
  Perls OOP was an afterthought and it does feel a bit of an add on rather than a core part of the language. Having said that I got my first job using Perl after learning Java at university. It actually helped me understand OOP and inheritance a lot better because it was so transparent compared to Java's OOP which seemed more of a black box - it worked but I never really knew how.

jqm 11y ago

"100 year language..." God I sure hope not. (Only if it's a lot easier to maintain than Perl 5 maybe...) I have bad feelings about Perl after having to parse and cleanup a bunch of abominably written multi-thousand line pages full of regular expressions and all manner of cleverness. I mean, I actually hated Perl so badly I believed it was the worst invention ever. Then I saw a well written project and was easily able to understand and felt slightly less negative. So it's not entirely the language, but to this day seeing 'Perl' brings negative emotions to the surface. Something like PTSD I guess. It will probably take 100 years for that to go away and me to willingly look at anything called 'Perl'.

tyingq 11y ago
Personally, I think a lot of the bad Perl code people have had to deal with relate back to three things. a) Many of people writing the code were sysadmins that just needed to get a job done, and didn't have much real development experience. b) Perl was also easy to get access to in cheap shared hosting environments, so it attracted other people without some development discipline. c) Perl4 did not have objects, and scoping was limited to local(). Thus, lots of spaghetti code and global vars. However, none of that would have gotten exposed to developers if their teams had decent interviewing techniques, or code review, etc. All that to say that Perl 6 shouldn't have the same propensity for bad code to end up in a real project. Any more than any other language that is. I can certainly misuse regexps, lambas and other features and write some hard to maintain Python.
kbenson 11y ago
Believe me, I've seen bad Perl[1]. Luckily I was already very familiar with Perl, so I was able to discern that the developer was just batty. 1: Global variables everywhere. Every function call did not pass arguments, but instead they assigned data to global variables in the immediately preceding lines, called the function, and then used those global variables. Copious use of SQL where every query was saved in a variable called $stmtA, $stmtB or $stmtC, depending on how many levels of sub-querying needed to be done in a loop. Obscure variable names in general. Zero comments. No use of modules, everything in one flat text file (for 5-10 or more flat text files), no code reuse. PHP used in the same project, to the same standard (one large sprawling multi-thousand line PHP file). This was an open source project, and to this day I wonder if possibly it was all a purposeful design decision, so they could charge for development requests.