|Written by Ian Elliot
|Thursday, 10 December 2020
You may think that Scala is an elegant language, you may even yearn for the days of Lisp or Fortran but they are all, both the new and the old, dead meat.
I can't be sure and neither can you but it seems that in the case of the web the tail is still wagging the dog.
What color would you like your web app?
Despite the fact that the revolution of Web 2 was about dynamic web applications and databased websites, what are we concentrating on? Semantic markup and making things look pretty using CSS. All of the headline news is about how HTML5 is going to bring about the new revolution amounts to prettier typography and multi-column layouts. For some reason the revolution seems to be hung up on what things look like not on how they behave. Even semantic markup leaves everything to be desired in that you might well use it but we have little idea what to do with it next.
All good but... where is the "big push" for programming language support?
Why is it we can focus on what color the web app is but never ask how best to code it or what is needed to get the more difficult job done.
Where we are
Now we have ECMAScript 5, which is at long last working its way into browsers that people actually use. This said, the changes to create ECMAScript 5 are welcome but small and we will probably be writing ECMAScript 3 for some time to come as we wait for older browsers to die away.
Server Side and client side
You might ask why hasn't this already happened?
A language that we have lived with for 15 years is suddenly emerging from its scripting days.
What is really interesting is that if you look at many of the so called HTML5 based web apps you can see that they could have been written using HTML4 and a bit of lateral thinking.
The answer is, of course, JSON.
Notice that this not an argument that JSON is better than XML just that it is making in roads not only into what we use but the way we think.
One language to rule them all
Well the simple answer is programmers like to use one language.
Language swapping needs a good reason and not just the unintelligent one of "the language isn't available".
When you think how hard it is to work with two-tier applications that demand that you move your attention from client to server and back again then you can also see that it makes no sense to make this round trip harder by a language swap on the way!
Put simply - no matter how clever we think we are and no matter what our language loyalties are, working in a single language is usually easier than working in multiple languages unless there is a very, very, very good reason.
How should you feel about this?
You can argue that this has already started to happen - but also you can argue not fast enough.
What we really need is language flexibility.
In this day and age I should be able to pick the language for the job and just use it on the client side or the server side, in or out of the browser. The logical way to have done this is to include a byte code interpreter or some other design of virtual machine able to run any language within the browser.
The situation is not a happy one. As the masses treat HTML5 with love and affection we need to realise that
|Last Updated ( Thursday, 10 December 2020 )