Archive for April, 2008
This is a 2007 talk about the upcoming changes in the JavaScript language or more accurately EcmaScript. Some of you may know that what we call JavaScript today is version 3 of the EcmaScript specification, which was finalized in December 1999. So it’s been with us for over 8 years without changes. EcmaScript (aka JavaScript) went through three revisions between 1997 and 1999 (one revision per year), and after that it stopped.
The web has changed quite a bit in those 8 years. In 1999 people used JavaScript for rollovers, form validation and cute effects. Today we live in a “Web 2.0″ world that is moving towards rich web applications like Google Maps, web-based office software, etc. In brief, the upcoming changes in EcmaScript 4 are intended to make JavaScript more suitable for more complex web applications.
Without further ado, here is the video:
An answering machine message for those who hate getting calls from telemarketers:
Here is a very interesting talk from Douglas Crockford on software quality, and in particular, why all software seems to be buggy, over-budget and late. He suggests reasons why this appears to be an endemic property of all software.
In addition to what Crockford says, I’ll add that software programming is fundamentally unpredictable. Either you are doing something you’ve never done before, or you are trying to figure out why something won’t work. There is very little about programming that is routine and predictable.
Note: Discussion continues below.
Literate Programming
Crockford talks about Literate Programming which is a very interesting idea which just hasn’t received any traction. The basic idea is:
- The documentation and the specification are embedded in the code.
- The program is designed to be read by a human.
And I’m not talking about code comments and JavaDoc, which merely documents the functions and classes in the program. I mean literal prose like “The purpose of this program is to provide a service for teachers to keep track of student marks (grades) as they try to complete their project”.
Literate programming is difficult, especially on a larger team, and there really aren’t many tools available to do it. But since I am a sole programmer I can make the rules, and I decided to try it out as an experiment. My most recent project is a markbook for teachers to keep track of marks (grades) associated with Ingot Certificates.
The experiment
The first step was to choose a documentation tool since that’s the cornerstone of Literate Programming. Long story short, I chose Natural Docs. I wanted something more “standard” like oXygen or JavaDoc, but no other tool has nearly enough flexibility for what Literate Programming requires. With reason, these tools are designed to write APIs, not software specifications.
Natural Docs is a surprisingly flexible system, almost wiki-like, where you can write a lot of interesting high-level documentation, with headings, sub-headings, lists, character formatting, embedded source code, etc. I do wish it had tables, embed HTML and other features. So it is not at the level I’d like for true Literate Programming, but it’s pretty good. In addition, the ND syntax is very natural looking, so the program source code itself is still easy to read.
How did the experiment turn out? Quite well actually. Approaching the project in this way really helped me think about the problem in ways that I would not have otherwise. Often I found myself struggling to explain why something was designed in a certain way, and I realized that this meant that the design was not as logical as it seemed at first. Then I would come up with a more logical design and end up with a much better product as a result. The experience was interesting, often frustrating, but also rewarding. Would I do it again in my next large project? Definitely.
/*
GNOT General Public License!
(c) 1995-2007 Microsoft Corporation
*/
#include "dos.h"
#include "win95.h"
#include "win98.h"
#include "sco_unix.h"
class WindowsVista extends WindowsXP implements Nothing
{}
int totalNewFeatures = 3;
int totalWorkingNewFeatures = 0;
float numberOfBugs = 345889E+08;
boolean readyForRelease = false;
void main {
while (!CRASHED) {
if (first_time_install) {
if ((RAM < 2GB) || (processorSpeed < 4GHz)) {
PopUp("Hardware incompatibility error.");
GetKeyPress();
BSOD();
}
}
Make10GBswapFile();
SearchAndDestroy(FIREFOX);
SearchAndDestroy(OPENOFFICE_ORG);
SearchAndDestroy(ANYTHING_GOOGLE);
AddRandomDriver();
PopUp("Driver incompatibility error.");
GetKeyPress();
BSOD();
}
//printf("Welcome to Windows 2000");
//printf("Welcome to Windows XP");
printf("Welcome to Windows Vista");
if (still_not_crashed) {
CheckUserLicense();
DoubleCheckUserLicense();
TripleCheckUserLicense();
RelayUserDetailsToRedmond();
DisplayFancyGraphics();
FlickerLED(hard_drive);
RunWindowsXP();
return LotsMoreMoney;
}
}
Another interesting talk from Douglas Crockford. I’m not sure when this video was taken. He proposes using a subset of JavaScript that eliminates most of the potentially problematic aspects of the languages. He argues that if you remove just a few things (ie. choose not to use certain features) you are left with a pretty solid language.
Those of you familiar with JS Lint may know that this tool incorporates Crockford’s ideas for a JavaScript subset. Personally I follow what JS Lint commands in all my programs. I don’t agree with 100% of Crockford’s subset ideas, but I agree with 95% of them. (On a side note: JS Lint is very cool in that it is a full JavaScript complier written in JavaScript).
Much of the talk is simply a historical comentary on JavaScript, but I actually found that very interesting too.
Why you should make sure that you and your wife have the same retirement goals.
A really interesting talk from Guy Steele (expert in computer language design) about how computer languages should evolve. Although he is thinking about Java, what he says is entirely applicable to JavaScript.
This is a topical subject, as a new version of JavaScript is being finalized right now, in Ecma. Are the changes good? Or are we just wrecking a perfectly good language? The new JavaScript will be a much bigger language, yet Guy makes a strong argument that we should not evolve languages by adding a ton of features, but by making them easier to extend by individuals.
The talk is very interesting and most of it is not too technical. It is accessible to someone with less programming experience (you may not get the part between “number” and “computer” but don’t be intimidated by that). The talk is 53min long.
I had trouble embedding this video. If it doesn’t work, go this page
