Slashdot Mirror
Optimizing Development For Fun
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."
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?
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.
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 collaboration model?
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.
I've used Haskell before in a college class. Nothing too "fun" about it, though its recursiveness could be usefull in some applicaitons.
Why "faster velocity of development"? Wouldn't "faster development" have worked?
Things to Avoid: The Haskell Wiki
Extreme Programming - OSS style.
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.
this to be implemented into apt-get so we the debian community are still superior to those pompous fun-compiling gentoo users.
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?" `":" #");}
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?
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 ofe /19263
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.
projects some of us have to work on. I *do* enjoy programming very much, but I also get stuck in boring stuff waay too often. And yes, I need to put food on the table for me, wife and 2 kids.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
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 have a preference for direct access to the cvs. For more casual coders, or those who just want to wander around looking for interesting things to help on, the wiki frontend could help.
That being said, I have no idea how well this idea could work, but for smaller prototyping projects it might just work.
...makes the -- aw, fuckit.
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
JavaScript backend
Perl 5 backend
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.
Are you adequate?
if it wasn't for my Mom's attitude towards us doing it.
If you take the attitude that it's okay to stop without holding everything to a nebulous standard of clean, it becomes easier.
The article was about optimizing development, not optimizing code.
Badass Resumes
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.
- -- Truth addict for life.
Tcl (and Tk) is still hanging in there, chugging along. Some recent developments:
Tile: modern look and feel + themes for Tk: http://tktable.sourceforge.net/tile/
An object system for the core: http://www.tcl.tk/cgi-bin/tct/tip/257.html
I think the other big thing that's still missing is to make the standard distribution 'batteries included' - we'll see if we can make that happen soon.
I love the language, in any case, it's super easy to get people started with, and if you look under the hood, it's coded very well, and has an *extensive* C API. That was what really sold me on the language - the ability to really integrate it well and easily with C code. Python's C API is good too, but I thik Tcl's is still broader.
http://www.welton.it/davidw/
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
In my blog entry Disorganized Incremental Software Development, 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).
Music: a super-stimulus for the perception of musicality. Musicality: a perceived aspect of speech.
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 conform. Yes, you do still have to write boring bits of code but there is a nicer feeling all around, together with a drop of professional pride on every line written. This over-all vision has taken many guises - clean code trees, re-use, falling into a meaningful code hierarchy, writing code which is more service driven. As you advance, your higher level vision also grows. With it, you'll find greater professional pride, better code, more arguments with management and a bigger head. Primitive and closed minded environments can be a hinderance, but you have to persist. I do agree though - if you can keep the 'fun' alive, it does result in better code. What we shouldn't forget is that it's not 'all fun, all of the time.'
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.
There you are, staring at me again.
on why chromatic considers a perl6 interpreter "a frivolous project".
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Definitions of frivolous on the Web:
* not serious in content or attitude or behavior; "a frivolous novel"; "a frivolous remark"; "a frivolous young woman"
wordnet.princeton.edu/perl/webwn
Related phrases: list of frivolous parties frivolous complaint frivolous lawsuits frivolous lawsuit frivolous suit
That's the question: I even resent calling pugs "a toy Perl6 interpreter". I think it's a serious project, optimized for the fun of its committers. And watchers, like me. But it works a lot and it's teaching me a lot of stuff I didn't know. Being fun is not the opposite of being serious, that is to say, being fun is not the same of being frivolous.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Cool. My original post gets modded off-topic and my reply to a reply gets modded troll. Woohoo!
"You'll get nothing, and you'll like it!"