Making Frameworks

Every few months we see a new framework springing up somewhere. Now we have too many choices. In fact it is little too much. Unfortunately, choice is something you don’t have in a typical enterprise. In an enterprise, software developer is coaxed to make use of many frameworks from which he would rather run a mile away. Not a day will go by without him criticizing them. Is something wrong with today’s developers? Why do they always keep criticizing about something which their managements rave about?

Before I continue I should clearly define, what I mean by (software) framework. I consider a framework to be a package (a closed box) of code that helps a developer to instruct the computer electronics to solve some problem. Now this problem could be of many types. You already know that instructing a processor in their native language (machine language) is no simple task. In other word this is a problem. To solve this we have the OS. Yes, OS is a framework too! Think about this. OS provides us with some basic APIs to read file, read from network, allocate memory , display output, taking input, and so many things. Your program doesn’t have to code them. OS provides APIs for them. So, OS too is a framework, which solves some common problems. To interact with Microsoft Windows’ API a VC++ programmer will typically use MS Foundation Class (MFC) library. This is needed since interacting with raw Win32 API in itself is a problem. It is very difficult to use. To ease that VC++ provides MFC framework. So, a typical framework also solves the problems in other frameworks.

No software in this world is perfect. If they were then there would have been no software industry, as service accounts for 70% revenue. They all have problems. This means there is always scope for a framework which solves that. However, the framework itself is a software, that means we need more frameworks to solve that! This has given birth to today’s infinite stack of frameworks. Stack of frameworks is no doubt needed but an infinite stack is always ridiculous. Infinite stack is a condition when developers try to fix problems from the top of the stack instead of going down and fixing the source of it. Unaddressable problems in a framework usually arise from design issues and lack of foresight. Perceived problems in a framework arise from framework user’s lack of understanding of the scope of it. In either case the developer using the stack should remove the problem framework, but usually end up adding a new framework to it. This is because – 1) It is cool to create a framework. 2) It is much easier to code a framework than make management understand why you want to change the stack. Once plagued with this condition the stack will inevitably grow like cancer until the hardware begs for mercy. At which point it will be declared that the stack is too advanced for current hardware.

Broadly classified, frameworks are of two types – thin and thick frameworks. Thin frameworks try to ease out some kinks in some other frameworks. Thick frameworks are the one which promise to do every god damn task you throw at them. In future if technology permits then maybe we will see a thick framework which will not only write the codes for you but also clean your kitchen floors. :p If you are a developer then you must have come across some frameworks like these.

It is interesting how sales people have changed the jargon to market frameworks. They do not use the word framework. They say it is a ‘technology’. Typically thick frameworks are marketed like this. Sales people will typically list out mind numbing number of features and at the end of the presentation the only thing you will remember is that this ‘technology’ is very powerful and hence awesome.

Endless frameworks stacks are no doubt ridiculous, but thick frameworks are evil. You depend on them and when things don’t work out the way you want then you will have run after their creators for help. Remember they are closed box. In industry parlance, they are black box. So, you know hardly anything about how it works. Do you want to take the risk of using something which does 90% of the job without you knowing anything about it? Thick frameworks, even when open source, are still dangerous. It is simply because they are so hard to code and could possibly have loads of bugs. This brings us to an interesting point. The code that we build on top of a framework in itself is a package of frameworks, in fact we can call that a framework too. So, does this mean the bigger the code is the more unreliable it is? Well yes, of course; but we try to minimize that by dividing the code into distinct (almost) independent parts. So, this means when evaluating a thick framework we must always try to identify the independent parts in it. If any such part is too big and complicated to understand then you should not go ahead with it.

A user of a framework must understand how the framework works. A normal user of OS need not know this, but as a developer you must know. This is because a normal user will always stay within the bounds of the foreseen scope, while the developer needs to push the boundary of it. By the time a developer understands that the current stack may not fully meet his requirements, it is already too late to change it. The only way around in this case is hack it! To hack it you need to know it inside out. For example, it is best to avoid a web framework which is so thick that you don’t even have the slightest idea of how it routes the HTTP packets inside it.

People now a days seem to miss the point of creating a framework and ‘technology’ stacks is solving problems, not multiplying them. Never make a framework which has more problems than the number of problems it solves.

Firefox 6 is out! Yeah and it’s not a beta.

Mozilla has gone nuts with their release version numbering. In a span of two – three months we get FF 5 and 6! Too good to be true? Yeah right. They say that it is just a number but these “just number” upgrade breaks extensions. At the time of writing this article Firebug was still broken in FF6.

Below I have pasted some interesting comments on this subject by other vexed FF users. (Src:


  1. Luis Elizondo wrote on August 16th, 2011at 9:16 am:

    Not enough changes for a mayor version release. I don’t want to be using Firefox 3569 next year!

  2. louisremi wrote on August 17th, 2011 at 12:37 am:

    We’ve changed our release cycles:
    Version numbers are just numbers, what matters is that we deliver features faster to you, Firefox users and Web developers.

  3. Jose wrote on August 17th, 2011 at 4:16 am:

    Considering that “just numbers” break extensions and make it just plain difficult for admins…

  4. Alex wrote on August 17th, 2011 at 6:19 am:

    Couldn’t agree more, Jose. Another new version…half my extensions no longer work. What’s the point? Using Firefox is no longer ‘fun’.

    And, rapid updates is one of the reasons why Chrome is unsupported at work…now Firefox? You’re pretty much pushing companies back to IE. Heck, we’re still on IE8 at work, probably won’t go to IE9 until next year. Whether it’s right or wrong, companies move at a slower pace, because they need to continuously support the internal software that keeps the place going. These rapid changes just mean that Firefox won’t be supported anymore. The extensions we need for day to day work keep breaking every few weeks now. It’s not good.

  5. Logan wrote on August 17th, 2011 at 6:45 am:

    I agree, this new versioning is ridiculous. If they’re just numbers, what’s wrong with “just numbering” them 4.1 and 4.2? Save the whole versions for releases that are actually a big deal.

  6. austin wrote on August 17th, 2011 at 7:05 am:

    i have to agree the version numbering is going too high too fast, and soon you will be at very large numbers that start to get ridiculous (as his “firefox 3569″ alludes to) people can handle small numbers even weird decimals(i say weird because 3.5.26 is not a real decimal but kinda looks like one. its made of a series of small numbers that are easy on the eye)

  7. Luis Elizondo wrote on August 17th, 2011 at 7:47 am:

    This is already ridiculous. This change to the release cycle is one of the stupidest decisions I’ve ever seen in an Open Source Project. What are you trying to achieve Mozilla? Really. You’re breaking extensions every two months or less, you’re making it really hard for developers to keep up to date with your changes, and remember, those developers are working for free, on their free time. Remember the expectation of Firefox 3 and Firefox 4? Millions of downloads in hours, even a Guinness World Record, and now with 5 and 6 you’re just loosing momentum against other browsers, when will you get another ‘Firefox party’ to celebrate the next release of the “Greatest Browser Ever”? When you reach Firefox 1000? Or maybe Firefox 2000? Again, this is stupid. You can still make really fast updates without moving to a major version and making big efforts to not break extensions.

    I will still use Firefox because of Firebug, but the moment you break it with one of your “mayor” versions, I’m done with you. There’s no reason to keep using a browser like Firefox when I have other options. This is not year 2000 when we have only two options.

  8. Jose wrote on August 16th, 2011 at 2:22 pm:

    Thank you for breaking my extensions once again. Whats up with the number jumps????

  9. Luis Elizondo wrote on August 17th, 2011at 7:51 am:

    Ohh, don’t worry, developers will fix them just about a week before they launch Firefox 7 and the history will continue.

  10. Andy M wrote on August 17th, 2011at 6:53 am:

    I don’t mind the new features but why does each new version have to break so many plugins and add-ons?

    It’s damn annoying to lose functionality that works perfectly well, just because a few new features have been added.

  11. raj wrote on August 17th, 2011 at 8:32 am:

    version no’s can be 1 thru 100000. by the time we reach 1000 the product itself will become obsolete. we dont have netscape anymore right. same way. of couse firefox is the new avatar of netscape. so by the time firefox reaches 1000 it will be rechristined firebox LOL

  12. Joe Luhman wrote on August 17th, 2011 at 10:07 am:

    Thank you for breaking my extensions for the second time in as many months. How long is this insanity going to continue? Please stop breaking the extensions for every major release, or please re-think this silly move to a six week ‘major’ release cycle.

I just hope, Mozilla come to senses before the users run out of patience.

What’s keeping me busy

Of course it is CInk. 😛 Ever since I started working on it, my world has now, kind-of wrapped around it. Oh, I am really fatigued now. Phew!

But anyway, why this post? I surely haven’t posted this to rant about myself. It is of course CInk and it is turning out to be quite something. I have been working on it to fill the features gaps between this and ContextFree. The only gaping hole left was that CInk version 0.1 didn’t support ‘paths’ at all. Well this weekend I have implemented that, well almost. Now CInk supports all path operations expect for ARCTO and ARCREL. I plan to implement them next weekend.

Along with Path support, I have improved the z-index handling. In version 0.1 of CInk, you might have noticed that for codes with z-index, the background color is applied at the end of the rendering process. Also if there are any event rules preset, like MOUSEMOVE and MOUSECLICK, then CInk would defer event handling until the main rendering completes. In fact for evented rules z-index was not even supported. I have fixed them now. Now it doesn’t matter if z-index is present or not, it would behave the same, although it could be injurious to yours browser’s health. In particular Firefox seems to struggle in this case.

I am now moving CInk to version 2.0. Why v2.0 and not v1.0? Glad you asked! I have thrown in a totally new capability in CInk which ContextFree or Algorithm Ink doesn’t have. Using texts.

CInk texts support

For texts the following commands have been introduced.

  • fn – Sets font name to use
  • fs – Sets font size. This is additive. So when multiple fs commands are encountered then their values will be added up as we progress. This allows us to create something where the texts will grow larger or smaller.
  • fu – Sets the font unit. This allows us to set the unit to be used with fs. This can be ‘px’, ’em or ‘pt’.
  • base – Sets text baseline. Won’t elaborate this right now but can be found out by Google.
  • align – Again won’t elaborate right now.
  • t – Aah! The prized command. This is the one which allows you to set the text that needs to be shown. This too is additive, so if you specify in a sequence – t A t B t C, then the net output will be the string ABC.
  • bkspc – This does the job of removing the last character, if there is any. So, if we modify the above  example to – t A t B t C bkspc, then the final text will be AB only.
  • e – This is like bkspc but instead of remove the last character it empties out the full text. So, whenever this is used the the final output will always be and empty string.
  • |t – This one is a genius! 🙂 I can’t help myself from putting so many exclamations and smileys. There goes one more. 🙂 This command should be followed by an integer. This value is then added to the last character’s unicode (decimal) value. So when the current string is ABC then a |t 1 will finally generate the string ABCD. This is because on adding 1 to unicode (in this case the ASCII) value of C, we get D. This D then gets clubbed together with the last string. Now this little buddy has one more trick up its sleeve. What do you expect will be the output of this – t ABC e |t 1 ? Well, it won’t be and empty string. It will be D! This because e and bkspc are, what I call, past-influential commands, because they are not supposed to influence the output of the future commands. In this example C‘s ASCII code is passed-on to |t even when it itself perishes. If C had not done that then |t would have been influence by past commands, making it hard to predict the output. So, now even if there is a e or bkspc on the left of |t then this doesn’t influence it.

There are few more goodies which I will throw-in here. You can use unicode characters for t. For characters outside the normal ASCII range you cannot directly write it as a parameter for t, but instead you need to give that character’s (decimal) unicode value in a special format – {uxxx}. Replace xxx with the unicode number. It can have any number of digits.

Now you might be wondering, at what point all these texts are actually printed and how do we control that? Well the answer is ECHO. ECHO is a shape primitive like CIRCLE, TRIANGLE, SQUARE and LINE (this will come in v2.0). So it behaves exactly like them, that is, when invoked do what is meant to do, in this case print text, using the transformation commands it is interested in. ECHO, like others, honours geometric and colour transformation commands, like hue, scale, flip, etc.

So, it’s time for an example.

//Delhi Belly by AppleGrew

startshape stacks
size {s 0.2 z -400 x -.5}

rule stacks {
   delhi {b 1 h 0}
   belly { y -1 b 1 h 200}

rule delhi {
   //Unicode for two Hindi characters.
   //{u2367} is called a "matra", which in
   //itself is not a letter but modifies the
   //sound of the other.
   stack {t "{u2338}{u2367}"}
   stack {t L x 1.5}
   stack {t H x 2.5}
   stack {t I x 3.5}

rule belly {
   stack {t B}
   stack {t E x 1}
   stack {t L x 2}
   stack {t L x 3}
   stack {t Y x 4}

rule stack {
   10* { z 1 x .05 r 1 h 10}
   ECHO {sat 1 r 1}

rule stack {
   10* { z 1 x .05 r -1 h 10}
   ECHO {sat 1 r -1}

rule stack {
   10* { z 1 x .01 r 1 h 10}
   ECHO {sat 1 r 1}

rule stack {
   10* { z 1 x .01 r -1 h 10}
   ECHO {sat 1 r -1}

Note: You need to have Firefox 4+ or Chrome to see the output below. It is not tested on any other browser.

CInk version 0.1 preview


For past few weeks I have been on working on this. This has come out to be quite good. The above video shows rendering being done on latest Google Chrome browser. I have tested my code in Chrome and FireFox 5, and it works with reasonable performance.

About CInk

Sometime back I stumbled upon Aza Raskin’s very inspiring and beautiful Algorithm Ink[sup] 1[/sup]. It’s easy to use and you can create some truly amazing art. From there I learnt that it is a Javascript implementation of Context Free Design Grammar (CFDG), invented by Chris Coyne[sup]2[/sup]. Also, that CFDG contains more language constructs which Algorithm Ink didn’t support, like loops, z-index, etc. Instead it provided a link to C implementation of CFDG – Context Free Art[sup]3[/sup]. When I saw what still more amazing stuffs people have done there, particularly a B/W artwork, “Bleak” [sup]4[/sup], then I decided of re-implementing CFDG in Javascript.

Why Javascript

CInk is not a replacement for its C counterpart – Context Free, but it adds to it. First this allows a way for random nettizens to stumble on it and create something amazing, even if by chance. Second, CInk clearly separates parsing and rendering logics, making it possible to be used to draw your site’s background. Yeah I find that cool. 😉 Third, as a side-effect of the trick Aza used to keep the browser from locking up as the script draws the art, makes for a visual treat. Which the C counterpart cannot, as it is too efficient and fast to render. 😛

Algorithm Ink

CInk can be considered an enhancement of Algorithm Ink, as the rendering logic’s fundamental concepts are from it.  Except for that it is purely a new product. The parser has been created using JSCC[sup]5[/sup] with slightly modified grammar than given in Context Free’s source code.  Output rendered by CInk is now very much like its Context Free. CInk retains support for MOUSEMOVE and MOUSECLICK predefined rules, introduced by Aza. One major difference between CInk and Algorithm Ink is that, unlike Context Free, Algorithm Ink used HSL to RGB color conversion, but CInk uses HSV to RGB conversion. Also CInk code has been made modular and it doesn’t litter the global namespace.

Overall CInk is compatible to Algorithm Ink and Context Free. So, codes for Algorithm Ink will run in CInk and codes for Context Free may need to be scaled down. You can use size {} command for that.


This is just a preview. I haven’t released CInk yet. It will be online when I have created its site. It will be GPL licensed. Currently path commands like LINETO, etc. are not supported, but will be in little future. Though tile{} command is supported but the output will be less than appealing. I am not sure if it is possible to fix this now. For now tile{} will remain broken. Since <canvas> doesn’t support z-indexes, so CInk creates stack of them when rendering a code that refers to z indices. At the end of the rendering all these stacks are merged into the one. This is of course a hack, but can’t help it unless HTML5 specification and browser developers do something about it.

  1. (Algorithm Ink)
  2. (CFDG inventor)
  3. (Context Free Art)
  4. (Bleak Artwork)
  5. (JS Compiler Compiler)