[SPOILER ALERT]I’m working on my presentation: “Visual Studio LightSwitch: Under the hood” for community days, and decided to post a little preview of some of the contents… If you are one of the 8 (or more, hopefully a lot more) people that intend to join my session, don’t read on…
After the usual “TOC” and “About the speaker”, I show a very small demo on LightSwitch for those people that tend to sneak into level 400 sessions without knowing the technology (something I do a lot myself :-)). Right after the demo, something along the lines of this follows:
So anyways, if this was the first time you have ever seen LightSwitch, I can imagine you’re thinking:
Man, I wish I had LightSwitch about three years ago… When Silverlight wasn’t dead.
As a LightSwitch addict, it must admit it hurts every time I see or hear this. Silverlight is dead. Stop saying that.
The truth is, Silverlight is not dead at all. Microsoft just rolled out an update (5.1 was rolled out on May 8th 2012), and they commit to support SL5 untill at least 2022 on Mac OS 10.5.7 and Windows 7, or lower. Besides, in my personal experience, when it comes to the technology that’s used to build their products, the business really doesn’t care…
Did anyone buy a word of what I just said? Anyone? Did you? 🙂
So here’s the truth, the whole truth and nothing but the truth… At least, what I, as a non-Microsoft-employee, think I know of the truth…
Screw palliation: Silverlight is dying. I know it’s a harsh thing to say and I tried to deny it myself for quite a long time, but it’s the truth, so you might as well skip right to the fifth stage of grieving: acceptance. In the youth-oriented, fast-paced, ever-changing IT world that we live in today, every new technology will die at a certain point. Silverlight might not be dead *right now*, but since Windows 8 going RTM in less than two months, it sure is dying a lot faster than some other technologies…
Meet Matt Evans. Besides having one of the goofiest (I mean this in a good way) profile pictures out of all Microsoft employees, he’s a member of the LightSwitch team and an enormous help to anyone with a LightSwitch question on the MSDN forums. One of his recent replies on those forums, was this:
The first line: “The LightSwitch team here at Microsoft is hiring people”, makes me question two things:
1) The LightSwitch team is hiring? What the h*ck am I still doing here in Belgium??!?
And, more realistically:
2) Why are they hiring? LightSwitch uses Silverlight as a client, and Silverlight is dead. Why on earth would you be expanding the team? (Let’s pretend you haven’t read Matt’s second and third line in that post) I’ll tell you why! Because they’ve got an ace up their sleeves. And I personally might not know 100% sure what suit that Ace is, but I know for a fact that they don’t just have an ace up their sleeves… They got pocket rockets and the flop’s about to serve them four-of-a-kind!
I’ll let you in on a little secret…
Back in the days, when I started programming, we used something called punch cards that basically contained machine level instructions. This is of course a flagrant lie, I’m 27 and probably wasn’t born when some of you punched holes in paper as a living…
As technology evolved, and magnetic storage and more powerful computers became available, the world got rid of machine language (1st generation language) and moved on to a higher level of abstraction: writing assembler (2-GL).
That might have been fun for a while, but to avoid unnecessary repetition, macros were added and pretty soon the world discovered an even higher language of abstraction: 3GL languages such as COBOL, FORTRAN and LISP. Random side-note: notice how all these 3-GL languages seem to have names in ALL-CAPS. Ooooh, metro-ish!
Note that from 1-GL to 2-GL, and again from 2-GL to 3-GL, a important “compatibility” shift happen. Instead of writing instructions that are tightly-coupled to the processor that will execute them, the 3-GL world is now at a level where they can write in a programming language, and then compile that into machine-dependent instructions.
Fast-forward to today’s situation, both the languages and the compilation process there-of, have taken on considerably higher forms of abstractions. Object Oriented Programming languages like Java, C# and VB.Net, are a higher level of abstraction over procedural programming, and compile in an intermediate language, which is then (JIT-)compiled by a VM to OS specific instructions, who in turn translates these to machine instructions.
Really moving forward, as history proved, means moving towards higher level of abstractions…
I say this of course in an attempt to make you wonder about what the next level of abstraction is that we can make over Object Oriented code… Well, the next level of abstraction, X-GL (the value of X kind of depends on who’s counting, meaning I really don’t know) is this:
Quick: out of the programming languages you know, randomly pick either your first, your latest, or your favorite.
Now, in that language, imagine you’re giving this UML-like requirement and you’d have to implement it, ie. write the OOP code. Can you do it?
Of course you can, and the fact that you can is simply amazing! Not so much that YOU can, in particular, but the fact that based on the same UML-like input, we were able to write (well: imagine writing) implementations in probably half a dozen programming languages.
Let’s do the same exercise again: here’s the requirements to a query, imagine writing it.
Some of you envisioned Entity Framework, some were thinking of LINQ, others had an SQL query in mind. Based one one input, we can come up with several actual implementations.
See where I’m going to? Ok one last time, create this screen, mentally, in the technology that you used last before coming to this session:
Were any of you creating this screen in WPF? Silverlight? HTML5? Swing? A free WebFormsBuilder tool? WinForms? (If you raise your hand when I say “WinForms” by the way, I do feel for you…)
The point is: based on the same input, you can write all kinds of working applications, varying on (the experience of the developer, and) the requirements of the customer.
And I don’t want to offend anyone’s intelligence here, but if this input is provided in a standard format, a smart compiler could do that too. Perhaps even better, most definitely even faster. And if the requirements change to the point where you need to rewrite your application in a different technology, simply take the same input and hand it over to a better compiler…
Pocket Aces, I told you!
This idea is called Metadata driven development, and it isn’t new at all.
In fact, there’s a book called “The pragmatic programmer” (a book I feel everyone should read), which was first printed in 1999, where the DRY-principle was tossed for the very first time…
Although almost everyone will claim to know what “Don’t Repeat Yourself” stands for, I found that a lot of people think it simply means one shouldn’t copy&paste code. It doesn’t, in fact it describes how every piece of knowledge in a system should have one and only one, unambiguous, authorized source of truth. Andrew and David describe metadata, and code-generation or interpretation techniques, to accomplish pure “DRY” implementations.
Implementing this DRY principle, the LightSwitch IDE might seem “simple” at first sight, and thus “likely to be inferior” to what you have been doing as a professional developer over the last couple of years. It is easier to dismiss it as a tool for non-developers, than to admit it is actually a higher level of abstraction over the OO code you might have been writing so far.
Each designer in the LightSwitch IDE is in fact a graphical layer over metadata, which is stored in several LSML (“Lightweight & sexy metadata language”) (“LightSwitch Markup Language” actually) files. This, is the input.
Given enough time and resources, the output, can be whatever you want it to be.
No wonder they are hiring…
Silverlight is dead. But that was just one way to interpret LSML. That was just the Ace-ten suited that LightSwitch v1.0 opened with. Pretty soon the flop will be dealt. My money, is on the team with the pocket aces up their sleeve…
Silverlight is dead. Long live LightSwitch!
And then of course I pop open the hood, as we dive deeper in the metadata driven client, where the metadata is interpret at run time, and in other different engine parts… What do you think? Good? Bad? Barely staying awake or eye-opening?