Friday, December 10, 2010

Coding Contest: Can Perl 6 Scratch Your Itch?

There is a coding contest that just went up to encourage folks to try out Perl6:

If this is an itch you'd like to scratch, you might also check out:

Rosetta Code for examples of using Perl 6 to solve familiar problems:

The Perl 6 Website:

Monday, October 4, 2010

OLPC XO-3 joins the Marvell Moby Collective

According to this article Marvell has given the OLPC project a $5.6 million dollar grant to fund designing the XO-3 around a complete system on a chip (SOC) produced by Marvell. -Which will be based on the Marvell Moby reference platform.

This means that the OLPC XO-3 Arm tablet's R&D is now fully funded.

And Marvell's $99 tablet may not be vapor after all.

$99 tablet availability in 1st world countries is projected for 2011. 3rd world countries will have to wait on the OLPC XO-3 till at least 2012.

Friday, October 1, 2010

Perl developers step up to Marvell Mobylize $100K Challenge?

Marvell Technology Group Ltd has announced a $100K challenge to developers interested in making creative, innovative, and engaging educational applications for their $99 Android based ARM tablet. Aka the Moby Reference Platform. Note: this is the same reference design which the OLPC intends to use as the basis for the XO-3.

Will Perl developers enter the fray? Is Perl support in the Android Scripting Environment ready for prime time?

Application submissions will be accepted from Oct. 11th thru Nov. 11th. Winners will be chosen and awards given during the 2011 International Consumer Electronics Show in Las Vegas, January 6-9, 2011.

[From the Marvell $100K Challenge website:]

Start thinking now of your most creative ideas on developing the best tablet app for teaching children any one or more of the following subjects:
  • Math
  • Science
  • Vocabulary
  • Geography
  • Social studies
  • Grammar
  • Spelling
  • Other curriculum most common to children in Kindergarten all the way up to and including the 12th grade.

Marvell is providing a few general rules2 below to help you get started on your winning app which, at a minimum:

  • Must be education related – teaching new skills and target the K-12 classes.
  • Should include multi-lingual options and features for use by English and foreign students.
  • Must run on an Android™ platform
  • Must have a connectivity aspect – the app needs to be connected to the web for premium experience and performance
  • Must leverage a multi-touch and user friendly interface
  • Be comprised of less than 512MB
  • App preferences welcomed, but not required, may include:
    • a "social network" learning aspects such as learn with your school buddies or challenge the students online
    • "plug and play" programs
    • apps that connect with current school based programs like Blackboard™ and Moodle™.

More information regarding the contest will be released in the coming weeks. Sign up here to receive breaking updates.

Wednesday, February 17, 2010

Open source: dangerous to computing education?

This is a response to a recent blog post by Mark Guzdial, chairman of the ACM education board.

Open Source is an integral part of a well rounded computing education.

While I will praise efforts to raise awareness of demographic barriers in open source development, I would challenge Mark to do a better job lining up his arguments and checking his references. Especially when many of his links have little or nothing to do with the statements attributed to them.

His link "more closed and less diverse than commercial software" links to a National Center for Women in Technology recruitment flyer. -Which sounds like a wonderful organization, but having read it now 3 times through says nothing about open source being more closed or less diverse.

The next link "overwhelmingly White or Asian and male" links to a OSCON presentation which says a lot about the male/female ratio... but nothing about white/asian demographics. Furthermore, it is a presentation which shows that the open source community is making efforts to draw awareness to the issue and improve the situation.

Mark attribute a quote to Linus Torvalds: "Talk is cheap. Show me the code." -But that quote is notably absent on the page he links to to reference it.

I'll grant, that that quote certainly sounds like something Linus would say. I have heard it many times in many open source projects. Taken out of context, it is used to imply that talk and conversation are undervalued. However, that saying is most frequently asserted during a conversation about:

1) A potential bug
2) Someone asserting that one implementation is preferable or superior to another

In the first case it is notoriously difficult ( to isolate a problem without access to the code.

In the second, the noise to signal ratio of conversations quickly become quite poor unless the conversation is rooted in actual code.

Legitimate Peripheral Participation exists in open source communities. Non-developers provide some of the best documentation. For the usability issues mentioned, non-developers are often better at writing documentation than the actual developers. They often help triage bug and issue tracking systems. And they can gradually move into development by bug testing and submitting tests which reproduce those bugs. And even when they don't gradually move into a developer role, they can become useful and respected members of a project by helping other users on mailing lists and IRC channels.

In Mark's closing paragraph, he disparages the open source community by painting it broadly with the religious zealot/fanatic brush stroke. It is true that open source has its zealots and fanboys. Apple, Microsoft, Google, etc. all have some rather intense supporters whose support relies more heavily on a go team mentality than on solid engineering. However, successful open source projects like the aforementioned companies also tend to have a core of solid engineers and skilled developers.

In closing, I applaud Mark for raising awareness of gender disparity in open source communities. And I would criticize him for implying that Open Source is "dangerous". I would remind everyone that correlation does not imply causation. There are many causes of a gender gap. My current employer has roughly 33% women developers in my department. When I started it was 0%. Things are getting better. That isn't an excuse to be complacent or dismissive of problems where they exist. We can and should strive to do better.

Sunday, February 7, 2010

Book and movie review: Kiln People vs. Surrogates

A couple weeks ago, I finished reading Kiln People by David Brin.

A couple nights back, I watched Surrogates starring Bruce Willis.

Kiln People was published back in 2002. The plot can be quickly summarized as... In a future where individuals can send short-lived clones of themselves out to accomplish tasks and later reintegrate... A gumshoe detective in the midst of cornering his arch nemesis drops down a rabbit hole into a convoluted conspiracy of epic proportions.

David Brin performs his usual phenomenal job of exploring the possible effects of future technology on society. However, the story takes a back seat to world building. Kiln People is a good read, but it is not a page turner.

Surrogates was released Sept. 2009 and follows nearly the same plot (without crediting Brin). Instead of clay surrogates we have robots. The conspiracy is streamlined and simplified... but leads to the same destination. The introspection of technology and its affects on society are dumbed down to stereotypical hollywood levels: "pretty people", "personal tragedy", "love story", and "technology bad". Surrogates is a good popcorn and carbonated beverage flick. You'll probably enjoy the ride. But you won't take away much to ponder or think about.

(If you'd like to read David Brin's take on Surrogates, check out the following post on his blog.)

Monday, July 27, 2009

Perl's popularity problem...

There has been a recent flurry of blogs on Perl's perceived popularity problem:

I'm a little cynical. Many good insights and areas for improvement are identified. But Perl needs to gain mindshare. And the only way to do that is to deliver the goods: Perl needs best of breed and/or innovative killer apps...

There is very little going on today which makes Perl relevant to anyone outside the Perl community. The reality is that Perl isn't much on anyone's radar except the people who already use it...

The insights which particularly appealed to me are:

  • Perl5 and Perl6 could definitely benefit from a "This is not your father's Oldsmobile" slogan. Perl doesn't market itself well.

  • Perl could use a modern clean cohesive comprehensive web portal which borgs the best of what the scattershot sites out there provide: CPAN, PAUSE, Perl Mongers, perldoc, perlmonks, ironman, use.perl, perlbuzz, the various community SCM repositories, professional training, perl jobs, etc. An effort to unify those disparate sites and services into a cohesive whole using modern and enlightened Perl would give Perl5 a chance to redefine itself.

Perl may look dead to outsiders, but there is a lot going on within the Perl ecosystem. There is: Perl6 (std, Parrot, Rakudo, SMOP), Moose, Catalyst, DBIx::Class, The list will vary from one Perl programmer to another. There is Padre, which shows promise of being of interest to non-Perl developers. And new in-roads into Bioinformatics. But O'Reilly and James Tisdall laid that foundation back in 2001 and 2003.

Another problem we need to answer, is why projects which are bootstrapped with Perl leave it behind?

Git, Linus Torvald's SCM love child, was originally assembled with a whole lot of Perl duct table, bubble gum, and glue. But if you visit, you'll be surprised by how irrelevant Perl now appears to be to git.

Where are the new exciting, relevant solutions which use Perl?

Maybe they exist, but we're not aware of them? Muldis Rosetta is a truly relational RDMS (not SQL) being developed by Darren Duncan. Sounds interesting and promising... Does it work? Is it fast enough? Is it ready for use in production environments? Can it work with DBI, DBIx::Class, ODBC, JDBC, etc? Why aren't more developers involved with it?

Mojolicious looks like a fresh new MVC. In a fairly crowded field, it may be hard to distinguish itself. Take a look at Sebastian Riedel's recent Mojolicious::Lite blog.

Where are the other fertile grounds from which new solutions will arise? What other projects are out there which are using Perl to solve something new or solve an old problem in a better way?

Thursday, July 9, 2009

Legacy Traps

Here's an interesting dialogue from #perl6 yesterday:
TimToady  but the fact is, Perl 5 is basically in a no-win
situation long term, which we first recognized in
PerlJam TimToady: now you're alienating all the staunch perl
5 supporters :)
TimToady I'm only alienating them "long term"
KyleHa If loving Perl 5 is wrong, I don't want to be right.
PerlJam Someone mentioned (probably on use.perl somewhere)
that Nicholas tried regular release cycles a while
back. I'd like to know if that's true and if so,
what became of it.
ruoso I don't really think the regular releases is the
TimToady I love Perl 5 too, but it's stuck (culturally, and
maybe technically) in a legacy trap, and the Perl 6
approach is the only long-term way out of that.
moritz_ ruoso: it's not about *regular*, but about being
able to release when there's something to fix
TimToady Perl 5 is a velociraptor, but we need an
acceloraptor now.

There ought to be a corollary to that saying about "Fast, Good and Cheap. -Pick any two". -Something to deal with legacy vs. innovation and revolution vs. evolution. But I suppose the latter is fundamentally a balance between looking backward while moving forward, the threshold of pain you're willing to undergo, and how you attempt to minimize it.

I wouldn't pretend to have the experience or wisdom to find the right balance. However, it doesn't appear to be a new problem.

C++ went through a period of upheaval not too long ago. There was a nice Dr. Dobb's article on it back in 1997. Well worth reading.

Here's a Linux kernel developers thread on the same topic of evolution and change. -A nugget from Theodore Tso:
"Clearly, we are right to mock Solaris for making claims that
they will never, ever, *ever* change an interface, not even
one that goes back sixteen years to Solaris 2.3. But it
doesn't follow the opposite point of view, that constant
mutability of kernel interfaces to make sure that things are
always perfect and pure and clean is the right one either."