markups, scripts, and interpretations...

work your 'net

so, i did the basic primer on html, or hypertext markup language. definitely doesn't explain everything about it, but it should've gotten you up and on your feet. 'sides, there's about a million tutorials (most of them decent) and reference sites out there. htmlgoodies used to be my favorite. haven't been perusing it lately, so i don't know if old joe burns is still keeping it fresh, but never fear--you won't have a problem finding good help when it comes to html.

now, from this point on (at least in this post), i'm going to assume you are at least sort of familiar with html. you know what a tag is. now, i'm going to take this a step farther.

markup languages, in the scheme of things are interpreted languages. there's a little debate on the matter as to what constitutes a real programming language. interpreted languages are interpreted by another program, and the translation, if you wanna call it that, is what's understood by the computer.

but, really, all programs are interpreted at some level. it's just a question of how, when, and where.

traditional programming languages like c, c++, basic, pascal, fortran, cobol, and all the other languages from the good old days.

java, on the other hand, is an interpreted language. you can run java on any computer that has a java virtual machine installed on it. the big advantage this gives is the ability to write one piece of software and have it run on everyone's computer with no changes.

of course, the downside is that you have to have a java vm (virtual machine) installed, and the vm has to be written for each type of computer that it is to be used on.

the vm is called a virtual machine because it acts like its own computer, but since it's all software (or virtual), there's no actual hardware involved. a virtual computer (machine).

but this is where people don't always see eye to eye. even traditional computer languages had to be interpreted. it's just that it was done by the programmer before the software was released.

a programmer writes a program (called coding) in basically just a plain text file. the file contains all the instructions (known as commands), written in a special way so that while a programmer can read them (most languages have syntax based on english), a special program called a compiler can read them as well. when you run a source code file through a compiler, it translates it into another language which the computer system can understand. we typically call the finished product an application or program, also known as an executable.

so, as you can see, both kinds of programs are interpreted or translated, just at different times. traditional programs are interpreted before the program is distributed, while interpreted languages translate it while the program is running.

the differences are self-evident for the most part. different approaches have different pros and cons.

now, you might be asking yourself what the heck all this has to do with html and networking and why you care. well, somewhere along the way, they came up with scripts and markup languages.

scripts are basically text files, again, and when they're executed, they are processed (or translated, again) into actual computer instructions. the advantage of scripts is that they are very easy to manipulate.

it's easy to open a script file on the fly, from more or less anywhere. now, they tend to not have quite as many features, but they are easy to learn, and easy to change and update.

scripts provide a way to provide more active, interactive, and dynamic functionality than html allows for on it's own. but scripts aren't just for web pages.

scripts can be used for many other purposes, including system tasks. remember batch (.bat) files (for all you DOS oldtimers out there)? scripts. just a text file with a string of commands written in it, and when the system reads, or parses it, each command is executed sequentially.

easy to change. no muss, no fuss, right? well, the major advantage compiled code has over interpreted code is speed. while it's true that they both have to be interpreted at some point, with traditional, compiled programs, all the number translation and interpretation has been taken care of by the time the end user gets ahold of a given piece of software. so, with compiled code, a user's computer reads it more or less directly, but an interpreted program has to get run through the vm every time.

easy to update, and good for distributing to multiple platforms (i.e. windows, osx, *nix, etc.), but it will never be as fast as something already compiled.

clear as mud?

well, the title of this is markups, scripts, and interpretations, so let me take a second to expand on markup languages (if you're still awake, that is).

by now, most of you are pretty familiar with html, or hypertext markup language. what makes html so special (and familiar) is hypertext. links. everybody likes to click on links, no? well, a lot of people forget that the rest of the acronym means something, too.

markup language.

a markup language is something that can be included into content (typically a document), which controls how the document behaves or is displayed. well, the style's caught on.

now, there's something called xml, or extensible markup language. the long and short of xml is that it is extensible or changeable. very modular.

you not only include tags, but you can basically describe what each of those tags are supposed to do, as well, which makes it tremendously more powerful (not to mention, tremendously more complex).

now, i'm not going to go into the breakdown of how xml actually works, as it's far beyond the scope of this post, but just keep your eyes peeled. one can already see many uses of xml popping up. VoiceXML (.vxml) is probably the most notable right now. i'll wager that many of you have already interacted with a voicexml script and not even realised it--you know those annoying interactive voice response computers which answer the phone at most companies, now? many of those are actually run by voicexml scripts (not dissimilar to a web page).

definitely cool, even though it sucks trying to get through to an operator, now.

anyway, maybe later i'll get together some good xml material and resources and work on a tutorial or something. 'til then, here's to big pipelines and open ports.

--theAdmin