If you are a web developer, you will be very familiar with this problem: browsers and web servers cache stuff to help speed up response. The idea is great when things don't change much, but it ain't rosy when pages, scripts, code, and content are changing constantly and quickly.
Most browsers offer a "refresh" button that's supposed to get the latest content. Don't be surprised if it's not always the case. I think I relied too much on that feature and it screwed me over, causing me to hack my own code before I realized it could be the browser's fault (and rightly so). I've seen instances where refresh can load an old (cached) script even when a newer version exists. Reducing cache size to mere MB helped - my first clue. Usually when I suspect this kind of issue, i switch to another browser (IE does cache better) and see if things look the same.
Web servers also cache stuff. The most dangerous are what they save when shutting down so that they can restore when they are back online. I've seen instances where old stuff was used instead of newly deployed code. Tomcat is notorious for this. I disabled this kind of caching a while back (don't recall how I did it, but suddenly it was gone as I tweaked around).
Compilers are the third and final source of caching issues. Most advanced IDEs have a "clean project" feature that helps. In a nutshell, if your files didn't change, some compilers won't recompile them when you build the project - even when dependencies may have changed. The result is a product with mixed code, old and new together. The surest sign of this is new features with old data - what I call "history playback".
Saturday, February 23, 2008
Saturday, February 09, 2008
Liquid Templating Language ... Say What?
I pride myself in being a diligent programmer with enough experience to be able to use any programming language under the sun, until I came across a small scripting language called Liquid. It's a server-side language - an offshoot Shopify/VBScript - that is used in some web applications to generate dynamic content in reporting views. It is touted as a simple language that anyone can use with ease.
I don't really agree with all the hype about it. In terms of flexibility and robustness, this language doesn't even come close to what modern scripting languages (both client-side and server-side) offer. To start with, it is poorly documented - an attempt to find full documentation and usage samples leads to Google Code and SVN preview to check out code if you want. It doesn't seem like people use it much.
Having a small set of constructs might make it easy to learn and use, but it severely limits what else it can do. Consider the simple idea of named variables: it doesn't have it! By extension, there's no concept of code reuse, regular expressions, and arrays/hashes - components that are useful for processing text repeatedly. In working with this language, part of me wanted to implement a Javascript engine that'd reprocess at the client whatever content Liquid produced so that it meets even the simplest requirements such as treating data with certain keywords specially.
The bottomline is this: if search engines know nothing about a language you choose to use in your application, chances are that you will be one of a dying generation of that language's users, or it is proprietary. Programming languages thrive on a huge user base in addition to a rich feature set - Liquid really has none of these. A time will come when applications written in obscure languages like this will need to be shredded in favor of simpler, fully-featured, modern languages. Consider Pascal and Cobol - they are still in use today because of the huge code base from ages ago, but there's a rapid move from them to C/C++ because of progress in programming languages. Companies that don't keep up will be stuck with antiquated and inefficient code - a long term cost. Especially for web applications where change is more rapid, I don't see this language surviving more than 7 years really. As more people find out about it, the more disadvantages out it they will see, and the less it will seem appealing for use in web projects.
I don't really agree with all the hype about it. In terms of flexibility and robustness, this language doesn't even come close to what modern scripting languages (both client-side and server-side) offer. To start with, it is poorly documented - an attempt to find full documentation and usage samples leads to Google Code and SVN preview to check out code if you want. It doesn't seem like people use it much.
Having a small set of constructs might make it easy to learn and use, but it severely limits what else it can do. Consider the simple idea of named variables: it doesn't have it! By extension, there's no concept of code reuse, regular expressions, and arrays/hashes - components that are useful for processing text repeatedly. In working with this language, part of me wanted to implement a Javascript engine that'd reprocess at the client whatever content Liquid produced so that it meets even the simplest requirements such as treating data with certain keywords specially.
The bottomline is this: if search engines know nothing about a language you choose to use in your application, chances are that you will be one of a dying generation of that language's users, or it is proprietary. Programming languages thrive on a huge user base in addition to a rich feature set - Liquid really has none of these. A time will come when applications written in obscure languages like this will need to be shredded in favor of simpler, fully-featured, modern languages. Consider Pascal and Cobol - they are still in use today because of the huge code base from ages ago, but there's a rapid move from them to C/C++ because of progress in programming languages. Companies that don't keep up will be stuck with antiquated and inefficient code - a long term cost. Especially for web applications where change is more rapid, I don't see this language surviving more than 7 years really. As more people find out about it, the more disadvantages out it they will see, and the less it will seem appealing for use in web projects.
Subscribe to:
Posts (Atom)