A small wave has hit the developer community this weekend about a clash between two lead developers: Chris Wilson of Microsoft's IE team and and Brendan Eich of the Mozilla foundation. The dispute is about the acceptance of ECMAScript 4; the proposed successor of Javascript. Wilson wrote public doubts about this standard, which let Eich to write a public letter in which Microsoft is being blamed for being reluctant and passive in the development of ECMA4. The debate is interesting, but we have to keep in mind that these are two individuals fighting over this dispute; there are no official positions here. However, I want to leave this aside (I know too little about the dispute as well to make sound arguments), and focus on how I perceive the future of client-side scripting.

As a programmer, I have always been a little bit relucant in learning Javascript. I get the same feeling when I work with Visual Basic. There is something... uneasy about it. The last couple of years I have mainly been programming in modern OO languages such as C++, Java and C#. A procedural language such as Javascript forces me to make such a leap in my approach and thinking that I feel being held back by the language. But I have the same with C. So, clearly it is not the fault of Javascript. In fact, I think Javascript is a good language in that it is easy to read because of a nice syntax, it has good scripting properties such as dynamic typing and it offers a lot of expression.

The question raises.. why is there the need for a 'new' javascript? The main force behind it, is to make the language more 'professional'. Make it more object-oriented, advanced exception handling, templates, etc. Indeed, these are things that are very important for any application of reasonable size. But is it important for Javascript? I have never used Javascript outside the webbrowser. In fact, I think most of the Javascript I use is either developed by a 3rd party or generated on-the-fly. Ajax? I use convenient libraries that abstract me away from the low-level javascript.

An article bij Joel Spolsky on the newSDK made me think about the role of Javascript nowadays. It is a great thing that almost all browsers support Javascript. Could you imagine all browsers supporting a language like, say, C++? Most C++ compilers don't even support the langague the full 100%. I am sure that the software engineers at Mozilla do not want to spend their time supporting a huge and complex language like that. The reason Javascript is so widely supported and popular is for the same reason the C language is still widespread today. It is the biggest denominator across languages, OS-es and browsers. If you write something in Javascript, there is a very good change it will be supported by the platform a client uses. The same is true for the C language, it is extremely powerfull because of the universal support. Even if the C language in itself can be considered obsolete by modern standards.

I believe that we should keep an easy, intuitive, flexible and powerfull language that can be executed for all browsers on all platforms, including new technologies such as PDA's and small mobile browsers. If you want higher-level constructs, you can use high-lever languages and 'compile' them down to javascript. For example, I could specify application logic in C#, which would then be outputted as Javascript in the final output. We can see the same in many smaller domain specific languages which transform a higher-level program into a c-program, which can then be compiled almost everywhere.

I do not believe that adding higher-level constructs into a language such as Javascript will make developers leave their current language and switch to Javascript. Surely, it would be more convenient if you were actually creating client-side javascript by hand. But in my experience, that doesn't happen a lot. But it would make it much harder for current browsers and future browsers to provide a (correct) implementation. You do not want a browser to implement a virtual machine just to be able to run an advanced javascript.

Sommige mensen vinden het een beetje vreemd dat ik een persoonlijke domeinnaam heb geregistreerd. En vervolgens: je wilt toch niet dat iedereen alles over je weet?! Mijn reactie daarop is vrij eenvoudig: die informatie is er toch al. Ik wil het gewoon graag onder controle houden. Iemand die echt anderen wil uitpluizen kan via een aantal simpele zoekacties al een heel eind komen. Alles wat ik niet te verbergen heb, hoef ik ook niet te verbergen, dus ik kan het net zo goed overzichtelijk bij elkaar houden.

Wat heb ik dan wel te verbergen? Enkele voorbeelden:

• Ik ben vrij voorzichtig met het online gooien van persoonlijke foto's, zeker als er ook anderen opstaan.
• Ik ben voorzichtig met het plaatsen van (informele) sterk politieke uitspraken
• Informatie als wachtwoorden, geldzaken, bepaalde telefoon nummers, etc.
• Informatie die sterk vooroordeel inspirerend is

Waarom ik voorzichtig ben met dit soort dingen? Denk even met me mee: wanneer er persoonlijke informatie van jou op het internet komt dan heeft die informatie enkele unieke eigenschappen die je niet terugvindt in 'offline' informatie:

• Het blijft voor een lange, zeer lange, tijd online.. en het raakt snel buiten je controle. Denk hierbij aan google cache, mensen die files offline opslaan, verspreiden via p2p netwerken, etc.
• Het is verschrikkelijk eenvoudig deze informatie op te zoeken, te indexeren en te koppelen.
• De informatie die je nu online zet kan straks, in een geheel andere context, volledig misplaatst zijn. Bedenk bijvoorbeeld of je foto's van je wilde feesten nu, nog steeds gewenst is als je straks als ambassadeur aan de slag wilt. Of als je in een vlaag van jeugdige opleving je begeeft binnen extreem-linkse, of extreem-rechtse kringen, in hoeverre beinvloedt dat je carriere later, ook al kan je gedachtengoed geheel veranderd zijn.
• Veel online informatie is geheel contextloos. Dit werkt veel vooroordelen in de hand. Hoeveel mensen zullen al niet afgewezen zijn voor banen omdat werkgevers snel op Hyves iets zagen dat hun niet beviel. Het probleem hierbij is niet dat je niet jezelf moet zijn, het probleem is dat je geen kans krijgt om iets uit te leggen. Op basis van halve informatie, zonder context, wordt er over jou beslists en buiten je macht om.

Een vriend tipte me over een (nederlandse) zoekmachine, wieowie.nl. Hier kan je allerlei online informatie van personen vinden. Omdat ik een vrij unieke naam heb, is de gevonden informatie over mezelf zeer relevant. Al kan ik nu al zeggen dat het telefoonnummer niet meer werkt.. De site veroorzaakt blijkbaar wat ophef aangezien mensen zich opeens aangetast voelen in hun privacy. Feit blijft dat deze zoekmachine niks illegaals doet, het maakt het enkel makkelijker om relevante gegevens op te zoeken. Wellicht zet het meer mensen aan het nadenken over hun digitale identiteit en de belangrijke impact van alle online informatie. Ik vind dat de wetten wat betreft privacy wetgeving nog steeds onvoldoende zijn. Als software developer mag ik vrijwel alles doen met persoonsgegevens (analyseren, koppelen, verkopen) zonder dat iets of iemand mij hierbij op de vingers tikt. Ik hoop, en verwacht, dat hier de komende jaren verandering in gaat komen. Je wilt toch niet dat straks ook je medische gegevens via wieopwie.nl te vinden zijn?

Zoekmachine voor personen - Wieowie.nl

I recently wrote an article about the concept and implementation of something which I call Role-Based Security in a Hierarchical Environment . It is a form of RBAC (Role-based access control). However, it also takes in account a context object (on which item is my function performing). And role permissions cascade down the context-tree. So having a permission on a certain context object means you also have permission for all underlying context objects (or not, depending on the role parameters). A typical use of this kind of security framework is in a traditional filesystem like NTFS.

In the article I outline the basic concepts behind it and an implementation in SQL Server 2005. The basis for this article is an implementation done in a recent production-ready webapplication. And it turned out to be a very effective way to deal with both partition issues, such as multiple clients in a single database. And security issues: making sure the users do not perform actions they are not allowed to do.

My intention is to write more articles like these in the future, thereby giving a little bit back to the development community of which I have taken so much already.

Links:

PDF article

Article on CodeProject