Friday, June 29, 2007

Oh, Yegge...

I followed one of the myriad links to Stevey's Blog Rants for the Rhino on Rails explanation (long story short: for the rest of us, JRuby on Rails or Grails probably makes much more sense, even if the project wasn't internal at this point). On the other hand, if it leads to enhancing/updating Rhino, go for it, guys!

I was a little tickled by a different entry on Rich Programmer Food (or, "Why Stevey thinks programmers should be at least familiar with how actual compilers work"). Stevey gleefully pokes fun at C++, Java, and Perl as a matter of course (especially Java--have you read about the Kingdom of Nouns?). But do you suppose he knows that part of Perl 6's design is the ability to write grammars? Moreover, the Parrot work has led to a set of tools that make implementing languages for Parrot easier. Compiler theory and DSLs, indeed!

Thursday, June 28, 2007

peeve no. 249 is the casual use of 'random'

As rants go, the capriciousness of this one is up near level 11. I hardly expect anyone else to share my irritation. Nevertheless, I must tell the World.

In my opinion, the everyday use of the word "random" is nearly always inaccurate. If someone you were talking with abruptly switched the conversation's subject, neither that person nor the shift was random. It may have seemed random, but only because you weren't insightful or knowledgeable enough to fathom the connection.

To be fair, the mental leaps people are capable of making can be incredibly subtle and creative, even to the point at which the likeliness of anyone else duplicating the leap is nil, whether with or without the exact same set of information. Don't call it random. Mental leaps are essential to progress.

If someone shifts mood suddenly, the chances are good that it isn't random, although someone's true motivations may be cloudy at best. The cases that come closest to randomness are those in which the emotional imbalance is clearly linked to a chemical imbalance - and in those cases the underlying cause is definite!

Humor that consists of events happening outside of rhyme and reason is not random, either. It's a writer frantically hurling nonsensical ideas when he or she doesn't care enough to write organized material. Unfortunately, such "humor" is its own undoing, because sooner or later the audience will notice the absence of any point, then naturally wonder why they're settling for such. One should also note that even "random" humor can't, in fact, be truly random. True randomness alienates an audience. Seriously. Use some dice or something to pick a set of elements, then combine the elements. The result will not cause laughter so much as perplexity.
Humor isn't random; it must be constructed so that it works.

Sometimes the actions of large organizations, or the managers of those organizations, may be labeled as "random". If thinking that makes one feel better, fine. Specific decisions perhaps actually have random elements (if two products are so similar in price and features as to be practically indistinguishable, who cares which one will be bought?). The reasoning behind other decisions may seem shaky or hasty, at best. But you better believe that when manager 3 suddenly starts advocating wonder technology 6, the idea did not enter his head by accident.

Tragedies, or the victims of tragedies, feel "random". My genuine (discomforting) advice is to abandon the illusion that the Totality Of Reality operates according to well-defined rules at any time, tragedy or not. I have barely any control over what happens to me. Neither do you. Those in supreme positions of power don't either; they could be eliminated by microscopic organisms, an assassination, or a coup. If "random" is a synonym for "out-of-control", then "random" is just the way things are.

Ugh, now I'm depressed. Stupid Total Perspective Vortex.

Monday, June 25, 2007

unintentionally funny

This may be in poor taste, and serves as further evidence that my mind is frightfully twisted in at least one of the lobes, but...

I was reading yet another reminder that working with computers involves proficiency at both "hard" tasks like logic/algorithms) and "soft" tasks like psychology, when I encountered this statement: "People are a 'soft' subject. Squishy, hard to nail down..."

I must say that I fully agree. In my experience, people can be squishy and hard to nail down.

Friday, June 22, 2007

software development ghost story: one guy vs. the Company

Creating My Own Personal Hell is one freaky read about someone who fills every role in a project, yet can't seem to make "the customer" understand the constraints of time/effort on the end product. That is, cutting testing time will be counterbalanced by increasing bug-fixing time later. Increasing time on bug-fixes will be counterbalanced by decreasing the time available for implementing new features/builds/releases. And on and on...all the common tradeoffs that seem to be integral to any project, but magnified.

To some degree I can relate to the frustration of filling multiple roles, working as I do in small-shop, in-house software development, but I feel immensely grateful for the others on my team (not to mention the folks who man customer support).

Thursday, June 21, 2007

objectifying javascript

The more things change, the more things stay the same. The Javascript code for the Ajax project I've worked on (the same project that motivated me to make a set of functions for mapping data onto widgets) was giving me rude flashbacks to the line-numbered BASIC days of yore. Global variables and functions are the way I've always written my Javascript (didn't everybody?). I figured it didn't matter, as long as I kept everything straight in my head, and continually looked for opportunities to replace duplicated code with functions....but then my head asplode from the criss-crossing interdependencies between all the separate bits.

Luckily, there are some pages out there that demonstrate a possible way out of the mess. Javascript Refactoring for Safer Better Ajax serves as a great guide and template for moving globally-accessible procedural code to finely-structured, encapsulated object code. Those who are a little rusty may find it helpful to first read about the syntax of Javascript custom objects at the mozilla project's developer site, or wander through Douglas Crockford's Javascript site. Structure your Javascript! recommends the less intricate approach of placing functions into nested objects to achieve namespace emulation.

The path I chose was more or less a compromise. As much as possible, I tried to identify distinct parts or organizational units in my Ajax application code. Then, for each unit, I created a singular global object containing the associated variables and functions. In effect, I broke the code up into object "modules". "Module" is a better descriptor than "object", because there still are no constructors and no real use of "this", nor is anything even remotely private (other than the few function definitions I moved inside of other functions). In other words, the code has not so much been rewritten as reorganized or relabeled. Frankly, the code's sanity may not be much improved, but mine should be.

Tuesday, June 19, 2007

Python 3000 Status Update

Link here. I admit to not currently using any implementation of Python for work or play. Many months ago I experimented with Jython for some job tasks, but since then the night-and-day difference in momentum between the Jython and Groovy projects has led the decision-makers to prefer Groovy. Either way, most of the code I work on remains Java or C#.

Nevertheless, I'm glad to see Python 3000 is almost there, and just as glad to see that some of Python's little quirks will be corrected. As Guido explains, the changes are intended to make Python more pythonic! Die, '<>' operator, die!

Yay for Unicode support, with bonus points for properly crediting Java as the design inspiration. I wonder how restless the natives may become when they notice that Python 3000 has separate object hierarchies for streams and bytes, abstract base classes, "annotated" function signatures, "print" as a function...

Friday, June 08, 2007

Perl monkey

I was building up one of those *nix command pipelines that should never be underestimated (in this case a diff piped to grep piped to...), when I was reaching that threshold at which a one-line command blossoms into a full shell script.

Like a garage tinkerer who reaches for the trusty screwdriver, instead I broke out a Perl one-liner to do the task. A major contributor to the shape of Perl's often-lambasted cryptic syntax is its borrowing from sed, awk, and shell, not to mention the integrated regex (as some have said, Perl is "postmodern" or a "Swiss army chainsaw"). I'm not apologizing for it, but just stating the obvious once again.

Any-who, perl has three parameters that are helpful for these situations: -p for looping over lines from stdin and automatically printing out the final value of the "default variable" $_, -e for specifying the code to execute (within single quotes - use hairy regular expressions or multiple statements separated by ; at your code maintenance peril!), and -a for "auto-splitting" the input line into the list @F. Combine the three and you get "perl -ape". Thank you, my Perl monkey, for helping me get my work done. Even if you can be messy, at least you're trainable.

Wednesday, June 06, 2007

impressions of Star Wars: Sacrifice

In the Legacy of the Force series, Sacrifice is an obvious turning point. To say this book has some significant plot developments would be an understatement. My motivation to finish it was so strong that I kept coming back to it (generally, I'm not the type who reads for hours and hours at a time). Inhaling such heady material so rapidly has produced some strong impressions.

The primary point, that hardly bears mentioning, is that this is a book by Traviss. The three authors who are collaborating on the Legacy of the Force books are in a rotation. For me, the mental sensation is akin to watching a shape turn in mid-air to sequentially expose each of its faces. If Allston is writing, there will be some humor to the proceedings, space battles, and Wedge and Corran. If Denning is writing, there will be probably be a load of references to the Dark Nest books and a good all-around balance between descriptions of the action and corresponding character introspection. If Traviss is writing, there will be Boba Fett and Mandalorians, conciseness, and musings about the gray area between good and evil. But that doesn't mean I have to like it.

Emperor's black bones, there's a lot of musings on moral ambiguity. It got so old. Every kriffing character in the book had to have a moment of thinking, "I'm so unsure of what to do. Formerly I had a childlike clarity of what separates right from wrong, but after enduring moral dilemma [fill in the blank], I got confused. Maybe after I undergo painful situation [fill in the blank], I'll abruptly shift into passionate, unreflective certainty." Yes, we get it, a sense of innocence is fragile. Adults sometimes do squeamish things for the greater good. In the Expanded Universe, the characters have gone through incredible tragedy. Now can we switch back to the Star Wars in which the characters exhibit fairly good-natured gallows humor instead of jaded quips? (I suppose for Mara, some sharp words are normal. But shouldn't the Jedi Council talk formally like a Jedi Council?)

I knew there'd be more Fett and Mandalorians, just not this way. Although those scenes give the book some touching moments, I have trouble viewing them as anything other than interlopers, or pages that fell out of another book into this one. Including authentic Mandalorian words in the text is an annoying practice. How odd is it that in this book the main characters seem to discuss Fett and/or Mandalorians surprisingly often, but in pretty much every other Star Wars book they, well, don't? About as odd as Han Solo and Alema Rar having more or less cameo appearances.

The dialogue otherwise bugged me in a few places, but I'll concede these are minor nitpicks. I still insist that Star Wars characters should not live or talk too similarly to the reader. "'Freshers need a good clean. Here's a toothbrush", for instance, is too close to reality. So are certain idioms, like "There's anger, and then there's being controlled by it - not seeing the forest for the trees", and "even if that cousin was a grade-A scumbag". Too many references to, or even quotes from, the original trilogy movies is also an excellent way to tear me out of the story (I seem to remember the line "no disintegrations" coming into play in one of Fett's scenes). This is the Legacy of the Force book series. Decades have passed in the timeline. Let it go.

Something I can appreciate is when a story has important deaths. If the title doesn't give it away, this book has a few. Undoubtedly, a tragic tone fits some parts quite well. A memorable image in my mind is the description of a "gel" droid designed to both look and act like a specific person for realistic target practice. The droid sustains a hit, reacts like a person...then self-repairs and clambers back upright. After many such cycles, it struggles helplessly to get back up again. Creepy.

Apart from deaths, the continuing series storyline moves along via a power shift. Audaciously, the shift occurs with apparently minimal disruption to all involved! I found this fascinating. People working within the law, preserving the peace, but simultaneously making power grabs. I suppose it makes sense from the point of view of cost-effectiveness. Why replace something when one can just appropriate it? Why demand allegiance when one can just fabricate legitimacy?

Something else that surprised me was the elaboration of the Niathal character, whom I enjoyed more and more as the book proceeded. I think it's fitting that someone who interacts with Jacen so much should take on more dimension, both because of being in the book's "spotlight" and her role of acting as a counterpoint to him. My hope is their personal interactions will become complex and nuanced (wheels within wheels, etc.) and not degenerate into a simpler form.

Maybe my favorite quality of Sacrifice was its resolute movement forward; ignoring the Mandalorian detours, I seldom felt like I was reading filler. Each chapter propelled me to the next. It was a fun ride, but be prepared for the bumps.

Sunday, June 03, 2007

code hygiene

A blog entry about code reuse through "recontexting" used the term "hygienic code", and I must admit that it left me confused at first. One of the comments asked for clarification. The meaning of "hygienic code", expressed in a follow-up comment, was "Hygienic code does exactly the task at hand, without introducing anything extraneous. As an example, rigorous application of AOP can be pretty hygienic, if all cross-cutting concerns can be implemented as aspects."

My confusion arose out of the way that I understand the definition of a hygienic macro, because recontexting appeared to do the opposite. (Side comment: I seem to recall reading once that un-hygienic macros, while harder to use, can accomplish particular tricks easier than hygienic macros). If code is hygienic when the reused code (whether macro or function) and the context code have no side-effect transformations of variables, then shouldn't it therefore not be hygienic when code undergoes recontexting, where recontexting consists of directly changing the meaning of a symbol in the reused code? Maybe this is what the blog author is alluding to in a later follow-up comment: "And, BTW, all of these approaches [OO, dependency injection, "hygienic"] have been criticized for their reliance on runtime black magic." Code that runs differently depending on context (as opposed to parameterized code that runs differently depending on arguments passed in) can be harder to trace. It's not that far removed in actuality from code that refers to global variables.

On the other hand, as the blog entry says, recontexting code has the unenviable goal of trying to reuse code without 1) originally writing the code to be reusable, or even 2) modifying the code at the time of reuse to be reusable. Also, the fact that the context is explicitly treated as a code configuration setting (reminiscent of an application.xml) makes it more acceptable to me than, for instance, a procedure that loads a class at runtime, changes it five ways, then passes the class (probably an instance, actually) to another procedure. I prefer to not take dogmatic stances on software development, but instead loudly point out the tradeoffs.

It's amazing how code can morph when one throws strict (compile-time or run-time) code contracts out the window.