Thursday, November 10, 2005

chromatic writes "Geoff Broadwell has written an analysis of optimizing an open source project for fun, specifically the Pugs project. Broadwell argues that making development fun and easy leads to higher quality code and a faster velocity of development, even when implementing a frivolous project (a toy Perl 6 interpreter) in an uncommon language (Haskell). The Pugs leader, Autrijus Tang, will speak about both Pugs and Haskell at EuroOSCON." Optimizing Development For Fun Log in/Create an Account | Top | 94 comments | Search Discussion Display Options Threshold: -1: 94 comments 0: 88 comments 1: 71 comments 2: 50 comments 3: 17 comments 4: 11 comments 5: 7 comments Flat Nested No Comments Threaded Oldest First Newest First Highest Scores First Oldest First (Ignore Threads) Newest First (Ignore Threads) The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way. This is all well and good... (Score:4, Insightful) by g_dunn (921640) on Sunday October 09, @06:44PM (#13752924) But, as a programmer, if the project I'm working on isn't something I want to do, and enjoy doing, why am I doing it? Even in the workplace, all of my projects are fun to me - That's why I decided to work there!And as open source projects are generally done as an aside, why volunteer to work their if the project doesn't interest you anyway?If you're not enjoying what you're doing, why are you doing it? [ Reply to ThisRe:This is all well and good... by downbad (Score:2)Sunday October 09, @06:53PMRe:This is all well and good... by Anonymous Coward (Score:1)Sunday October 09, @07:00PM1 reply beneath your current threshold.You obviously have never seen the boring....... by hummassa (Score:2)Sunday October 09, @07:59PM1 reply beneath your current threshold. Re:This is all well and good... (Score:5, Insightful) by NanoGator (522640) on Sunday October 09, @06:59PM (#13753015) (http://www.ferion.net/ | Last Journal: Monday May 06, @03:16AM) "If you're not enjoying what you're doing, why are you doing it?"Food on the table, mainly.In any event, I think questions like this are more helpful for management than they are for programmers or anybody else with a similar profession. The article uses the word 'fun', but in practice, I think 'importance' is a more interesting term. (Maybe they're not all that dissimilar?) Constantly changing directions in order to meet arbitrary deadlines or "chasing money" is a real morale killer. Working with well laid plan knowing that you're boring work is going to pay off into an interesting product, that's a lot more interesting. It's important.Eh I think I'm mainly just stating the obvious here. When I hear stories of companies like EA demanding tons of unpaid overtime to meet an arbitrary deadline, it seems to me that even the 'fun' parts of asset building turn into a curse real fast. It's not fun to try to shortcut your way to the finish line with the concern that one of those shortcuts will come back and nip your hinder. [ Reply to This | ParentRe:This is all well and good... by dubl-u (Score:2)Sunday October 09, @07:52PM1 reply beneath your current threshold.Re:This is all well and good... by zod2008 (Score:1)Monday October 10, @12:25AM1 reply beneath your current threshold. Want to make dev fun? (Score:4, Interesting) by Anonymous Coward on Sunday October 09, @06:54PM (#13752986) Use Python!Seriously - we use it except in a few places where C/C++ is a better fit for interfacing with DirectX. The results? People are having real fun and getting a ton done. We couldn't be happier. [ Reply to ThisRe:Want to make dev fun? by Anonymous Coward (Score:2)Sunday October 09, @07:08PMRe:Want to make dev fun? by D3m3rz3l (Score:1)Sunday October 09, @07:55PMRe:Want to make dev fun? by WillWare (Score:2)Sunday October 09, @08:05PMRe:Want to make dev fun? by An Onerous Coward (Score:2)Sunday October 09, @08:21PMRe:Want to make dev fun? by jma05 (Score:1)Sunday October 09, @10:53PMRe:Want to make dev fun? by Eil (Score:3)Sunday October 09, @08:21PMRe:Want to make dev fun? by belmolis (Score:2)Sunday October 09, @08:44PMRe:Want to make dev fun? by jonastullus (Score:3)Sunday October 09, @08:18PMRe:Want to make dev fun? by macshit (Score:2)Sunday October 09, @08:47PM Re:Want to make dev fun? (Score:5, Interesting) by jonastullus (530101) on Sunday October 09, @09:18PM (#13753601) ## I think you underestimate the ability of people to write bad codebut i don't.good python code is extremely readable, and medium python code is a pleasure to WRITE, because many things just seem to solve themselves.BUT, writing big software or maintaining medium-to-crappy python code is far worse than many of the alternatives (except perl, of course)... this is exactly why i have become such a big fan of type inference, not to speak of garbage collection which i had my doubts about in the past, but fully embrace nowadays.python's shady object-orientation makes many things harder than they need be (compare ruby).lacking private/public flags for methodsugly "__something__" pseudo-access-controlimplicit creation of attributes on write-access (*hello typos*)not so beautiful handling of "method not implemented" functionalityincessant and visually displeasing explicit "self." everywherelacking abstract/virtual classes, interfacestoo frequent "necessity" of metaclass-hacks (although the possibility is very nice)verbose attribute initialization in constructorsthe evil "param = []" default value pitfalland other defects with python's object system have led me to believe that it is not an ideal language for big-scale OO development.yet, for rapid prototyping i know few languages that allow the programmer such unhindered experimentation and the *possibility* of resulting readable code. also for applications of a few thousand lines, written by a few people it can actually create a certain fun factor! [ Reply to This | ParentRe:Want to make dev fun? by cloudmaster (Score:2)Sunday October 09, @11:12PMRe:Want to make dev fun? by Pseudonym (Score:2)Sunday October 09, @09:54PMRe:Want to make dev fun? by eosp (Score:1)Sunday October 09, @08:11PMRe:Want to make dev fun? by smitty_one_each (Score:2)Sunday October 09, @10:09PM2 replies beneath your current threshold. Why shouldn't it be fun? (Score:3, Insightful) by punkdigerati (921644) on Sunday October 09, @06:58PM (#13753009) I'm sure many more people would have a cleaner house if cleaning their house was fun. [ Reply to ThisRe:Why shouldn't it be fun? by dubl-u (Score:1)Sunday October 09, @07:36PMJust a spoonful of sugar... by gardyloo (Score:2)Sunday October 09, @08:12PMRe:Why shouldn't it be fun? by jonadab (Score:1)Sunday October 09, @09:50PMIt would be not as bad for me... by hackwrench (Score:1)Sunday October 09, @11:19PMRe:Why shouldn't it be fun? by Frogbert (Score:2)Monday October 10, @12:12AMRe:Why shouldn't it be fun? by BasilBrush (Score:2)Sunday October 09, @08:57PM1 reply beneath your current threshold. This is the kind of collaboration I like (Score:1) by HvitRavn (813950) on Sunday October 09, @07:00PM (#13753023) I am very enthusiastic about this kind of collaboration, the wild "everything goes" approach is very appealing as it invites anyone to do anything since "breaking something doesn't matter because it can be fixed in a few keystrokes".However, my personal experience is that there will at some point arise conflicts, arguments and general disagreements, often leading to one or more developers to just pack up and leave. Or worse, fork!Anyone else had any experience with this very loose development collaboration model? [ Reply to This while (Score:1) by akhomerun (893103) on Sunday October 09, @07:00PM (#13753024) while optimizing projects for maximum fun is great, it doesn't actually increase productivity unless the project itself is a productive project. i'd rather have a slow project than a fast one that's end result is useless. [ Reply to This Re:while (Score:4, Interesting) by autrijus (48596) on Sunday October 09, @07:54PM (#13753254) (http://www.autrijus.org/) Verily. However, I think a key parts of of the fun is a solid expectation of making a difference in the world, while the current result being immediately useful (for learning and/or production).A project generally regarded as pointless will likely have a difficult time finding contributors that sees this kind of fun in it. [ Reply to This | Parent Haskell (Score:1) by fyndor (895340) on Sunday October 09, @07:07PM (#13753054) I've used Haskell before in a college class. Nothing too "fun" about it, though its recursiveness could be usefull in some applicaitons. [ Reply to This Avoid Recursion (Score:4, Insightful) by Dante Shamest (813622) on Sunday October 09, @07:14PM (#13753076) Things to Avoid: The Haskell Wiki [haskell.org] [ Reply to This | ParentRe:Avoid Recursion by robotoverflow (Score:1)Sunday October 09, @09:16PMThat's mistitled by Estanislao Mart�nez (Score:3)Sunday October 09, @09:40PMRe:That's mistitled by Fahrenheit 450 (Score:2)Sunday October 09, @10:33PMRe:Haskell by fyndor (Score:1)Sunday October 09, @09:29PMRe:Haskell by dhasenan (Score:2)Sunday October 09, @10:03PM1 reply beneath your current threshold. Faster velocity? (Score:1, Insightful) by Anonymous Coward on Sunday October 09, @07:13PM (#13753074) Why "faster velocity of development"? Wouldn't "faster development" have worked? [ Reply to ThisRe:Faster velocity? by hunterx11 (Score:3)Sunday October 09, @07:28PMRe:Faster velocity? by bgramkow (Score:1)Sunday October 09, @08:33PMRe:Faster velocity? by ScrewMaster (Score:2)Sunday October 09, @10:57PMRe:Faster velocity? by smackjer (Score:2)Sunday October 09, @11:54PM1 reply beneath your current threshold. Sounds kinda like... (Score:1) by woah (781250) on Sunday October 09, @07:32PM (#13753163) Extreme Programming - OSS style. [ Reply to This refactoring dirty prototypes (Score:2) by jonastullus (530101) on Sunday October 09, @07:33PM (#13753171) Embrace anarchyIt's important also to make committer sign-up fast and easynew committers could be invited en masse and sign up on their owncommitting quick and dirty protypes that can be refactored as they grow*AAAHHHH*and i thought (quick and dirty) prototypes were supposed to be immediately scrapped and their essence implemented in clean, revised code... *silly me*all in all an interesting read, commending "anarchy" and as-turbulent-as-possible commits over more stringent methodologies. i can imagine that PUGS is going along quite "smoothly" and am in awe how these two radically different communities (haskell and perl) managed to find each other ;-)but whether this community and flair can be reproduced simply by adhering to somewhat questionable guidelines is another question alltogether. [ Reply to ThisRe:refactoring dirty prototypes by autrijus (Score:2)Sunday October 09, @07:39PMRe:refactoring dirty prototypes by jonastullus (Score:2)Sunday October 09, @08:01PMRe:refactoring dirty prototypes by -homb- (Score:2)Sunday October 09, @10:01PMRe:refactoring dirty prototypes by Pseudonym (Score:2)Monday October 10, @12:21AM All we need now is ... (Score:5, Funny) by Douglas Simmons (628988) on Sunday October 09, @07:34PM (#13753173) (http://assambassador.com/) this to be implemented into apt-get so we the debian community are still superior to those pompous fun-compiling gentoo users. [ Reply to This Mod story +5 Insightful (Score:5, Interesting) by Spy Hunter (317220) * on Sunday October 09, @07:36PM (#13753182) (Last Journal: Thursday April 22, @07:05AM) Most insightful article about software development I've ever read. Every open source project could learn a thing or two here, and closed-source commercial products could learn a bit too.IMHO this philosophy could go a *lot* farther too. We should be building these types of concepts into our software development tools (not just source control but IDEs and compilers and even languages). It should be as easy as possible for users to get the source, build it, modify it, and submit their changes. Ideally as easy as editing a Wiki. Though the inherent complexity of software means that Wiki simplicity will probably never be reached, we could certainly do a *lot* better than we do now.In an open source project the ease of the process of getting, compiling, modifying, and submitting changes to the source is directly related to the number of new contributors joining the project, which is directly related to the rate of improvement. Traditional software development tools have far too many pitfalls and require far too much know-how for casual users. The process of contributing to open-source projects could and should be a lot more automatic and foolproof, because attracting contributors is the single most important thing an open source project can do to improve itself. [ Reply to ThisRe:Mod story +5 Insightful by daveb (Score:1)Sunday October 09, @07:57PMRe:Mod story +5 Insightful by dubl-u (Score:1)Sunday October 09, @08:02PMLet's run with this idea a little by wyoung76 (Score:3)Sunday October 09, @08:12PMRe:Let's run with this idea a little by Otter (Score:2)Sunday October 09, @10:01PMRe:Let's run with this idea a little by qbwiz (Score:2)Sunday October 09, @10:33PMRe:Let's run with this idea a little by Ramses0 (Score:2)Sunday October 09, @10:48PMRe:Let's run with this idea a little by Spy Hunter (Score:2)Monday October 10, @12:05AMRe:Mod story +5 Insightful by bcrowell (Score:2)Sunday October 09, @08:30PMRe:Mod story +5 Insightful by Captain Tripps (Score:1)Sunday October 09, @09:00PM Re:Mod story +5 Insightful (Score:5, Insightful) by Spy Hunter (317220) * on Sunday October 09, @09:29PM (#13753650) (Last Journal: Thursday April 22, @07:05AM) If a Wikipedia article gets munged temporarily by someone who's stupid, uninformed, or malicious, it's no big deal, and it will probably get fixed soon. But when it's a piece of software, the consequences are potentially a lot more serious, and there's no guarantee that the damage will be detected or fixed any time soon.Why will the damage to wikipedia get fixed soon? Because anybody can fix it. Why will the damage to the software not be fixed soon? Because only a couple of people have the ability to fix it. The idea is to give far more people the ability to fix that problem (a number which is proportional to the number of people who are likely to cause the problem, so the problems shouldn't get out of hand).Why is the software problem more serious? Because softare is fragile. Is that inherent to software, or is it just the condition of the software development tools and processes we use today? I believe it is the latter. I believe software development tools and processes could be a lot more robust and forgiving of simple mistakes. And if projects started really opening up contributions, made it as easy as editing a Wiki, then they would be forced to become more robust. This is a good thing, not something to be avoided.I'm not sure the conclusions from The Mythical Man Month apply directly here. The main conclusion is that adding developers to a project makes it take longer. Open source software isn't on a strict schedule, and it doesn't have central management with clearly defined lists of requirements. New contributors aren't assigned to speed up existing work, they add their own features and improve the software in their own way.Most successful open-source projects also have exactly one author. Massive parallelization works best for something like Wikipedia that's both big and inherently parallelizable. Most software isn't like that.I'm thinking about the big projects here. KDE, GNOME, Mozilla, Debian, etc. But why is it that developing software isn't inherently parallelizable? To the extent that is actually true, once again I blame the tools. We need better software development tools to make software development more parallelizable. I don't think there's any inherent reason why "Joe's Yet Another MP3 Database" on SourceForge shouldn't be able to use this type of develoment methodology, given the right tools. [ Reply to This | Parent Re:Mod story +5 Insightful (Score:5, Insightful) by bcrowell (177657) on Sunday October 09, @09:50PM (#13753730) (http://www.lightandmatter.com/) Why is the software problem more serious? Because softare is fragile. No, it's more serious because, e.g.: People depend on software to get their work done. Broken software can mess up your data. Malicious software can do bad things, like give your credit card number to Russian gangsters.Vandalizing a Wikipedia article has none of these serious consequences.Why will the damage to wikipedia get fixed soon? Because anybody can fix it. Why will the damage to the software not be fixed soon? Because only a couple of people have the ability to fix it. If you take the total number of people in the world who are interested in and capable of doing OSS programming, and divide by the number of OSS projects, the result is a number close to 1. This is why most OSS projects have a single author. Imagining that "only a couple of people" have the privileges to fix a bug is actually optimistic -- the most likely case is that only one person is interested. [ Reply to This | ParentRe:Mod story +5 Insightful by boneshintai (Score:2)Sunday October 09, @10:02PMRe:Mod story +5 Insightful by Spy Hunter (Score:2)Sunday October 09, @10:19PMRe:Mod story +5 Insightful by l00k (Score:1)Sunday October 09, @11:39PM Good points (Score:2, Interesting) by Anonymous Coward on Sunday October 09, @07:48PM (#13753230) Form the article:* Embrace anarchy. One of the key realizations of modern Internet projects (the oft-quoted Web 2.0) is that on the whole, your users can be trusted.* Avoid deadlocks. There should be nothing blocking a programmer from committing his code.* Cast committer rights far and wide. A central core committer group is necessarily slower than allowing every developer to commit as desired.This all boils down to one thing: Open the CVS access for everybody. And that is exactly what I have come to hate about the GNOME project: Development is essentially closed because every piece of code needs to be reviewed and there are not enough reviewers. I often wondered whether these guys really believe in Open Source. Is KDE development equally restrictive and boring? [ Reply to This1 reply beneath your current threshold. It's not frivolous (Score:2, Insightful) by Anonymous Coward on Sunday October 09, @07:58PM (#13753266) What a weird article description. Getting people to hack on frivolous projects generally isn't a problem. Getting them to hack on tough projects can be. Okay, maybe this is a test implementation in a funky language, but this isn't a frivolous project according to the Perl folks; Damian Conway described the work as "both amazing and amazingly useful: as a way ofexploring the deeper design and implementation issues" here:http://www.nntp.perl.org/group/perl.perl6.language /19263 [perl.org]Worst of all, the word frivolous distracts from the point of the article, which is all about techniques you can use to help making hacking on any project fun. It's not about only hacking on projects that are instrinsically fun, as 'frivolous toys' tend to be. [ Reply to ThisRe:It's not frivolous by chromatic (Score:1)Sunday October 09, @10:27PM Pugs 6.2.10 has just been released. :-) (Score:5, Informative) by autrijus (48596) on Sunday October 09, @09:19PM (#13753609) (http://www.autrijus.org/) I am delighted to announce Pugs 6.2.10, released during a slashdotting ongeoffb's "Optimizing for Fun" column: http://developers.slashdot.org/article.pl?sid=05/1 0/09/1831219 [slashdot.org] The release tarball will be available from CPAN shortly: http://pugscode.org/dist/Perl6-Pugs-6.2.10.tar.gz [pugscode.org] SIZE = 2394516SHA1 = 3d8669fdccc3616c99cdde68659759b8b5782859With two months of development, this release features more tightly integratedJavaScript and Perl5 code generator backends, a library interface to the Pugssystem via support for the Haskell Cabal frameworks, as well as many new tests.After the release, the push toward 6.28.0 will begin in earnest, with the newlyspecified container model and object model integrated back to the main runtime,fleshing out support for the remaining OO features.Again, thanks to all the lambdacamels for building this new ship with me. :)Enjoy! /Autrijus/Changes for 6.2.10 (r7520) - Oct 10, 2005Feature ChangesShared componentsSupport for the Haskell Cabal framework, exposing Pugs as a library to other Haskell users, paving the way for use in IDEs, as well as future Inline::Pugs and Inline::GHC modulesAdopted the code convention of expanding literal tab chars to spacesJavaScript backend can be invoked with pugs -B JS Perl 5 backend can be invoked with pugs -B Perl5 Pugs will now compile version ranges in use/require statementsSignificant backend enhancements; see below $?PUGS_BACKEND can be used to tell which runtime is in use exec emulated partially on Win32JavaScript backendPasses 91% of the main test suite including TODO failuresIntegrated with MetaModel 1.0Faster code generation, taking advantage of -CPerl5 output.Switched to continuation passing style CPS to properly support return, ?CALLER_CONTINUATION, coroutines, and sleep Improved support for binding and autodereferentiationInitial support for multi subsInitial support for symbolic dereferentiationList construction no longer creates new containersMiscellaneous performance improvementsNamed-only arguments +$x and ++$x cant be passed positionally anymoreParts of the Prelude can be written in Perl 5 now to improve performancePerl 5-like regular expressions mostly workingProper UTF-8 handlingSupport for monkey-but $foo but {...} Support for $CALLER:: and $OUTER:: Support for lazy {...} blocks for delayed evaluationSupport for temp and let declarationsSupport for array and hash autovivificationSupport for array and hash slicesSupport for evaluating expressions in the PIL2JS shell :e <exp> Support for junctionsSupport for loading JSAN modules by using use jsan:Module.Name Support for lvalue subroutines foo = ... Support for slurpy hashes in subroutine signaturesSupport for the Proxy class not yet user-visibleSupport for the eqv operatorUsing for with only one element to loop over works now int works correctly on special values like Inf or NaN now substr returns a r/w proxy: substr$str, $pos, $len = $replacement Perl 5 backendPasses 33% ofRead the rest of this comment... [ Reply to This1 reply beneath your current threshold. Optimus Prime (Score:2) by Ranger (1783) on Monday October 10, @12:10AM (#13754253) Optimizing obscure little used code doesn't sound very optimal to me. Aren't their utilities that can tell you where the bottlenecks in your program code is? Wouldn't it better to write efficient code in the first place. Cleaning up someone elses mess really just doesn't sound fun in my book. Oh I can hardly wait until my alcoholic roommate powerpukes on the ceiling again. I've got this new long handled mop for optimal cleaning efficiency. [ Reply to This10 replies beneath your current threshold.

0 Comments:

Post a Comment

<< Home