Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Optimizing Development For Fun 144

Posted by Zonk from the haskell-has-never-been-or-will-ever-be-fun dept.
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."
This discussion has been archived. No new comments can be posted.

Optimizing Development For Fun More

Optimizing Development For Fun

Comments Filter:

  • This is all well and good... (Score:4, Insightful)

    by g_dunn ( 921640 ) on Sunday October 09, 2005 @05: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?
    • Because it needs to be done?

    • Re:This is all well and good... (Score:5, Insightful)

      by NanoGator ( 522640 ) on Sunday October 09, 2005 @05:59PM (#13753015) Homepage Journal
      "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.
      • 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.

        I don't know about that. I'd use the term "enjoyable" instead of "fun", but I strive to structure the projects I work on so that everybody is enjoying it. Like most people, I'm much more productive when I'm enjoying things, so there's a big financial benefit to arranging things so that people are eager to come to work every day. And I think it's every employee's r
    • If you're not enjoying what you're doing, why are you doing it?

      A great point that I should include in my FAQ. Fun is such an arbitrary thing and will be all but annihilated as you submit yourselves to me. Programmers of EA will have no difficulties under my new regime. Vote for me: http://zod2008.com/ [zod2008.com]
    • Like the human life cycle, you've got to take dump now and then. The same goes for software, in and out of the workplace, where in addition to writing exciting applications, there is often a lot of boring-to-death-work, unless you're especially lucky.

      What I've found though, is that if you go into the work place with some 'higher-order order' in mind, and try to unify everything you do into one clean infrastructure, the fun does linger. You should have a greater vision to which all other projects must co

    • on why chromatic considers a perl6 interpreter "a frivolous project".

  • Want to make dev fun? (Score:5, Interesting)

    by Anonymous Coward on Sunday October 09, 2005 @05: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.

    • Re:Want to make dev fun? (Score:5, Interesting)

      by Anonymous Coward on Sunday October 09, 2005 @06:08PM (#13753057)
      Except that this article is about people developing in Haskell - a language that's every bit as fun to use as Python (it even has optional syntactic whitespace), but compiles to native code (so it's faster) and infers types at compile-time (so it's robuster).

      Think Pugs is cool? Look at this [okmij.org]. These guys have implemented a complete transactional file system - looks like a Unix FS, but provides snapshots, unlimited undo, true copy-on-write handling of links (including link cycles), and perfect concurrency without requiring any OS-level threading. In just 540 lines of Haskell.

      Give it a try. The learning curve's steep at first - it's got some concepts you simply won't have encountered anywhere else. But if you're smart enough to have dropped C++ in favour of Python, you're smart enough to handle Haskell.

      • Except that this article is about people developing in Haskell - a language that's every bit as fun to use as Python (it even has optional syntactic whitespace), but compiles to native code (so it's faster) and infers types at compile-time (so it's robuster).

        And if you really want speed and the functional properties of haskell, try Ocaml. It's hella lot faster [debian.org], even faster than c++ [debian.org] and that's something!

        (Haskell has nicer syntax though)

        • Hmm there seems to be a bug at slashdot code. The urls are wrong, I'm previewing them for a second time and they are still wrong even when they are correct in this box. I can't even copy and paste them as text because the buggy algorithm makes them incorrect links again.

          Go and compare for yourselves at The Computer Language Shootout Benchmarks
          http://shootout.alioth.debian.org/ [debian.org]
      • Sure, if you want an uglier, single paradigm language that's harder to maintain, it's great. But us non-zealots prefer to use languages that are easier to read and don't think that a single programming paradigm is the end-all and be-all.

        The "lines of code" argument is tired, old and bullshit, frankly. Anyone can write a minimal line version of practically anything, but that says nothing for maintainability, readinability or anything else. Someone's written a 3 line RSA utility in perl, but have you taken
        • Sure, if you want an uglier, single paradigm language that's harder to maintain, it's great.

          Uglier is in the eye of the beholder. Hell all I hear about Python is how clear and clean it is, but every time I look at it I can't help but think how ugly it is, with all of it's __some_crap_or_another__ and whatnot. Sure, it's nicer than, say, C++, but that's a bit like saying someone is cuter than Karl Malden... Bottom line, saying something is uglier should mean little to anyone who isn't you -- we all like a
    • I've heard that Python is a lot of fun to code in. Is that really true? I mean Java and C# have similar features to Python right? In terms of high level libraries, code succinty, etc etc. I've been meaning to learn Python because I've heard so many good things about it. Do you have any specifics you'd like to share?
      • I've been meaning to learn Python because I've heard so many good things about it.

        Go ahead, take the plunge. It will be one of the more rewarding half-hours of your computing career.

      • I'm a bit of a Python noob, but a few things have really impressed me. The syntax is about as clean and straightforward as things can get, and the "batteries included" philosophy means that you've got a lot of functionality at your fingertips. Regular expressions, XML parsers, etc. Very useful stuff.

        Also, the interpretedness is useful. In EMACS python mode, all I have to do to run the program is C-c C-c. Syntactic whitespace makes for cleaner code.

        There are pitfalls. No const's, weak typing, the abili

      • Re:Want to make dev fun? (Score:5, Informative)

        by Eil ( 82413 ) on Sunday October 09, 2005 @07:21PM (#13753363) Homepage Journal

        Mainly, Python is powerful but has a deliberately shallow learning-curve. The most often-cited reasons are the following Python mantras:

        - Everything is an object
        - Syntax is simple and predictable (but feels a little odd if you're coming from C, C++, Perl, Java, etc)
        - There's one obvious way to do it. (Contrast with Perl's, "There's more than one way to do it.")
        - Batteries included (comes with a large library of modules)

        Pretty sure there are more, but these are the biggies that I can recall. These are the same reasons that many quote for using Ruby as well, but I got around to trying it yet.

        I used to be a big fan of Tcl for it's insanely shallow learning curve. (Even more so than Python.) I wrote a usuable Tk (GUI) app within the first hour of even hearing about it. Too bad it didn't really catch on and mature as well as Python and Perl did over the same time-frame because it really is a nifty language.

        • I agree about Tcl - it is really under-rated. I tried it a couple years ago because I wanted to try out Tk. There was a time when I thought that it wasn't well suited to larger-scale projects, but after a while I realized that that wasn't true. It's really a lot like Lisp, but with about the right amount of syntactic sugar.

        • Do this in a python shell to read the Zen of Python:

          Python 2.3.4 (#1, Feb 22 2005, 04:09:37)
          [GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)] on linux2
          Type "help", "copyright", "credits" or "license" for more information.
          >>> import this
          The Zen of Python, by Tim Peters

          Beautiful is better than ugly.
          Explicit is better than implicit.
          Simple is better than complex.
          Complex is better than complicated.
          Flat is better than nested.
          Sparse is better than dense.
          Readability counts.
          Special cases aren't special enough to b
    • i agree that python has a tendency (at least for me) to cause relaxation and make even otherwise boring tasks fun due to its extremely readable nature and good balance of write-once vs. read-often.

      and also, c++ is not such a hard competition when "having fun" is on your agenda. every single time that i sit down to program c++ i end up heavily frustrated at some point due to wrong "#include" order, some whacko unreadable compiler error or simply a hard to find segfault (most often due to forgotten pointer in
      • i agree that python has a tendency (at least for me) to cause relaxation and make even otherwise boring tasks fun due to its extremely readable nature and good balance of write-once vs. read-often.

        I think you underestimate the ability of people to write bad code -- I've seen a great deal of really crappy impossible-to-understand python code.

        I get the impression that many people think "hey it's an easy-going casual high-level language, I don't need to use any care whatsoever!"

        [This problem can be even worse

        • Re:Want to make dev fun? (Score:5, Interesting)

          by jonastullus ( 530101 ) on Sunday October 09, 2005 @08:18PM (#13753601) Homepage
          ## I think you underestimate the ability of people to write bad code

          but 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 methods
          • ugly "__something__" pseudo-access-control
          • implicit creation of attributes on write-access (*hello typos*)
          • not so beautiful handling of "method not implemented" functionality
          • incessant and visually displeasing explicit "self." everywhere
          • lacking abstract/virtual classes, interfaces
          • too frequent "necessity" of metaclass-hacks (although the possibility is very nice)
          • verbose attribute initialization in constructors
          • the evil "param = []" default value pitfall

          and 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!
          • what is the 'the evil "param = []" default value pitfall'?
            • EXAMPLE:

              def test(arr = []):
              return arr

              t = test()
              t.extend(["hello", "world"])

              u = test()
              print u
              RESULT:

              $ ./test.py
              hello
              hello hello
              REASON:

              the default value expression is evaluated once, when the function
              object is created, and the resulting object is bound to the argument.

              FIX / WORKAROUND:

              if you want to create a new object on every call, you have to do
              that yourself:

              def __init__( self, myList=None):
              if myList is None:
              myList = [] # create a new list
        • What? You must not be a Python fanboy, or you'd realize that it's *impossible* to write bad Python - and that bad code is guaranteed with Perl. It's possible to write crappy code in any language, even one that forces you to indent (yay, forced indentation magically makes everyone a great programmer! Never mind those line continuation characters that are required as a result of having no end-of-line char, and ignore that the language isn't strictly typed, but you still can't always use numbers as strings
      • This is ridiculous. Any comments to the effect of "programming in language X is more fun" are going to be highly dependent on personal preference. While you may find C++ to be quite frustrating, I'm sure there are many people that agree with you. And I know for a fact that there are a lot of people out there who will tell you that Java is the greatest thing in the world (except for a nice MLT). Personally, I've never used C++ outside of college, and I avoid Java whenever possible, but I van tell you tha
      • yet, python tends to have its own set of problems, mainly stemming from the fact that NO type checking is done at startup time and so you have to start your program again and again, everytime only finding/fixing one small typo!

        As opposed to starting your compiler again and again, everytime only finding/fixing one small typo!

        -Dom

    • One of the reasons why Pugs is written in Haskell is that, IM(biassed)O, it can be even more fun than Python. Certainly, the more fun features of Python were either directly borrowed from Haskell (e.g. list comprehensions) or from languages very like it (e.g. higher-order programming from Scheme).

  • Why shouldn't it be fun? (Score:4, Insightful)

    by punkdigerati ( 921644 ) on Sunday October 09, 2005 @05:58PM (#13753009)
    I'm sure many more people would have a cleaner house if cleaning their house was fun.

  • 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 collaborat

  • 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.

    • Re:while (Score:5, Insightful)

      by autrijus ( 48596 ) on Sunday October 09, 2005 @06:54PM (#13753254) Homepage
      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.

  • I've used Haskell before in a college class. Nothing too "fun" about it, though its recursiveness could be usefull in some applicaitons.

    • Avoid Recursion (Score:5, Interesting)

      by Dante Shamest ( 813622 ) on Sunday October 09, 2005 @06:14PM (#13753076)
      Things to Avoid: The Haskell Wiki [haskell.org]
      • Thanks for the warning, i'll try to avoid clicking on that link (as it appears to point directly to the Wiki in question!)
      • That shouldn't be called "Avoid Recusion," because you're not really avoiding recursion. What you're doing (as the wiki itself explains) is abstracting it into a higher-order function. Still a pretty damn important technique that one should master in functional languages--recognizing the "shape" of a loop (is it a map? a left or right fold? an unfold?), and implementing the looping logic as a higher-order function separately from its specific uses.
        • Still a pretty damn important technique that one should master in functional languages--recognizing the "shape" of a loop (is it a map? a left or right fold? an unfold?), and implementing the looping logic as a higher-order function separately from its specific uses.

          Learn the squiggol [psu.edu], it shall set you free (or rub your eyes and curse the development of category theory...)
          • Yeah, I was reading that a couple weeks ago. Lesson I got out of it (might be wrong, but if it is, it's wrong in a good way): all linear recursion, deep down, boils down to "copying" some recursive "data structure"; scare quotes because you get to pick your own "fake" constructors, destructors and type predicates. Thus, linear recursion boils down to "copying" a "list," and iteration (i.e. tail recusion) boils down to "reversing" a "list."

            Some Scheme-ish code might make this clearer. Here'
            • Yeah, I was reading that a couple weeks ago. Lesson I got out of it (might be wrong, but if it is, it's wrong in a good way): all linear recursion, deep down, boils down to "copying" some recursive "data structure"; scare quotes because you get to pick your own "fake" constructors, destructors and type predicates. Thus, linear recursion boils down to "copying" a "list," and iteration (i.e. tail recusion) boils down to "reversing" a "list."

              Well, there's a bit more to it than that. I suppose that might be th
      • Too many things to avoid...it does say a lot about Haskell, doesn't it?

  • Faster velocity? (Score:2, Insightful)

    by Anonymous Coward
    Why "faster velocity of development"? Wouldn't "faster development" have worked?
  • Extreme Programming - OSS style.

  • refactoring dirty prototypes (Score:3, Insightful)

    by jonastullus ( 530101 ) on Sunday October 09, 2005 @06:33PM (#13753171) Homepage

    Embrace anarchy

    It's important also to make committer sign-up fast and easy

    new committers could be invited en masse and sign up on their own

    committing 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.

    • Fully agreed, although note that rewriting everything excepts the tests is an usual form of "refactoring" in the Pugs project. :-)
      • ## rewriting everything excepts the tests is an usual form of "refactoring" in Pugs :-)

        probably not least due to the nice isolation/interchangability of functions in haskell... i haven't looked at the code yet, but heard that you were using monadic parser combinators, and if those things are good for one thing then it surely is extending, rewriting and "recombinating" sub-parsers *gg*

        on a sidenote, here's a funny thing i found in an otherwise quite convincing C# tutorial (http://www.softsteel.co.uk/tutorial [softsteel.co.uk]

        • Anonymous methods can also make use of the local variables and parameters in whose scope the anonymous method lies. This is a somewhat complicated, and we don't yet have a clear idea of when one should exploit it. So to illustrate it we'll borrow the example from the documentation.

          That's funny. They should have read the standard Perl article on closures: http://www.perl.com/pub/a/2002/05/29/closure.html [perl.com]

          Here's a quote from it:

          Here's the canonical example of closures, that you'll find in practically every Per

    • [I] am in awe how these two radically different communities (haskell and perl) managed to find each other ;-)

      It's not such a shock, IMO. Ever since it's been a "real" language (about Perl 5 or so), Perl has always been inspired by Lisp-like languages with its support for programming with lists, map/filter-like programming, higher-order programming and so on. And Perl is still a prerequisite for building the most common Haskell compiler, GHC.

      Haskell and Perl represent flip-sides of the programming coin

  • All we need now is ... (Score:5, Funny)

    by Douglas Simmons ( 628988 ) on Sunday October 09, 2005 @06:34PM (#13753173) Homepage
    this to be implemented into apt-get so we the debian community are still superior to those pompous fun-compiling gentoo users.

  • Mod story +5 Insightful (Score:5, Interesting)

    by Spy Hunter ( 317220 ) * on Sunday October 09, 2005 @06:36PM (#13753182) Journal
    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.

    • sounds like an interesting methodology - but what does FUN stand for? How does it compare with SCRUM and is it Agile?

      How can we teach this as a thriving Software Engineering methodology if it doesn't have a silly acronym
      • sounds like an interesting methodology - but what does FUN stand for? How does it compare with SCRUM and is it Agile?

        I know you were mainly kidding, but I think one of the secrets to the success of the assorted Agile methods is that everybody has more fun. If I were talking to a business exec, I'd cover it up by using a more suit-friendly term like "engaged", "motivated" or "morale-building", but from my perspective, fun is what it is.
    • If we use wikis as a front-end to the cvs, and by default mark all modules with a simple security level (no disk access, etc), and wrap each thing with unit tests for basic error capturing, and had incremental compilation, then we might have an easier and more collaborative way of coding.

      To further the idea a little more, the wiki also helps in documenting the structure of the project, and like other tools would be able to show any/all references to given code.

      Certainly, if you're a hardcore coder, you'll

      • I'm not familiar with the "modern, decentralized version control" described here, so I'm probably simply missing something, but as a casual coder my concern would be this:

        Casual coder A has just made a few tweaks and committed them, breaking compilation. Intarweb idiot B came by a few minutes later and deliberately broke some other things. I, casual coder C, show up a few minutes after that with an idea I'd like to try out in the source code -- and it doesn't compile because the damage from A and B hasn't b

        • I think that that's where the unit tests come in. If something doesn't compile, or it doesn't pass the unit tests, then it cannot be checked in. There could also be known-good checkpoints, which enable users and possibly even developers to work on something that should work.
          • Does that mean the unit tests would be readonly for the general public? I'm assuming they should, since otherwise you'd just delete the unit tests if you wanted to check in some faulty code.

            But what if someone changes an interface and the unit tests need to be updated?
      • I did something similar to this at work... some greasemonkey scripts wired to a wiki as a backend datastore with some extra popup helper dialogs.

        You would then run it via Python's great runtime eval stuff. Since I'm pretty tired, maybe some code would help demonstrate:

        def Import( wikiword ):
        print ">>> Importing: " + wikiword
        text = getTextFromWikiWord( wikiword )
        code = getCodeFromText( text )
        if len( code ) == 0:
        • And once it's in a wiki hidden between [code] blocks, lean on the wiki to provide gooood documentation (think wikipedia, but with little blocks of code).

          I think documentation is one area where this approach could really shine without requiring major changes to existing tools. Large projects such as KDE could create wiki documentation sites tied to the code documentation in their CVS. Developers don't like writing documentation, and they're too close to their own code to know how to write good docs. Use

          • The goal was to record browser-interactions against a web-page with GreaseMonkey (as snippets of executable python), then "save" the actions to an internal wiki under a name chosen by the user.

            def UserDefinedFunctionNameForSearching():
            browser.useForm( "search" )
            browser.set( "q", "test something" )
            browser.submit()

            ...then let users string together these functions into executeable scripts via a simple wizard:

            Execute( "UserDefinedFunctionSearching" )
    • I agree with a lot of what you're saying, but...

      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.
      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 s

      • Keep in mind that the people involved in pugs are highly self-selected: they've been following the Perl 6 e-mail lists, and they know Haskell.

        That's true of some contributors, but not all. Autrijus inspired many Perl hackers (camelfolk) to learn Haskell, and even got some in the Haskell community (lambdafolk) interested in Perl 6. But yeah, I think Pugs has been successful partly because there were so many people following along and wanting to join in on the Perl 6 implementation. Your average open source

      • Re:Mod story +5 Insightful (Score:5, Insightful)

        by Spy Hunter ( 317220 ) * on Sunday October 09, 2005 @08:29PM (#13753650) Journal
        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.

        • Re:Mod story +5 Insightful (Score:5, Insightful)

          by bcrowell ( 177657 ) on Sunday October 09, 2005 @08:50PM (#13753730) Homepage
          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.

          • I don't think anyone's proposing that we distribute from the publicly-editable version, but for a project with sufficient momentum the community behind it may well be able to reach consensus on what snapshots to release for testing. Test snapshots may well have more stringent requirements (eg. all submissions must be vetted, all submissions must pass automated testing, etc) for submissions before being marked "stable" and released.

            The basic idea is surprisingly sound, I think, and is worth testing out on a
          • 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.

            People shouldn't depend on software under active development; only released software. Obviously before releasing a piece of software some quality assurance work will have to be done. This needs a different process than normal development work; it can be done on a branch of the code. This problem is largely solved by exist

            • And why is that? Because OSS programming is hard to do. It's very hard to jump in and immediately contribute to a project that you use.

              Why do you say that? Have you ever been turned down from a project that you wanted to work on? I've found that, if I have useful code to contribute, any project I've approached has happily accepted my input. If you're getting rejected (general you - not just the poster), then there are just a few likely reasons. 1), you're not as good of a coder as you think, and your id
          • 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.

            If you took the total number of people who contribute to the Wikipedia, and divide by the total number of Wiki

        • In my blog entry Disorganized Incremental Software Development [1729.com], I describe an idea for a programming language where all implementations and specifications are named using cryptographic hash codes of their contents. This avoids all name collisions, and means that you can let anyone be a "committer", and indeed dispense with version control altogether (except for comments, which still have to be written by someone who knows what they are writing).

  • Good points (Score:2, Interesting)

    by Anonymous Coward
    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 a

  • It's not frivolous (Score:3, Insightful)

    by Anonymous Coward on Sunday October 09, 2005 @06: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 of
    exploring 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.

    • Re:It's not frivolous (Score:2, Informative)

      by chromatic ( 9471 )

      I meant that Pugs started as a frivolous project in the same sense that the Linux kernel started as a frivolous project and as much as any learning experience refactorable into useful, non-frivolous code is frivolous.

      I'm not sure when Autrijus realized what he had, but I'm sure he didn't intend to write a full-fledged Perl 6 implementation with pluggable backends targeting Perl 5, Parrot, the JVM, and JavaScript, at least not at first.

  • Pugs 6.2.10 has just been released. :-) (Score:5, Informative)

    by autrijus ( 48596 ) on Sunday October 09, 2005 @08:19PM (#13753609) Homepage
    I am delighted to announce Pugs 6.2.10, released during a slashdotting on geoffb's "Optimizing for Fun" column:

    The release tarball will be available from CPAN shortly:

    http://pugscode.org/dist/Perl6-Pugs-6.2.10.tar.gz [pugscode.org]
    SIZE = 2394516
    SHA1 = 3d8669fdccc3616c99cdde68659759b8b5782859

    With two months of development, this release features more tightly integrated JavaScript and Perl5 code generator backends, a library interface to the Pugs system 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 newly specified 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, 2005

    Feature Changes

    Shared components

    • Support 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 modules
    • Adopted the code convention of expanding literal tab chars to spaces
    • JavaScript 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 statements
    • Significant backend enhancements; see below
    • $?PUGS_BACKEND can be used to tell which runtime is in use
    • exec emulated partially on Win32

    JavaScript backend

    • Passes 91% of the main test suite including TODO failures
    • Integrated with MetaModel 1.0
    • Faster 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 autodereferentiation
    • Initial support for multi subs
    • Initial support for symbolic dereferentiation
    • List construction no longer creates new containers
    • Miscellaneous performance improvements
    • Named-only arguments +$x and ++$x cant be passed positionally anymore
    • Parts of the Prelude can be written in Perl 5 now to improve performance
    • Perl 5-like regular expressions mostly working
    • Proper UTF-8 handling
    • Support for monkey-but $foo but {...}
    • Support for $CALLER:: and $OUTER::
    • Support for lazy {...} blocks for delayed evaluation
    • Support for temp and let declarations
    • Support for array and hash autovivification
    • Support for array and hash slices
    • Support for evaluating expressions in the PIL2JS shell :e <exp>
    • Support for junctions
    • Support for loading JSAN modules by using use jsan:Module.Name
    • Support for lvalue subroutines foo = ...
    • Support for slurpy hashes in subroutine signatures
    • Support for the Proxy class not yet user-visible
    • Support for the eqv operator
    • Using 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 backend

    • Passes 33% of the main test suite including TODO failure

  • This makes sense (Score:4, Interesting)

    by doc modulo ( 568776 ) on Monday October 10, 2005 @01:42AM (#13754728)
    Because there are 2 kinds of fun/joy systems in the brain.

    The kind triggered by dopamine, the short high that doesn't last, the Mtv, nicotine, "I want to buy this" kind of fun.

    And the relaxed kind of contented joy that works with the serotonin system in the brain. Which does last and is an indicator of good relationships with friends, experiencing nature and knowing that "all is right in my domain, I'm ok for exploration into new things" kind of fun.

    That last kind of joy is an indicator of efficiency and "everything is as it should be" and if you feel that while coding, you must be on the right track.
  • The phrase 'even when implementing a frivolous project (a toy Perl 6 interpreter) in an uncommon language (Haskell).' shows some very big misunderstandings about this project, and software-development and developers in general.

    Calling Pugs 'frivolous' and a 'toy' project is like calling linux frivolous, and a toy OS. The fact that Pugs seems to be fun to write, and seemed like something that they writers would like building, has little to do with it being usefull, but does illustrate one of the reasons th

  • Vice Versa? (Score:5, Insightful)

    by Maljin Jolt ( 746064 ) on Monday October 10, 2005 @04:23AM (#13755131) Journal
    While writing perl in haskell *is* fun, writing haskell in perl would be a horrific nightmare torture. Perhaps all code language disputations/wars should be solved by duel of this kind.
    • One man's nightmare torture is another man's fun weekend challenge, and vice versa.

Slashdot Top Deals

"To take a significant step forward, you must make a series of finite improvements." -- Donald J. Atwood, General Motors

Close