Wouldn’t it be neat if web browsers had more client-side languages available? Wouldn’t it be kind of cool if you could code up your app in Tcl and place it in a script tag? Well, it turns out you actually can (sort of)! The below Tcl code is mostly non-sense, but it does do some DOM manipulation, and you can see it in action here.

<script type="text/tcl">

proc appendTextNodeToElement {divId text} {
    set div [document getElementById $divId]
    set textNode [document createTextNode $text]
    $div appendChild $textNode
}

proc listNames {name1 name2} {
    if {== $name1 $name2} {
        set nameStr $name1
    } else {
        set nameStr "$name1 and $name2"
    }
    puts "hi $nameStr"
    return $nameStr
}

appendTextNodeToElement "testDiv1" "This is a test!"
set names [listNames "Bob" "Alice"]
appendTextNodeToElement "testDiv2" $names
appendTextNodeToElement "testDiv3" "2 + 2 = [+ 2 2]"

</script>

It turns out that when a web browser is parsing a script tag, if it doesn’t recognize the “type” attribute, it will ignore the code within the tag. This allows newer browsers to support additional languages without breaking older browsers. However, the older browsers still leave the contents between its opening and closing tags there, so if you have some JavaScript code that will parse and interpreted it, you can execute it.

The idea fascinated me and I wanted to see if I could whip up a proof of concept. I found a neat open source Tcl interpreter written in C called Picol, which was only 550 lines and covered only a sub-set of the language. I figured this was perfect for my needs and decided to see if I could port it to JavaScript. The port was really straight forward and I was pretty amazed when I actually saw it working. I went ahead and added in a few DOM manipulation functions, but decided not to get too carried away. The code for this is available here. I only went far enough to get a proof of concept though, so it’s not very feature rich. I also don’t really have any plans to go further with this, I just sort of got excited at the idea and wanted to see what would happen.

I also decided to search around and see anyone else had ported other languages for use on the client side. I ended up finding some code written by a Dutch programmer which allows for LOLCODE in the browser (zip mirrored here). However, rather than interpreting the code, his method converts the LOLCODE to JavaScript, and then appends this new JavaScript into the web page via a script tag. Still neat though.

Also, I’m aware interpreting code with an interpreted language isn’t the best idea performance wise, and that there is currently a growing number of languages that compile into JavaScript. So client-side developers aren’t technically limited to just JavaScript, but I do still find the idea of JavaScript-based interpreters kind of neat.

Lastly, there are a couple of JavaScript Tcl interpreters out there already. I played around with a few, but ultimately found them a little too confusing, and I wasn’t sure they were made for what I wanted to do (basically act as a JavaScript substitute), so I passed them over when doing this experiment. However, I’ll link to them below for those of you who are curious.

• incr Tcl in Javascript – Includes a lot of the Tcl language features. Examples of its usage are available here.
• Rapid Application Programming Language (RAPL) – I’m not completely sure of what separates this from the previous library, but you can see an example here.

I know, I know, tomato-tomahto, but I’ve had people tell me I say it wrong when said each way, which has left me rather confused, so I decided to do some research and figure out how SQL is actually pronounced. SQL is the language used for querying and managing data in a relational database system. Some people say S-Q-L and some people say “sequel”. This difference in pronunciation also effects the writing of documentation. The indefinite article that’s used before the term (a or an) is based on how it’s pronounced (try saying “a SQL” and “an SQL”). No one wants to sound ignorant, so which way is correct? It turns out they’re both correct/acceptable, but that the S-Q-L way of saying it is more “official”.

SQL was initially developed at IBM by Donald Chamberlin and Raymond Boyce. It was initially called “Structured English Query Language” (SEQUEL) and pronounced “sequel”, though it later had to have it’s name shortened to “Structured Query Language” (SQL) due to trademark issues. It was created to supplant the then popular QUEL database language, and the name “sequel” was meant as a pun (it was the sequel to QUEL) [1]. However, this leads to the big question – was language still called “sequel” after the name change?

If you look at Oracle’s official documentation on SQL, it says it’s still pronounced “sequel” [2]. However, if you look at MySQL’s official documentation, it says “MySQL” is officially pronounced “‘My Ess Que Ell’ (not ‘my sequel’)” [3], and Wikipedia says SQL is officially pronounced “S-Q-L” and references an O’Reilly book on the subject [4]. So this is no help, the major sources aren’t agreeing on the way it’s “officially” pronounced.

Then a thought occurred to me: SQL was created in the 70’s, the creators are probably techies, I can probably just email them and ask them how it’s pronounced! Ray Boyce had passed away at a young age, but Don Chamberlin was alive and now teaching at a university. I felt a little silly, but I decided to fire off a short email to him:

Hello Don,

I’m sorry to waste your time with such a silly question, but I’ve often heard SQL pronounced S-Q-L or as Sequel. I’ve also seen the official pronunciation listed both ways. According to wikipedia, you and Raymond Boyce created the language and it was shortened to SQL after some legal dispute. So my question is, is there an official pronunciation to SQL? Thank you for your time.

– Pat

To my delight, he replied back:

Hi Pat,

Since the language was originally named SEQUEL, many people continued to pronounce the name that way after it was shortened to SQL. Both pronunciations are widely used and recognized. As to which is more “official”, I guess the authority would be the ISO Standard, which is spelled (and presumably pronounced) S-Q-L.

Thanks for your interest,
Don Chamberlin

I felt a little dumb wasting his time with such a goofy question, but I was thrilled he replied back. Later I would find out that he himself pronounces it as “sequel” [5], so it’s interesting he would be so unbiased, though I suppose his pronunciation is consistent with him noting that the original guys kept calling it “sequel”. With this I felt I had found my answer: Both were acceptable, though the standard indicated S-Q-L was probably more official.

I don’t have any plans to be that guy and start correcting people who say “sequel”, though now I feel I can at least defend saying S-Q-L if someone tries to correct me. Additionally, while this may seem like a really trivial matter, some people seem to take it rather seriously. On a thread at Oracle’s message forum, a DBA who pronounces it “sequel” mentioned that “I’ve rejected interviewees because they didn’t know how to pronounce SQL … If you can’t pronounce it correctly, then I have doubts as to your ability to use it correctly.” [6] Though then again, the Oracle community seems to have adopted the “sequel” way of saying it, so maybe adapting to whatever environment you’re in is the best policy. Whatever the case, knowing why it’s said one way or another can useful.

[1] http://www.ibphoenix.com/resources/documents/design/doc_123
[2] http://docs.oracle.com/cd/B10501_01/server.920/a96540/intro.htm
[3] http://docs.oracle.com/cd/E17952_01/refman-5.1-en/what-is-mysql.html
[4] http://en.wikipedia.org/wiki/Sql
[5] http://www.youtube.com/watch?v=ghxpXpTuALM#t=33m23s
[6] https://forums.oracle.com/forums/thread.jspa?threadID=630585&start=15&tstart=0

The Muller Formula is a neat little color formula that aims to predict which sets of colors people will find pleasing. No actual formula is given for it, but it’s concept is described. Given a set of colors with the same hue but a different lightness, the colors with the lighter hues should be shifted to a more naturally bright color and the colors with a darker hues should be shifted to a more naturally dark color. I thought this was a neat idea and figured I could possibly simplify it to work with a single color (what I decided to call a “Muller Color”). If a color had a high lightness, its hue would be shifted to a naturally light color. If it had a low lightness, its hue would be shifted towards a naturally darker color.

The original article used a the traditional artist’s Red-Yellow-Blue color wheel. I wasn’t able to find a good conversion formula to go from the Red-Green-Blue color model (RGB) (which is popular in computing) to the Red-Yellow-Blue color model (RYB), but I did find formulas to go from RGB to the Hue-Saturation-Lightness color model (HSL). I figured this would work well since the HSL model had everything I needed to calculate a “Muller Color”. I could detect the lightness of a color and then adjust its hue accordingly.

Looking at the HSL color wheel, I decided to use the primary colors (Red, Blue and Green) as the more naturally dark colors, and the secondary colors (Yellow, Cyan, Magenta) as the more naturally light colors. This decision was just based on my own judgement. Using the HSL color model and the concept described by the Muller Formula, I was able to generate interesting colors from RGB inputs. And to make a long story short, I ended up using this idea in my Image to Color Palette Generator app. A color palette would be generated of an image, but in addition, the user would also see a palette of the corresponding Muller Colors.

I figured I was done with this idea until I received a recent email from someone suggesting I take the images people input into the Color Palette Generator program and create “Muller Images”. Basically, call the Muller Color formula on every pixel in the image and generate a new image. I thought this was a really cool idea so I whipped up a quick prototype which you can see here. The shift percent indicates how much a color should shift. For example, if the color is between red and yellow and the shift is 100%, it will become yellow if it’s light and red if it’s dark (a dark yellow would even end up becoming red and a light red would end up becoming yellow). If the shift is just 50%, it will just shift 50% of the way closer.

Unfortunately, the results weren’t as stellar as I hoped. Calling the Muller Color formula on every pixel caused them to gravitate towards similar colors, so the resulting image tended to look like poorly compressed gifs. An example of a 10% shift can be seen in the Bernie Madoff pumpkin pic below.

It was still a cool idea, and maybe it could still be used for something, though it’d probably have to be tweaked a little bit. There are other images available to Muller-ize on the experiment page if anyone else is interested. Thanks to David Dailey for the idea on this one.

About a month ago I had an interesting idea for my Text Ascii Art Generator (TAAG) program. Though due to being busy with work and buying a house, I haven’t had time to try it out. However, the idea is applicable to almost any web service, so I thought I’d share it with you all in case someone out there was looking for a nifty way to make some extra money off of a web app or blog without posting a bunch of ads up. I’m aware that too much commercialism can kill a website, however, I think this idea is kind of clever.

The idea originally struck me when I was brainstorming improvement ideas for TAAG. I thought that it might be cool if the user could put their output on a t-shirt. It’d make for a really neat way for someone to show their techiness/geekiness. After deciding I liked the idea, I then wondered if the t-shirt companies had already thought about 3rd party applications creating dynamic designs for them. After some quick googling, I discovered they had.

Both Zazzle and SpreadShirt allow you to dynamically submit designs for t-shirts which you can then sell. CNN even uses SpreadShirt to sell t-shirts of recent headlines. And you’re not limited to just t-shirts, you can put your designs on all sorts of crazy products – mugs, purses, hats, buttons, mouse pads, shoes, postage stamps, posters – the list goes on.

I’m not advocating turning your web apps or blogs into online stores, but if carefully used, this could compliment their output. An online photomosaic program that would let you buy a poster of your output might be kind of cool. And web comics that would let you buy t-shirts of your favorite comics would probably do pretty well, I had a whole bunch of Far Side t-shirts when I was in middle school.

Though as I said at the start of this post, I haven’t done any of this myself yet. I talked briefly to the FIGlet creators and they were cool with the idea, however, since I didn’t create the fonts themselves I’d feel wrong selling products with other people’s artwork on them without their permission / giving them a cut, and since there are over 300 fonts, this creates a rather complicated situation. So I may not even implement this idea (I’m still thinking about it though), but I figured I’d share the general concept, since it appears it could apply nicely in certain situations.