Slightly worried about what I've written there. I'm writing about an argument at $work, not with anyone on this list.
]]>Wouldn't it have been great to read that two clever programmers had collaborated and that DateTime version ??? was backward compatable and really flew.
Then the benefits would have gradually crept into our codebase without me getting into another argument about standard modules.
The stats quoted for Time::Moment are impressive.
At a glance, the basic constructor arguments and basic attributes are compatible with DateTime making it a drop-in replacement in some cases.
However, the basic arithmetic operations are different. These are fairly common operations such as adding hours or days. This will make it very limited as a drop-in replacement.
Is there a case for some sort of DateTime::Facade namespace to hold modules which put DateTime compatible wrappers around other date/time modules? There would be an overhead in the extra layer of abstraction, but this might not be large.
]]>People inside the echo chamber know about Metacpan and either use it in preference to search.cpan.org or switch to it if, as is often the case at the moment, search.cpan.org is down.
People outside the echo chamber are less aware of Metacpan. If search.cpan.org is down, they just take it as more evidence that Perl is d**ng.
]]>PBP calls for functions/methods to return explicitly, so I always try and get my team to do that. The reasons given in the book seem fair enough, or would have been fair enough in 2006.
However, there was a lot of noise about Scala in the Perl community about a year ago. As a result I, like many Perl programmers, have been idly looking at it.
Scala also returns the last value if you don't return explicitly. However, that's beeen designed in for a specific reason.
Doing an implicit return (among other things) in Scala allows for tail recursion and massively reduces memory usage during deep recursion.
Does anybody know if Perl optimises using tail recursion?
I suspect it doesn't, but it would be spooky if it did. It would show how advanced Perl was when it came out.
]]>If you use the namespace Javascipt.pm or make Javascript.pm a wrapper around your module then, in theory at least, modules which depend on Javacript.pm should work a bit better.
For example, I've wanted to use JS::JSLint as part of a project test suite for several years. I've never managed to get it to install. On two occasions I've spent a whole morning messing about with it and given up.
Part of the problem is that Spider Monkey is difficult to install and is not provided as a package on many Linux distributions.
Another problem is the Javascript.pm installation process doesn't appear to be very good at detecting Spider Monkey once it is installed. I found myself patching that.
I've never actually got as far as JS::JSLint!
]]>I enjoyed your book on Effective Programming, I even persuaded a couple of local libraries to stock it. I've got a copy of the latest Camel book here, but I've only dipped into it. Surprisingly, the bit I've read is the bit where you laud the format command to the skies. I suspect that was cut and pasted from the previous edition without proof-reading.
I've never achieved any particular pre-eminence, but I can be reasonably confident that I've worked on more development projects than you. It's one of the few certainties that come from getting old.
Much of what you say there is naive and patronising. I can live with being patronised, but you are patronising the other readers as well.
Very few people in any field take "Best Practices" to mean the one and only true way. They mean "Good Practices" or "Recommended Practices". Even in fields where life and death is at stake, people use the "Best Practices" as a starting point and develop project practices. The difference is that you can end up dead or in prison if you deviate without the appropriate authority.
I did not say, or even imply, that I wanted a single set of compulsory rules.
I said that Perl needed a set of rules about which there was reasonable authoratative consensus and that people could use as a baseline. It does.
You don't want to start developing your project standards from a blank sheet of paper every time. Nor, when you are on a new project, do you want to say "Do this because I am wise". You'll spend ages justifying yourself. It's more likely that you'll want to say "Do this because I've done it before, it's recognised as good practice, and all these people agree with me."
Sometimes you'll want to deviate from the standards, sometimes you won't give a damn about standards.
I did not say, or even imply, that I wanted anybody to do a lot of work for free. I do little bits and pieces for the Perl community for free, but I have no intention of doing a lot. Even with the little bits I do, there is a sub-agenda of networking, job protection, paying back favours, etc. Most people are like that.
It sounds like we need a corporate sponsor. Most discussions of this ilk end with that conclusion.
Regards
Duncan
It's also very old.
It makes it very difficult to impose a baseline set of practices on a project team.
I can't see anything in the meditation you tagged about updating PBP, but this seems to come up every couple of years and we never move forward.
Does anybody know what the sticking point is? How many of the differences are just because the book is old? You wouldn't expect a 2005 book to have much about Unicode in it. Damian Conway may have changed his mind on some things in the last 8 years.
Does Damian Conway refuse to update it or allow it to be updated? Do O'Reilly refuse to allow it to be updated? Is the problem that the community can't put together a little team of "name" authors to give an update gravitas? Is the problem money?
Is there a feeling that the new Camel book is the new PBP? (I confess I haven't read those sections in any detail, I always refer to PBP.)
]]>Is this anything to do with it? A glance at the two sets of code indicates that it may not be.
]]>If the goal is identifying modules which need adoption then there should be a qualifying criteria.
I suggest that module which has been released within the last year should not qualify even if its overall score is very high.
As it stands, a module which was released yesterday with a lot of bugs and dependencies could score quite highly.
Similarly, I've been involved in conversations about whether mentioning games programming might get the attention of students.
The SDL library was being pushed quite hard within the Perl community a couple of years ago. I know some people worked hard to make the bindings available.
Armed with this knowledge, I spent half an hour googling games written in Perl. I couldn't find a single non-trivial example. Was I looking in the wrong places or is this another area in which we are kidding ourselves?
]]>I was working on a fresh Ubuntu installation and I couldn't get the Vim syntax highlighting to work. I went to the sys admin and asked him to download the full version of Vim. He knew immediately what I meant and once he had done it I had all the vim features I needed. I didn't have to keep going back.
Later, on the same installation, I couldn't get our Perl modules to install because there wasn't a C compiler. Once I nudged the system administrator, he downloaded a development package and I had all the tools I needed. I didn't need to keep going back for a compiler, for make, etc, etc.
If we go for a thin core, most people are going to want one of the extended cores as well. There might be an extended core for web development, for GUI development, for bio-informatics, for systems administration and so on.
We don't have anything like that. There have been plenty of attempts, but none have caught on.
I think one of the reasons is that they try to specify a single solution. For example Task::Kensho specifies Catalyst. There might be more chance of getting a consensus if it allowed three or four frameworks. Why not Catalyst, Mojo and Dancer?
The idea that "There Is More Than One Way To Do It" has some merit as long as it's not taken to an extreme.
Three or four frameworks? Fine. Thirty or forty? No. Three or four accessor modules? No worries. One hundred and twenty? No.
]]>