Why developers need to grow up
I am tired of hearing the same old argument that "my language is better than yours", the statement is as meaningless as it is childish, it reminds me of the school yard arguments "my dads better than yours" and is so childish it annoys me.Why is the argument pointless
Languages are better than others, depending on the context within which they're being compared. This premise comes right back to the age old problem that there really is no silver bullet, ever, for anything. No single language does everything better than any other and this is a fact, let's look more closely at what exactly I mean. For a language to be good it must be able to do the task you want it to do, in a manner that's expressive and simple to understand, after all code spends more time being read than written. There are other constraints that may apply to the context within which we compare languages for example we may be dealing with limited resources.Whilst C# is very expressive and nice it does need to run within some form of VM so using it for something that's destined for machines other than Windows is not a good idea, I am not saying you can't use mono to run it on Linux but mono isn't as up to date as the Microsoft CLR by virtue of the way it is developed it can't be. Similarly any JVM language will of course need a VM, so you can run it on any system that has a vm but, and this may come as a shock, not all systems actually have a JVM on them. I find Haskell my favourite language but sadly there's little call for it in an enterprise java setting and besides it's expressive to me but not to the other X number of devs that I work with so once again what's best for me isn't best for them or indeed the business. Now consider C++ it has its shortcomings, much of which I have to say have been addressed with C++11 which impressed me, but compare the size of a Hello, World! app compiled from C++ to a version made using raw assembly (or is it assembler I never can remember) code, or even C code for that matter if you presumably use the cout or printf then you'll need to import some libraries e.t.c. whereas the assembly code one loads some registers and makes a system call (ah the days of interrupt requests in DOS, them's were the days :) )
My point is that all languages are good and all languages are bad, just put them in the right or wrong context respectively. One colleague put it nicely "when the only tool you have is a hammer, every problem looks like a nail" which sums it up nicely we have an expansive toolbox so we need to chose the right tool for the job.
So What has this got to do with Protocol
Imagine you have a system that needs to have rapid changes made to the UX, we've all been there, so this part of the system is written in a nice language for representing user flow and gui's, whatever that language may be. However it makes no sense to use the same language to describe the business logic that governs the process that our given company does, so this bit is written in a language, or languages, that best suit that. Now consider the very low level thing that the business is communicating with, for example a driver to a specific piece of hardware, the driver software is rarely altered but does have to be stored on something with less storage space than a gnats armpit so we're really talking squeezing the most out of the small number of bytes but not caring too much about the readability of it.All of these systems exist within a single company, each system is made to a very high standard and they all perform their tasks marvellously.
Now here's the protocol bit, they must all talk to each other in a way that makes sense to the systems doing the communicating so for example the limited driver bit will get a streamlined set of data only the essentials of what it needs, whereas the UX bit can happily send all the information it's gathered at the business logic which is free to ignore any bits it doesn't need for that operation.
