If the yoke of backwards compatibility was thrown off from Perl 5.x, what would you change? And why?
(Short technical overviews rather than detailed rants preferred.)
- Please do not front page this post. Preferably do not upvote it. (Downvote at your choice.)
- This is not a anti-Perl 6 post. Nor an attempt to revisit the Perl 6 design process.
And anti-Perl 6 rants are explicitly not solicited.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: What would you change?
by dragonchild (Archbishop) on May 17, 2008 at 03:39 UTC | |
Of course, we can't autobox without a solid OO system. I'd just like to autobox with Moose. But, I can't without a performance penalty that's ridiculous above what tie imposes. So, I don't. My criteria for good software: | [reply] [Watch: Dir/Any] [d/l] |
by monarch (Priest) on May 17, 2008 at 11:46 UTC | |
I am a fan of prototypes. I know it is not recommended in Perl Best Practices because of the danger of someone pushing argments into an array and then passing the array.. e.g. returns the following error:
However, as much as the prototype solution is broken for this situation, I'm still a fan of prototypes. Having prototypes has helped track down a bug in code used in production in a company whereby someone went in and modified the code adding a new parameter to each function. And then a minor bug slipped through whereby a call to one of the functions didn't provide enough arguments. Prototypes would have caught this in the compilation phase. In fact, by adding prototypes to all the functions we caught another instance whereby a function was being called with the wrong number of parameters.. | [reply] [Watch: Dir/Any] [d/l] [select] |
by grinder (Bishop) on May 17, 2008 at 12:54 UTC | |
When adding a new parameter to each call of a function, have the code behave one way with N args, and a different way with N+1. Ideally, by synthesising a default value for the missing parameter, and then going ahead and doing the same thing. There are many ways of working around this sort of codebase evolution. Having the code fail badly because one call was missed is just wrong. Perl is not C. As to the other point, yes it's true that prototypes catch things at the compilation phase, but it doesn't deal with passing a text string when a numeric was expected. For that, Params::Validate is a much more robust approach to ensure parameters are sane, especially in a large code base. • another intruder with the mooring in the heart of the Perl | [reply] [Watch: Dir/Any] |
by almut (Canon) on May 17, 2008 at 14:39 UTC | |
Although I normally neither use nor need prototypes in Perl, I'd still love to see them being extended in such a way that you could make regular Perl functions behave like Perl builtins in every respect (think of overriding print, system, etc.). I've come across some discussion along these lines on p5p (e.g. here), but I think things never went beyond just being discussed. (This is not my entire Perl 5 wishlist, btw, but the other items are still too vague / not thought-out enough yet, that I would dare to present them to this audience :) | [reply] [Watch: Dir/Any] [d/l] [select] |
by dragonchild (Archbishop) on May 19, 2008 at 01:51 UTC | |
My criteria for good software: | [reply] [Watch: Dir/Any] |
by BrowserUk (Patriarch) on May 19, 2008 at 02:43 UTC | |
by dragonchild (Archbishop) on May 19, 2008 at 13:36 UTC | |
| |
Re: What would you change?
by friedo (Prior) on May 17, 2008 at 03:34 UTC | |
I never liked the print syntax. That whole optional-parameter-but-with-no-comma thing really gets my goat. I'd rather just always use select instead of sticking the filehandle in the print statement, but I don't. It eats me up inside, I tell you. I can never remember what the syntax is for taking a slice on a hashref. I have to fiddle with it every time, no matter how many times it comes up. Rather than dealing with an appalling mess of curlies and sigils, I would really liked to have had a slice operator that could be used like my @stuff = slice $href, qw/key1 key2 key3/; Yeah, I could probably write it myself, but I'm lazy. | [reply] [Watch: Dir/Any] [d/l] [select] |
by ikegami (Patriarch) on May 17, 2008 at 03:55 UTC | |
There been an alternative for quite some time.
Works on any handle.
How does adding slice break perl's backwards compatibility? | [reply] [Watch: Dir/Any] [d/l] [select] |
by Porculus (Hermit) on May 17, 2008 at 21:20 UTC | |
Rather than dealing with an appalling mess of curlies and sigils... I can't recall ever wanting to take a slice of a hashref myself, but this line aroused my curiosity, so I investigated to see just how bad it could be. First I went for the naive approach: my @stuff = @$href{ qw/key1 key2 key3/ };And was rather surprised to discover that I'd got it right first try! Perhaps the reason this seems intuitive to me and not to you because I already habitually write $$href{key1} rather than $href->{key1}, so I'm used to using double sigils to dereference things? (Henceforth I shall use this consistency as an argument in favour of my preferred syntax!) | [reply] [Watch: Dir/Any] [d/l] [select] |
by rudder (Scribe) on May 18, 2008 at 03:34 UTC | |
For extra clarity (to me, anyway), I prefer to write it as:
(with the extra curlies). For some reason I never was crazy about the arrow shortcut here. In fact... umm... how do I correctly write the above using the arrow? I can't get it to work. | [reply] [Watch: Dir/Any] [d/l] |
Re: What would you change?
by Limbic~Region (Chancellor) on May 17, 2008 at 23:29 UTC | |
I would change a lot of things. The list goes on and on. On the other hand, I am quite certain that the changes I would make would result in a language that would suit me and likely not many others. I think this is more than just a matter of "take the bad with the good". I think that there is very little that almost everyone can agree should be changed (removed, added, augmented, modified, etc). I can also say with absolute certainty that the things that I would want to change today are not the same things I would have said 3 years ago which wouldn't have been the same things I would have said 6 years ago. Cheers - L~R | [reply] [Watch: Dir/Any] |
by Tux (Canon) on May 19, 2008 at 17:09 UTC | |
funny list :) I would want to keep format, but make it work, and make it actually work, also on lexical file handles, nestable, extendable, versatile etc etc. There are a few useful modules on CPAN already, but none of them actually makes it easy to convert from the good ol' format to what the modules offer. They all have their merrits. Let's bundle and make it useful! I'd throw out threads. Completely. I'd make auto-conversion from 32bit ints to 64bit ints to bignum and vv more native, so you never loose significance on integers I would remove modules from CORE that do not belong in CORE, such as CGI and Text::SoundEx I'd like the TIE system to be more transparant, and work on all data types (currently Tie::Handle is broke, and there is no Tie::Format. Imagine the fun you could have with the latter Enjoy, Have FUN! H.Merijn | [reply] [Watch: Dir/Any] [d/l] [select] |
Re: What would you change?
by jplindstrom (Monsignor) on May 17, 2008 at 19:38 UTC | |
/J | [reply] [Watch: Dir/Any] |
Re: What would you change?
by TimToady (Parson) on May 20, 2008 at 00:32 UTC | |
| [reply] [Watch: Dir/Any] |
by BrowserUk (Patriarch) on May 20, 2008 at 01:32 UTC | |
Indeed :) I hope that the recent benevolence to the TPF is allowed to assist you personally in the goal. The thought train that lead to my asking the question was my starting to wonder if there weren't some minimal subset of changes to Perl 5 syntax and semantics that might act as a halfway house between Perl 5 and Perl 6. A clean break from the backward compatibility yoke, but that required minimal changes to existing sources,in order to accomodate the clean up and removal of long (technically or emotionally) "deprecated" parts of Perl 5 whilst retaining broad compatibility. And whether this cleaned up and enhanced (without extreme additions) language might be sufficiently simpler than the full-blown Perl 6 spec to allow it to a) be avialable more quickly; b) acts as a migration path to the full deal. I realise that there have been several similar proposals (and even starts:Ponie?) in the past, but my thought was that maybe the combination of a) not slavish adherance to Perl 5 compatibilty; b) not the full gusto of Perl 6 enhancements; c) just enough changes to fix a few pertinent, long-standing beefs and wish-list items; might give the idea impetous. However, given the Which only goes to show what a complex and thankless task you set yourself with the open design process you started those years ago, and what a remarkable balancing act you've had to pull to achieve the level of consensus you achieved. I read somewhere earlier today a statement that went something like: "individuals think better than commitees". But at least commitees have finite numbers of minds, and each member represents and filters the desires (aims; goals; prejudices;) of the many minds that sit behinds them. I once flirted with the notion that in the modern, internet-connected world, democracy should replace MPs (political representatives in governmental forums) with one-man, one-electronic-vote, directly upon the issues themselves. The idea is attractive for many reasons, not least because it would render party politics impotent. I've seen it dismissed on various grounds, most commonly the scare-mongering and emminently technologically fixable problem of ensuring security, privacy and freedom from electronic ballot stuffing. I've recently come to realise that the single biggest barrier to the removal of the "representative" from the mix, is the inherent and very valuable filtering role they perform. I do not envy you your task. And if I could see a way of helping, without adding to the drag of controversy, I would. Another quote I read recently comes to mind: "Deliberate with caution, but act with decision; and yield with graciousness, or oppose with firmness." I'm pretty good at two of those, and a third is within my grasp (with some effort). But the fourth is something I've always struggled with and it seems to be getting harder as I get older. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [Watch: Dir/Any] |
Re: What would you change?
by moritz (Cardinal) on May 18, 2008 at 14:22 UTC | |
I admit that most of that (if not all) is bluntly stolen from the Perl 6 synopsis. It's the subset of features I really like, and that could be integrated into perl 5 without making it a different language altogether. | [reply] [Watch: Dir/Any] [d/l] [select] |
Re: What would you change?
by shmem (Chancellor) on May 17, 2008 at 15:10 UTC | |
Preferably do not upvote it. (Downvote at your choice.) Couldn't resist to upvote your post. Downvote mine if you like ;-) I would change bless() to construct an inside-out object incorporating Alter into the core, so that bless { @_ }, $class provides a real inside-out object with a hidden alter ego for free, which is thread-safe, garbage-collected and accessible only inside this object's package:
That way, an object would behave as a normal perl data type if so treated, but as an object calling one of its methods. Private and public attributes for free. No, I haven't thought about all the consequences... --shmem
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: What would you change?
by rhesa (Vicar) on May 18, 2008 at 00:46 UTC | |
Actually, I think the changes I'd most like to see revolve around making perl a bit friendlier towards functional and OO programming. Function/method definition and invocation could be less verbose. See for example Method::Signatures for a step in the right direction (Moose is lovely too, of course). update: Oh, I forgot! I would absolutely love to have lvalue methods that work. I'm getting really tired of having to write $foo->bar( $foo->bar() + $wibble ). I'd like to be able to use more syntax than just ->() once in a while. | [reply] [Watch: Dir/Any] [d/l] [select] |
Re: What would you change?
by Porculus (Hermit) on May 18, 2008 at 14:19 UTC | |
I would fix the expression/block ambiguity in map and similar functions: they do usually DWIM, but there's always that nasty niggling uncertainty... It would be such a simple fix, too! map { ... } could simply always indicate a block, not a hashref expression, which would thus always be written map +{ ... }. Problem solved. | [reply] [Watch: Dir/Any] [d/l] [select] |
Re: What would you change?
by Joost (Canon) on May 20, 2008 at 00:17 UTC | |
And really we should lose all or all but one sigil the whole $/@/% thing is just messing up generic calls.
| [reply] [Watch: Dir/Any] |