Re: Multisubs and multimethods: what's the difference?

On Wed, Mar 01, 2006 at 09:09:30PM -0700, Joshua Choi wrote: : Kudos to all the Perl 6 mailing list. Not to mention all the people on the list... :-) : What's the difference between : multi sub infix:<..> ( Int $min, Int $max ) { ... } : and : multi method infix:<..> ( Int $min, Int $max ) {

Multisubs and multimethods: what's the difference?

Kudos to all the Perl 6 mailing list. What's the difference between multi sub infix:<..> ( Int $min, Int $max ) { ... } and multi method infix:<..> ( Int $min, Int $max ) { ... } ? And in the case there isn't one, what's the point of declaring if it's a "sub" or "method"; why not just "multi"

Re: Trends in Code Quality

I'm with Aristotle. I think it's an urge that's come out of the development community -- specifically, *certain* development communities -- rather than from an end-user desire for quality. Many of the best -tested pieces of software are the infrastructure type things that only developers

Re: [PATCH] Compiling Parrot on NetBSD

Steve Peters wrote: Thanks to the work that's already been done, it was very easy to get NetBSD up and running. The attached patch is all that's needed to add NetBSD support to Parrot. I should add that it passes all test too :) Steve Peters [EMAIL PROTECTED]

[PATCH] Compiling Parrot on NetBSD

Thanks to the work that's already been done, it was very easy to get NetBSD up and running. The attached patch is all that's needed to add NetBSD support to Parrot. Steve Peters [EMAIL PROTECTED] +# Copyright: 2006 The Perl Foundation. All Rights Reserved. +# $Id$ + +package init::hints::net

Re: Trends in Code Quality

On Wednesday 01 March 2006 03:27, Jeffrey Thalhammer wrote: > Thanks for this. I've heard the term "Technical Debt" > a few times lately and I really like it. Unlike a > financial debt however, there is a possibility that > the principal and interest won't have to be paid. A > poor implementati

Re: make error on 9188

On Monday 27 February 2006 16:43, chromatic wrote: > On Monday 27 February 2006 16:35, Beau E. Cox wrote: > > Is it me or thee? Any ideas out there? > > I'm seeing the same thing on Linux PPC. > > -- c c - Did you have a chance to try my patch? If so, did it work? -- Aloha => Beau;

Re: Trends in Code Quality

* Dominique Quatravaux <[EMAIL PROTECTED]> [2006-03-01 14:20]: >Yours is a *very* interesting bookmark collection. Do you have >more? I have a collection at . Disclaimer: it’s far from complete, of course. I try to keep to really meaty stuff, so less gets added than

Re: User stack: Worthwhile?

I don't use the user stack, myself, but one advantage that the current implementation has over "just using a PMC" is that you don't have to go out and get the global PMC you're storing things in. We already have at least one language implementation that used to work just fine using the stac

Re: Trends in Code Quality

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A. Pagaltzis wrote: > > It has to be *REALLY* awful though. See Joel Spolsky on rewriting > from scratch[1] (the gist: *never* do it!). > > [1]: http://www.joelonsoftware.com/articles/fog69.html > > [...] If you want to equip programmers to ta

User stack: Worthwhile?

From: Chip Salzenberg <[EMAIL PROTECTED]> Date: Mon, 27 Feb 2006 09:46:42 -0800 On Fri, Feb 24, 2006 at 12:57:24AM +0100, Leopold Toetsch wrote: > That's indeed an (indirect) answer to the 'do we really need it' part ;) Is there any other client of the user stack that can't be eas

Re: Best practice for version control of locally installed CPAN modules

Michael Peters writes: > Krang keeps a local copy of all of the CPAN modules it uses in it's > source repo. Also, each module is installed locally to krang so that > it can be installed without affecting an existing installation. ... We've used software that does things like that; I think the OT

Re: Trends in Code Quality

> If you want to equip programmers to talk to > management, don’t > forget to give them this link: > http://www.martinfowler.com/bliki/TechnicalDebt.html Thanks for this. I've heard the term "Technical Debt" a few times lately and I really like it. Unlike a financial debt however, there is a p

Re: Parrot vs NekoVM

On Feb 28, 2006, at 1:59 PM, Nicolas Cannasse wrote: On Feb 28, 2006, at 12:09, Nicolas Cannasse wrote: Yesterday I did a quick fib(30) benchmark comparing Parrot Win32 daily build (using jit core) and NekoVM (http://nekovm.org). The results are showing that Parrot is 5 times slower than N

Re: Trends in Code Quality

* Jeffrey Thalhammer <[EMAIL PROTECTED]> [2006-03-01 11:05]: >>> By lowering maintenance costs via quality control, managers >>> can avoid (or at least postpone) having to scrap their entire >>> system and rebuild from scratch in India. >> >> I think this is a bit of a stretch. > >I'm in the middl

Re: Trends in Code Quality

> If you're talking to a bunch of perl mongers I > recommend talking about > perl instead of spouting management-speak. The > Republic Of Ireland has > nothing to do with perl programming. I can appreciate that, but I have to believe that no one likes writing crappy code. And more so, no one l

Re: Trends in Code Quality

Jeffrey Thalhammer wrote: Is that still too much of a stretch? Should I forget about the outsourcing stuff and just focus on the ROI aspects? If you're talking to a bunch of perl mongers I recommend talking about perl instead of spouting management-speak. The Republic Of Ireland has nothin

Re: Trends in Code Quality

> >By lowering maintenance costs via quality control, > managers can > >avoid (or at least postpone) having to scrap their > entire system > >and rebuild from scratch in India. > > I think this is a bit of a stretch. I'm in the middle of one such situation. I have inherited a 500k line legacy sy

Re: Trends in Code Quality

On 3/1/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote: > In my experience it has more to do with the particular > programming community. In Java and Perl, there is a lot of > emphasis on testing. I don't know about its prevalence in the > Ruby or Python or other communities, but there is definitely > a

Re: Trends in Code Quality

Hi Jeffrey, * Jeffrey Thalhammer <[EMAIL PROTECTED]> [2006-03-01 09:40]: >By lowering maintenance costs via quality control, managers can >avoid (or at least postpone) having to scrap their entire system >and rebuild from scratch in India. I think this is a bit of a stretch. >Can you think of an

Trends in Code Quality

Hello everyone- I'm working on a presentation of Perl::Critic for the local perlmongers group. As part of the presentation, I would like to make some comments about the current industry trends around software quality. Basically, I'd like to assert that there is a growing emphasis on software qua