DAxelrod's Journal http://use.perl.org/~DAxelrod/journal/ DAxelrod's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:24:51+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 DAxelrod's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~DAxelrod/journal/ MMU Announced [News from an Alternate Timeline] http://use.perl.org/~DAxelrod/journal/33877?from=rss <p>In a press release today, Imtel announced a new processor hardware component, called a Memory Management Unit.</p><p>"The MMU will supplement our existing VX-t technology in offloading virtualization overhead to the processor itself," said Imtel's Bob Brooke.</p><p>While it has been possible for years to give applications the illusion of controlling the computer's entire memory address space, the in-software techniques employed by hypervisors have always meant taking a performance hit, especially when it was necessary to swap memory to disk. The MMU allows applications to send instructions directly to the processor, negating the need for a software-based address translation layer.</p><p>But Imtel claims the biggest benefit will be hardware-enforced "memory protection", ensuring that different applications cannot read or modify each others' memory. Brooke went on to claim, "The <a href="http://linux.slashdot.org/linux/07/07/24/0218242.shtml">containerization</a> benefits of the MMU will provide unparalleled levels of security."</p><p>VMWear's Chan Du declined to comment specifically when asked if the MMU would be utilized by their upcoming hypervisor technology, the so-called Operating System Kernel. He would only say, "Operization Technology will provide many new ways to abstract hardware from individual applications, but it is our policy to not discuss features of unreleased products."</p> DAxelrod 2007-07-25T01:26:13+00:00 journal Concurrency and assumptions http://use.perl.org/~DAxelrod/journal/32445?from=rss <p>I'm convinced that some problems are considered hard mainly because they're really good at exposing unquestioned assumptions at different levels of a system.</p><p> <a href="http://ridiculousfish.com/blog/archives/2007/02/17/barrier/">Barrier</a> <a href="http://www.thinkingparallel.com/2007/02/19/please-dont-rely-on-memory-barriers-for-synchronization/"> Please Don&#8217;t Rely on Memory Barriers for Synchronization!</a> <a href="http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf">C++ and the Perils of Double-Checked Locking</a> <br>Barrier <a href="http://www.algorithm.com.au/blog/files/the-problem-with-threads.html">The Problem with Threads</a> <a href="http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html">The Problem with Threads</a> </p><p>In concurrency, one of those levels having its assumptions challenged is the programmer, but that's not the only reason it's hard.</p> DAxelrod 2007-02-20T02:59:17+00:00 journal Perfection can only be approximated http://use.perl.org/~DAxelrod/journal/32291?from=rss <p>If you don't know why a particular tool sucks, you haven't been using it for long enough.</p><p>This is especially true for programming languages and software.</p><p>Counterexamples welcome.<nobr> <wbr></nobr>:)</p> DAxelrod 2007-02-01T04:02:53+00:00 journal Bad reasons you should learn C. http://use.perl.org/~DAxelrod/journal/31761?from=rss <p>Beatnik's <a href="http://use.perl.org/~Beatnik/journal/31751">response</a> to an <a href="http://www.jubling.com/ten-reasons-why-every-programmer-should-learn-c.html">unconvincing argument for learning C</a> got me thinking. Here's my response. </p><blockquote><div><p>2) Device drivers and operating systems are written exclusively in C. Now, you may never write a device driver or an operating system, but what if you are ever required to modify one?</p></div></blockquote><p> Rare modification of device drivers aside; I think a better reason (sorta related to this) is that C was designed to write Unix in. Learning C may allow you to learn more about the internals of your OS.</p><blockquote><div><p>4) C programs are smaller and faster then any other program created in a different language. Sometimes your program needs that speed boost that only C can give it.</p></div></blockquote><p>False. Sorry, but this is no longer the case. Compiler research has come a long way.</p><p>For example, look at perl's highly fine-tuned regular expression engine written in C. <a href="http://weitz.de/cl-ppcre/">CL-PCRE</a>, a Perl-compatible regular expression library written in Lisp, <a href="http://weitz.de/cl-ppcre/#performance">claims to outperform perl's</a> (when compiled with <a href="http://www.cons.org/cmucl/">CMUCL</a>). Yes, there are many problems whose C implementations are faster, but this does not hold true for all programs or all architectures.</p><blockquote><div><p>5) If you have learned C, you can learn any modern programming language. The reason behind this is that all modern programming languages are based on C</p></div></blockquote><p>Many programming languages have syntax that's kind of like C. But all? Scheme is based on Lisp. Prolog is almost nothing like C. As isn't Haskell. I have trouble believing that SQL and C share much in the way of parentage. XSL? I could go on.</p><p>Much more important than syntax is paradigm. My problem with the "learn C and you can learn anything" argument is that maybe if you learn C you can learn other procedural languages. Knowing C ain't gonna get ya very far in learning functional or logic programming. And most of the languages that <i>are</i> based on C have powerful language constructs that C lacks. Closures, for example.</p><blockquote><div><p>8) C is the only language that teaches you what pointers really are. C# and Java skip the subject completely. It is pointers that give C its power.</p></div></blockquote><p>A power we have yet to fully understand how to harness. Like goto. The indirection role is played by references in Perl and equivalents in other languages. The continguous addressable block of memory space? Arrays and iterators mostly take care of that. The fact that dynamically allocated memory is only accessible through indirection is not a feature, though.</p><p>Face it, C's pointers (and the language infrastructure they're related to) are the reason buffer overflows exist. Let's figure out how to stuff them back into Pandora's box before they become widespread. Oh wait, we didn't.</p><p>I can see the power of C's pointer implementation because it allows for all kinds of crazy Turing-machine possibilities. With those possibilities come risk.</p><blockquote><div><p>9) C is still the most commonly required language for programming jobs.</p></div></blockquote><p>My gut feeling is that the language of choice for PHBs these days is Java, but I have no data to back up my assertion either.</p><blockquote><div><p>10) Anything that has a microprocessor in it has support for C. From your microwave to your cell phone, C powers technology.</p></div></blockquote><p>I could sort of see this argument being valid if you were talking about IA32 (which seems to have a lot of C primitives as instructions), but otherwise not so much. The processor has no support for C.</p><p>If you want to argue almost every architecture has a C compiler for it, you'd be a lot closer. Some of this is because C is self-hosted, but some is also because C is good for getting close (but not too close) to hardware.</p><p>Please note that I am not trashing C. I happen to think it is also worth learning, for different reasons. I'll have to write those down later.</p> DAxelrod 2006-11-30T02:21:30+00:00 journal When read-only isn't http://use.perl.org/~DAxelrod/journal/31476?from=rss <p>Step up, one and all, and see me modify a simple scalar only by reading it. Nothing up my sleeves.</p><p> <code> my ($num, $let, $foo);<br> $num = "z";<br> $let = $num;<br> #$foo = 1 + $num; #this does not modify $num<br> $num++; $let++;<br> print "num:$num let:$let\n";<br> __END__<br> Output:<br> num:aa let:aa<br> <br> Output with 1+$num line uncommented:<br> num:1 let:aa<br> </code></p><p>This means we have a line that makes no assignment to a variable, but still changes that variable.</p><p>Critics will call this dangerous and unexpected action at a distance. Proponents will note that a warning is triggered, read-only statements are still an indication of What You Mean, and that this probably makes <i>excellent</i> fodder for obfus.</p><p><small>Admittedly, this is (sorta) documented. <a href="http://perldoc.perl.org/perlop.html#Auto-increment-and-Auto-decrement-increment-auto-increment-%2B%2B-decrement-auto-decrement---">Perlop</a> mentions "If, however, the variable has been used in only string contexts since it was set," the ++ operator acts differently.</small></p><p> <a href="http://use.perl.org/comments.pl?sid=33442&amp;cid=51303">Abigail's comment</a> to <a href="http://use.perl.org/~jjore/journal/31415">this discussion about side effects</a> inspired this experiment^W magic trick.</p> DAxelrod 2006-11-01T20:38:32+00:00 journal Side-effects create dependencies http://use.perl.org/~DAxelrod/journal/31427?from=rss <p> <a href="http://use.perl.org/~jjore/journal/31415">All this discussion of side-effects</a> has reminded me of something.</p><p>A particular bit of code has, potentially, a return value, and side-effects. Other parts of the program have a dependency on a bit of code if they rely on either the code's return value, or side-effects. Think of return values as explicit dependencies, and side-effects as implicit dependencies.</p><p>Purely functional programming languages are easier to paralellize because all of the dependencies in the code are explicit.</p><p>It would seem that parallelization of non-functional programming languages would be possible (without explicit design by the programmer) if we had a better way of analyzing code to map out dependencies.</p><p>I'll expand on this a little bit when I have more time.</p> DAxelrod 2006-10-26T21:08:58+00:00 journal The False Dichotomy of Content vs. Presentation http://use.perl.org/~DAxelrod/journal/31361?from=rss <p>I unfortunately can't find the source right now, but there's a bit of wisdom that says that programs are written primarily to communicate with humans, and secondarily to communicate with compilers.</p><p>I bring this up because of the quote at the top of <a href="http://use.perl.org/article.pl?sid=06/10/19/1230210">this perl5-porters summary</a>.</p><p>Many of our furious debates over code style, especially whitespace formatting, are annoying precisely because they deal with code at only the human level. The compiler usually doesn't care about tab-stop preferences.</p><p>So I started thinking about being able to mark diffs as style changes versus code changes, so that version control history is preserved because you can query only the diffs that actually change how the program runs. I had some ideas about schemes involving some bizzare combination of <a href="http://perltidy.sourceforge.net/">perltidy</a>, <a href="http://search.cpan.org/perldoc?PPI">PPI</a> (which can losslessly roundtrip code), <a href="http://search.cpan.org/perldoc?B::Bytecode">B::Bytecode</a>, and optree comparisons.</p><p>And then I realized maybe this wasn't such a great idea.</p><p>Something a lot of people in web design have been struggling with for years is how to separate content and presentation. Of course, the two really can't be completely separated. Say you have content that is structured purely on the basis of semantics. You <i>want</i> its display to reflect certain aspects of its structure.</p><p>It's really similar to trying to separate data and code. Everyone agrees that abstractly it's a good idea so you don't have problems like buffer overflows and SQL injection attacks. But some of the most powerful things computers are capable of require crossing the boundaries of data and code. Turing Machines are powerful for the precise reason of having data-that-is-also-code.</p><p>It's all nice for me to say the two should be separate, but it's an unrealistic oversimplification.</p> DAxelrod 2006-10-19T20:22:16+00:00 journal Sobering http://use.perl.org/~DAxelrod/journal/31295?from=rss <p>My heart goes out to the <a href="http://news.google.com/news?q=Nina+Reiser">Reiser</a> family.</p><p>Comments turned off, becuase I've already been saturated with discussion on this elsewhere.</p><p>CromeDome <a href="http://use.perl.org/~CromeDome/journal/31291">wrote about his reaction</a> to the nature of the discussion, though.</p> DAxelrod 2006-10-11T19:26:55+00:00 journal A license (clause) to kill http://use.perl.org/~DAxelrod/journal/31284?from=rss <p>If I do not use "the same terms as Perl itself", would that prevent <b>you</b> from using my code (especially CPAN modules)? Contributing to it? Distributing it? (<b>EDIT</b>: Not so much from a legal basis as if you'd decide "I don't want to have to figure out the legal crap here" and just give up. <b>ENDIT</b>)</p><p>This <a href="http://thread.gmane.org/gmane.linux.kernel/448894/focus=450619">thread</a> on the LKML is fascinating. Let's put aside discussions of the GPLv3 for a second and look at another argument Linus made in that thread, that the "or any later version" clause essentially means that you're agreeing to license your code under the terms of a license you haven't seen. I buy his argument, and so I'm trying to figure out how to license further code I work on.</p><p>Now, previously, when licensing FOSS Perl stuff I've written, I've used "the terms of Perl itself", nice, easy, and license-compatible with most other Perl stuff.</p><p>Well, <a href="http://search.cpan.org/src/DAXELROD/Class-LazyObject-0.10/LICENSE">the terms of Perl itself</a> include the "or (at your option) any later version" clause. (The version of the GPL they specify is also Version 1, which I'm not actually sure I've read.)</p><p>The "terms of Perl itself" <a href="http://dev.perl.org/perl6/rfc/346.html">might also change</a>, to use the <a href="http://www.perlfoundation.org/legal/licenses/artistic-2_0.html">Artistic License 2.0</a> though I haven't kept up with the discussion on that front.</p><p>So ideally what I'd like to do is license my code under the Artistic License 1.0 (or whatever the canonical name is for the current Artistic License) or the GPLv2.</p><p>Would this cause problems for others?</p><p>Because ultimately, if it will, I might decide that contributing code that people can use is more important than the rest of this licensing stuff. I welcome your input.</p><p> --- </p><p><small>Please note that I'm not asking for legal advice. I'm asking about how your actions would be influenced.<br>Also note that if I were to contribute to someone else's project, I would most likely license my code under whatever terms they had chosen to license their code.</small></p> DAxelrod 2006-10-10T19:05:34+00:00 journal OT: MarkovSpammer&#8482; http://use.perl.org/~DAxelrod/journal/31268?from=rss <p>I was really starting to miss jjohn's <a href="http://use.perl.org/~jjohn/journal/22443">MarkovBlogger</a>. Until I started getting what looks to be Markov-generated-spam. Usually it's just annoying but this one (which failed to actually advertise anything) was hillarious.</p><p>If Kafka, ee cummings, and Kent Beck all had a child who was dropped in its head repeatedly, the child might one day create this:</p><blockquote><div><p> <code> From: Mohammad Rutherford<br> Subject: Watch Chavez </code> </p><p> so that you can spend (and impress cocktail party guests) challenging. Something But you don't just of the best practices be wrong (and what somewhere in the world</p><p>Patterns--the lessons more complex. (and too short) to spend somewhere in the world how patterns are the same software deep understanding of why patterns look in you don't want to words, in real world you have. You know when he casually mentions</p><p>also want to learn be wrong (and what In a way that lets you put sounds, how the Factory of Design Patterns so used in the Java API<br> and why everything<br> look "in the wild". a design paddle pattern. so you look to Design want to see how science, and learning theory,</p><p>so that you can spend up a creek without challenging. Something the embarrassment of thinking so that you can spend neurobiology, cognitive it struggling with academic In their native applications. You challenging. <br>Something<br> used in the Java API same problems.<br> Singleton isn't as simple as it</p><p>your time is too important </p><p>it struggling with academic to use them (and when when he casually mentions (and impress cocktail party guests)<br> your time on...something design problems<br> Head First book, you know</p><p>when he casually mentions</p><p>Head First Design Patterns so that you can spend brain in a way that sticks. is so often misunderstood,<br> on your team. when he casually mentions <br> alone. At any given moment,</p><p>alone. At any given moment,</p><p>patterns look in who've faced the You'll easily counter with your alone. At any given moment,<br> "secret language" a design paddle pattern. reinvent the wheel<br> you have. You know Something more fun. design problems</p><p>, and how to exploit Design Patterns, you'll avoid his stunningly clever use of Command, In their native of Design Patterns so to use them (and when a book, you want<br> on your team.<br> support in your own code. neurobiology, cognitive<br> Best of all, in a way that won't <br> up a creek without Best of all, in a way that won't<br> learned by those</p><p>them to work immediately. reinvent the wheel what to expect--a visually-rich Best of all, in a way that won't to do instead). You want <br> when to use them, how With Design Patterns, matter--why to use them, (and too short) to spend <br> of patterns with others of patterns with others want to see how of patterns with others who've faced the<br> advantage<br> somewhere in the world<br> will load patterns into your of patterns with others Head First book, you know real OO design principles the patterns that </p><p>them to work immediately. texts. If you've read a better at solving software</p><p>between Decorator, Facade who've faced the <br> design problems who've faced the be wrong (and what challenging. Something his stunningly clever use of Command, sounds, how the Factory<br> be wrong (and what</p><p>Something more fun. </p></div> </blockquote><p> <small>BTW, does use.perl have something equivalent to Perlmonks's <code>readmore</code> tags?</small></p><p> <b>Edit:</b>Dear lord. I just got another one that obviously uses Hitchhiker's Guide to the Galaxy as one of its source texts.</p> DAxelrod 2006-10-09T20:33:31+00:00 journal Which win32 perl flavor? http://use.perl.org/~DAxelrod/journal/31239?from=rss <p>Unfortunately, even the best of us are sometimes forced to use Windows.</p><p>Which perl would you recommend on Windows for somebody doing development work in Perl? I'm unlikely to be writing XS, although I might need XS modules. Note that this will not be running production software, so I don't need something stable as in Debian-stable.</p><p>Perl under Cygwin? ActiveState? Vanilla? Strawberry? Something else completely?</p> DAxelrod 2006-10-06T14:06:27+00:00 journal OT: I &lt;3 NJ http://use.perl.org/~DAxelrod/journal/31207?from=rss <p>My reaction to <a href="http://arstechnica.com/journals/apple.ars/2006/10/2/5475">this</a>:</p><p> <i>A while ago...</i> <br> <b>NJ Legislator 1:</b> So, if we count that pile of dollar bills <em>three times</em>, it means we have more money! <br> <b>NJ Legislator 2:</b> But we don't have more money, we've just counted wrong. <br> <b>NJL1:</b> Not "wrong". <em>Differently!</em> <br> <b>NJL2:</b> Uh, you think the public will fall for that? <br> <b>NJL1:</b> Sure! Even though they dump a huge percent of their high property taxes into schools, they don't know enough math to catch it, and they don't have enough civic responsibility to care!</p><p> <i>Later...</i> <br> <b>McGreevy:</b> I'm a Gay American. <br> <b>NJ:</b> Dude, it's 2004. No one cares if you're having orgies with midgets and Koala bears. <br> <b>McGreevy:</b> And while your heart is bleeding for me, the powerless repressed minority who, uh, holds most powerful office in the state... <br> <b>NJ:</b> <em>Sigh</em>. What? <br> <b>McGreevy:</b> I've been funnelling large amounts of your tax dollars to my lover! But buy my book about it! <br> <b>NJ:</b> Dammit! Get out of office! <br> <b>McGreevy:</b> I can see you're not yet tolerant enough to accept me. Fine. I'll step down. In a few months. Buy my book. <br> <b>Interim Governor:</b> You didn't elect me, but I actually don't suck! Democracy works!</p><p> <i>Later...</i> <br> <b>NJ Supreme Court:</b> Hey, Legislature? <br> <b>NJ Legislature:</b> What is it? Want more caviar or bling? <br> <b>NJSC:</b> No. Listen, you gotta stop this crazy accounting crap. <br> <b>NJ Legislature:</b> Uh, sure thing. It'll take effect <em>after</em> we're all out of office and our predecesors will have to deal with the fallout. <br> <b>NJSC:</b> Sorry. Come up with a non-fantasy budget before you adjourn for the summer. <br> <b>NJL:</b> Aww, but I was just about to ship off to Aruba on taxpayer dollars! <br> <b>New Governor:</b> No. I'm locking you in the freakin' building until you come up with a budget.</p><p> <i>Now...</i> <br> <b>NJ Legislature:</b> Ok, everybody. We're raising taxes- <br> <b>Public:</b> -We don't have to pump our own gas now, do we? <br> <b>NJL:</b> No. Nobody even mentioned that. <br> <b>Public:</b> Well, it always comes up whenever anybody talks about New Jersey. <br> <b>NJL:</b> Listen, we're also making you pay for media downloads and shipping and handling. That'll mostly affect younger citizens. <br> <b>18 Year Old NJ Citizen:</b> Dammit! If I cared enough to vote, I would <em>so</em> get rid of this government! <br> <b>McGreevy:</b> Buy my book! <br> <b>Citizen:</b> No. I'd have to pay taxes on shipping and handling.</p><p> <b>DISCLAIMER</b> <br>Facts have been bent for humor's sake. Feel free to correct me in the comments.</p> DAxelrod 2006-10-03T16:53:00+00:00 journal Testing Installed Modules: Opening a Can of Worms http://use.perl.org/~DAxelrod/journal/31018?from=rss <p>Ovid recently asked what should be a simple question: <a href="http://perlmonks.org/?node_id=572344">How should we install tests along with modules?</a> </p><p>Of course, this is not a simple question at all and breaks down into several distinct problems. The first is actually <b>"How do we test an installed module?"</b> </p><p>kwilliams responded with the brilliant idea of a Module::Build retest action, that would look for modules in @INC instead of blib.</p><p>Unfortunately, this doesn't completely solve our first problem.</p><p>Why? Because way too many tests are written with the assumption that they will be running from within an unpacked module distribution. Which means they require <b>context</b> outside of the installed<nobr> <wbr></nobr>.pm files.</p><p>Off the top of my head, the kinds of tests that have this problem include </p><ul> <li>Tests that pull in specific files from the distribution <ul> <li>Tests that pull in test modules not in blib</li><li>Tests for scripts installed with the module</li><li>Tests that pull in data files (which may end up being installed)</li></ul></li> <li>Tests that depend on the whole distro structure <ul> <li>Test::Signature</li><li>Test::Distribution</li><li>Test::Pod</li><li>Test::Pod::Coverage</li><li>tests that rely on the MANIFEST</li><li>tests that scan files for spelling errors, minimum versions, or prereqs</li></ul></li></ul><p>You could argue that any of these that are abstracted into Test::Whatever modules have enough of a layer of indirection to account for however you test installed modules. But I think that misses the point. A list that large is not evidence of special cases. It's evidence that it's important for tests to have more than the<nobr> <wbr></nobr>.pm alone.</p><p>One solution that sucks could be a way of marking which tests assume they're being run in a distribution and which ones don't care. That would be horribly tedious.</p><p>Maybe this is evidence that we need a metadata database to go with our installed modules. We already have a PACKLIST that sorta kinda serves as an installed module database. The problem is, now we need an API for tests to query that database.</p><p>Maybe we're going about this wrong. Tests need a distribution. Modules work in a distribution and out of a distribution. It's common to develop modules inside a distribution.</p><p> <b>Why not install an entire module distribution?</b> </p><p>Have a lib-like directory which is searched for entire distributions rather than just<nobr> <wbr></nobr>.pm files. When you use a module, it will actually be pulled from its distribution.</p><p>Running modules from within distributions? Doesn't that sound like <a href="http://search.cpan.org/perldoc?PAR">PAR?</a> </p> DAxelrod 2006-09-16T18:53:26+00:00 journal OT: Law is not Code http://use.perl.org/~DAxelrod/journal/30978?from=rss <p>I've read several times now that computer geeks don't usually take the same approach to law as, say, lawyers. For example Eben Moglen <a href="http://www.fsfeurope.org/projects/gplv3/barcelona-moglen-transcript.en.html#q11-patent-retaliation-freedom">characterized this</a> as "the hacker belief that laws are form of code that are executed without errors or ambiguities." <b>EDIT:</b> Alias rightly points out that this is a strawman. I think a statement closer to what I'm getting at might be "the hacker belief that laws are a form of code that <i>are intended</i> to be executed without errors or ambiguities". <b>End Edit</b></p><p>I'm starting to see why that might be the case.</p><p>Something that fascinates me is how the US Supreme Court has bootstrapped itself into its current role. (Basically, for those unfamiliar, a lot of what the US Supreme Court does is issue rulings on whether various laws are constitutional or not (unconstitutional laws are nullified), but <a href="http://www.law.cornell.edu/constitution/constitution.articleiii.html">the Constitution</a> does not explicitly give the Court this power.)</p><p>It ocurred to me that the only reason the Court uses precendent in its decisions is precedent.</p><p>How's that for circular logic?</p><p><small>Yes, I am aware that if they completely decided to drop precedent, it would most likely cause other branches of the government and citizens to take actions that would undermine the court. That's beside the point here.</small></p> DAxelrod 2006-09-12T22:29:34+00:00 journal Traits Paper Moved http://use.perl.org/~DAxelrod/journal/30613?from=rss <p>You know the Traits Paper <a href="http://dev.perl.org/perl6/list-summaries/2003/p6summary.2003-12-14.html#Meanwhile,_in_perl6-language">everyone</a> <a href="http://search.cpan.org/~stevan/Class-MOP-0.32/lib/Class/MOP.pm#Papers">seems</a> to be <a href="http://www.perl.com/pub/a/2004/04/16/a12.html?page=11#class_composition_with_roles">talking about</a>? The URL a lot of them point to no longer contains the paper.</p><p>So, for future reference, the Traits Paper is actually</p><blockquote><div><p>Nathanael Sch&#228;rli, St&#233;phane Ducasse, Oscar Nierstrasz and Andrew Black, "<b>Traits: Composable Units of Behavior</b>", <i>Proceedings ECOOP 2003 (European Conference on Object-Oriented Programming)</i>, LNCS, vol. 2743, Springer Verlag, July 2003, pp. 248-274.</p></div></blockquote><p> and its URL is now <a href="http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf">http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf</a>. </p><p>Chopping off part of the URL reveals the website of the <a href="http://www.iam.unibe.ch/~scg">Software Composition Group</a> at the <a href="http://www.unibe.ch/">University of Berne</a>, who seem to have written several more awesome papers.</p> DAxelrod 2006-08-14T03:16:06+00:00 journal No, wait! I come in peace! http://use.perl.org/~DAxelrod/journal/30547?from=rss <p>Let me make a few things clear about what I said in my previous entry.</p><p>What I'd like to do is step back, take a look at what we have, and try to figure out where to go from here. I'm not planning to start a new CPAN or anything.</p><p>I'm also not going to write a bunch of decrees about what I think other people should do. I'm hoping to be able to gain enough of an understanding of what the various projects around the CPAN infrastructure are so I can figure out how I can help. Another important part of this is that I'm not trying to piss people off. Shake up their assumptions a little, maybe, but not piss them off. That said, keep the criticism coming. Just please don't dismiss me outright based on what I've said so far.</p><p>If you like, the better way to see what I'm trying to do is that I'm doing research, forming some oppinions, and asking others whether these oppinions are crazy. Then I'll work from there.</p><p>And don't worry, I don't want to break backward compatibility. But I'm curious what the design possibilities might look like if we didn't take backward compatibility for granted.</p> DAxelrod 2006-08-07T02:23:43+00:00 journal A CPAN Revolution http://use.perl.org/~DAxelrod/journal/30537?from=rss <p>Incremental, backward-compatible change has its place. But sometimes it's good to be able to break your ties with the past and change how you look at things.</p><p>I've become convinced that we need to do this with CPAN.</p><p>Don't get me wrong, the CPAN is not only wonderful, it's one of Perl's best strengths. That doesn't mean we can't make it much, much better.</p><p>Ok, so what do I mean when I say CPAN? I'm referring to a lot of different things.</p><ul> <li>Module packaging (including metadata and versioning)</li><li>Installation mechanisms for modules</li><li>Package managers</li><li>Package repositories</li><li>Specification of dependencies</li><li>Interfaces, both APIs and UIs</li><li>Probably some other things I've forgotten</li></ul><p>It would be a benefit to look not only at our own past, but the accomplishments of other people solving similar problems. There are plenty of packaging systems, library management technologies, etc. and in the great Perl tradition, we should steal as many of their good design ideas as possible.</p><p>Step one is to come up with some sort of spec. Step zero is research. What have we designed? What have others designed? What are our needs?</p><p>It's going to be an exciting ride.</p> DAxelrod 2006-08-05T15:03:24+00:00 journal