2024- 2023
- 2022
- 2021
- 2020
- 2019
- 2018
- 2017
- 2016
- 2015
- 2014
- 2013
- 2012
- 2011
- 2010
- 2009
- 2008
- 2007
- 2006
- 2005
2004
Silence- Snowflakes
- Paranoia Pays
- Microsoft Help
- Polyglot 11: More C
- Polyglot 11: C
- Polyglot 10: Smalltalk
- Toronto Wisdom
- Exterminated
- The Last Straw
- BT Broadband Trap
- Polyglot 9: Moo
- Polyglot 8: SVG
- Polyglot 7: POV-Ray
- Polyglot 6: Python
- Polyglot 5: PHP
- Polyglot 4: Euphoria
- Polyglot 3: JavaScript
- Polyglot 2: Java
- Polyglot 1: VB
- POV-Ray
- Etch A Sketch
- Slashdotting
- Flashy Lies
- Scientific Illiteracy
- Creeping Featurism
- VidScope
- Saturn V
- Perspectives
- Slide Rule
- eBay Sale
- Iron Filings
- Gimble
- VBA Security
- Random Morsels
- Exact Change
- Easter Egg
- Diametral Pitch
- mod_deflete
- Ethical Spam?
- Deadlines
- CPU Power
- Fosdem 2004
- Academic Reversal
- Mars Memorial
- Culture Clash
- Watching the Users
- 2003
- 2002
Polyglot 9: Moo
9 October 2004
Some things are completely predictable. Here's my implementation of the colours application for Moo. Running example and source code.
Most programming environments are based around interchangeable modules. Apache or Zeus, Perl or Python, MySQL or PostgreSQL. Pick the ones you want, glue them together and your environment is ready to program. If one module can't cut it, replace it with another one. It's a good strategy with many obvious benefits.
The Moo takes the opposite approach. Everything is in the one monolithic database. The absolute joy of programming in a Moo as opposed to Apache/Perl/PostgreSQL is that when an error happens you get an entire traceback from the moment of the error all the way back to the starting command. Having everything in-Moo makes development, debugging and maintenance uniquely simple and straightforwards.
Which strategy is better? That's the stuff of holy wars. The truth is that in their pure forms both are good. But the monolithic approach only works in its pure form. Once you start bolting external dependencies onto the Moo the environment degrades to just another glue language (and not a very good one at that).
So when it comes to drawing an image (not something that's in the Moo's natural repertoire), one should try to avoid taking the modular approach of gluing some form of GD interface onto the environment. The Moo ought to create the image itself. There are two file formats which are suitable, SVG and BMP. This implementation used BMP. The verb that renders the bitmap automatically switches between paletted 8-bit colours and 24-bit true-colours as required. The only problem I encountered was that the spec I was using forgot to mention that BMPs are little-endian[?]. I only realised this when in desperation I started decoding a real BMP in a hex editor.
Update: Chris Allen pointed out that the generated BMP didn't render in MSIE. It turns out that the above menioned spec stated that a zero needed to be used where in fact a one was required. I've fixed the Moo's BMP renderer and informed the spec's author of the error. I've also found and corrected an unrelated off-by-one error that caused traceback in rare cases.
