Fighting Eleven #20: Choices
About two weeks ago, I decided I had to make a decision about the programming language I was using.Like all languages, VB.NET does some things very, very well, particularly when used in a WPF application.
Other things, though, it does very poorly, often in an infuriating way.
Plus, it won't compile to a mobile platform (unless you count Windows Phones, which seem to be dead).
I decided that the easiest move would be to C#. It's supported in Unity, I thought it was relatively close to the scripting language in GameMaker (wrong, as it turned out), and it's easy to port C# to iOS. I wasn't sure about how well the XAML would export, but it felt like a step in the right direction.
So I started reading. And I had progressed to the point where I was going to start taking the existing code I had and convert it to C#.
However, I decided to email Garret first, because Garret is one of the smartest people I know, and even better, he explains things in an incredibly clear way.
His answer to my e-mail was so good that I'm quoting it below:
I'm afraid I must disabuse you of the notion that C# will give you the portability you are hoping for.
You are correct that .NET will only give you the tools to develop on the Windows Mobile platform, but I would strongly recommend that if there is a direction you want to go, you find a scripting platform or tool that will allow you to cross-compile between platforms and make the jump (or graphics platform or whatever) instead of spending time struggling to work in C#. And I will explain why I believe this below.
The idea of there being a "C-family" of languages is... misguided. A reasonable comparison would be an archivist comparing a coffee stained Playboy magazine with the Magna Carta and concluding they are similar because they are both yellow.
Maybe a bit extreme, but you get the point.
VB.NET has more in common with Java than C# has in common with C++.
The C-family appears to be a thing because what you are seeing is 50 years worth of developers being influenced by a revolutionary new programming language called "C" (which is based off a language called "B") that dates back to the moon landing. These developers were inspired by the ideas of a high-level language that abstracted away machine code, could be compiled and run on different chipsets without being modified, and decided "I can do it even better".
Some people took more extreme paths than others - a subset of them decided to build their own languages, but since they were familiar with "C" and (often) were building their compilers IN "C", they decided to make their language look like C.
You know how evolution works - we didn't evolve from monkeys, but Monkeys and Humans did have a common ancestor. Well, Perl and Java are the Pit Viper and 3-toed Sloth that just happen to share a common ancestor, a soft-shelled slug, called "C". As a result you can identify some characteristics in common that they share (they have eyes!) but that is where the similarity ends.
The "C" family is defined by a few commonalities (as I see it)
1) The use of braces "{" and "}" to denote the start and end of a block.
2) The existence of certain named control blocks: "if..else, switch..case, for, while" of which ALL can actually be accomplished solely through the use of a "while" statement if you are being truly masochistic.
3) The use of a dot "." to denote accessing a component property of a structure
4) Use a ";" to separate instructions (traditionally used at the end of a line).
That's about it.
Fascinating - I know.
But what it comes down to, is that I could write a summary that would outline the syntax changes that would result in VB.NET being classified as a "C-family" language, and it would take me fewer characters than I've already typed in this email to do it.
Lets try!
1) Braces: replace all blocks that begin with a keyword [complete list: class, do..loop, if..else, for each, for, function, select..case, structure, sub, try..catch, while] and end with another [end* or loop] by adding a "{" after the initial keyword command (ie "for i = 1 to 10 {") and replace the end keyword(s) with a "}"
2) No change (all VB keywords and control structures are modelled after "C-family" languages)
3) No change (VB uses the "." accessor)
4) Add a ";" after each declarative line, command, or instruction that is not the beginning or end of a block "{" or "}"
Done!
VB.NET is now in the C family!
The point of this is that the differences between "C" and "C++" and Perl, and PHP, and AWK, and Squirrel, and NYM and Noop... are enormous compared to the differences between VB.NET and C#.
The problem is that every language behaves differently under the hood, they do different things, they have different libraries, they have unique features, unique strengths, unique conventions, unique operators, unique platforms. That although they have some vague similarity in appearance, that is all they possess.
C is a structured procedural language that shares many commonalities with Assembly (in fact, you can execute Assembly instructions within C if you'd like) while Java is a virtualized byte-code object-oriented language that just happens to appear kind-of like C.
For you to take advantage of any new mobile application platform scripting language, it is far more important that you understand the concepts that underlie Object-Oriented systems and how to structure, organize, and implement code effectively - which is something shared by all modern platforms (and co-incidentally, doesn't exist in C), and then how to do what you want to do in your destination platform of choice (understanding the libraries, idiosyncrasies, and structures of your target language) than it is to understand C-style.
When you get right down to it - once you understand how to program, the syntax rules become trivial.
I often reflect on how incredibly lucky I am to have people like Garret advising me on all different kinds of things, not just programming.
It makes me less stupid, and that's always a good thing.
<< Home