Slashdot Mirror

← Back to Stories (view on slashdot.org)

Optimizing Development For Fun

Posted by Zonk on 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."

5 of 144 comments (clear)

  1. Want to make dev fun? by Anonymous Coward · · Score: 5, Interesting

    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.

    1. Re:Want to make dev fun? by Anonymous Coward · · Score: 5, Interesting

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

    2. Re:Want to make dev fun? by jonastullus · · Score: 4, Interesting
      ## 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!
  2. Avoid Recursion by Dante+Shamest · · Score: 5, Interesting

    Things to Avoid: The Haskell Wiki

  3. Mod story +5 Insightful by Spy+Hunter · · Score: 4, Interesting
    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.

    --
    main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}