Slashdot Log In
Optimizing Development For Fun
Posted by
Zonk
on Sun Oct 09, 2005 05:37 PM
from the haskell-has-never-been-or-will-ever-be-fun dept.
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.
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)
Re:This is all well and good... (Score:5, Insightful)
(http://www.ferion.net/ | Last Journal: Monday May 06 2002, @02:16AM)
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.
Want to make dev fun? (Score:5, Interesting)
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)
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.
Re:Want to make dev fun? (Score:5, Informative)
(http://bityard.net/ | Last Journal: Thursday August 08 2002, @04:18PM)
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.
Re:Want to make dev fun? (Score:5, Interesting)
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).
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!
Why shouldn't it be fun? (Score:4, Insightful)
This is the kind of collaboration I like (Score:1)
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?
while (Score:1)
Re:while (Score:5, Insightful)
(http://www.autrijus.org/)
A project generally regarded as pointless will likely have a difficult time finding contributors that sees this kind of fun in it.
Haskell (Score:1)
Avoid Recursion (Score:5, Interesting)
Faster velocity? (Score:2, Insightful)
Re:Faster velocity? (Score:5, Funny)
(http://lavincolindo.net/ | Last Journal: Friday January 20 2006, @05:50PM)
Sounds kinda like... (Score:1)
refactoring dirty prototypes (Score:3, Insightful)
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.
All we need now is ... (Score:5, Funny)
(http://assambassador.com/)
Mod story +5 Insightful (Score:5, Interesting)
(Last Journal: Sunday March 11 2007, @09:01PM)
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.
Re:Mod story +5 Insightful (Score:5, Insightful)
(Last Journal: Sunday March 11 2007, @09:01PM)
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)
(http://www.lightandmatter.com/)
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.
Good points (Score:2, Interesting)
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?
It's not frivolous (Score:3, Insightful)
exploring the deeper design and implementation issues" here:
http://www.nntp.perl.org/group/perl.perl6.languag
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.
Pugs 6.2.10 has just been released. :-) (Score:5, Informative)
(http://www.autrijus.org/)
The release tarball will be available from CPAN shortly:
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 backendThis makes sense (Score:4, Interesting)
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.
'even'? (Score:1)
(http://zeewier.blub.net/~jdv/)
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 that a lot of free software is good -- it was fun to write.
Using Haskell is also something that only improves the fun, instead of what the 'even when' implies. Partly, perhaps, because it is a bit uncommon -- because it is fun to learn something new -- but mostly simply because it's Haskell. I did some numerical maths-practical assignments in Haskell, while others used C or Pascal (the choice of language was free). My programs where invariably about 10 to 25% of the length of most others, while being a lot more readable and easier to write. Haskell is actually a lot of fun to use.
Jan
Vice Versa? (Score:5, Insightful)
(Last Journal: Thursday December 14 2006, @05:43PM)
Re:Optimus Prime (Score:2)
(http://reverend.healeys.net/)