From AS3 to C#, Part 23: Conclusion
Today’s article wraps up the series with some closing thoughts comparing and contrasting AS3
C# was introduced in 2000 and was initially very similar and likely heavily inspired by Java. Java in turn was heavily inspired by C++ which in turn was inspired by C which was released in 1972. Even C was inspired by B and that was by no means the very beginning. What I’m trying to say is that no language is unique and they almost always borrow a huge amount from each other.
AS3 is no exception to this. Obviously it is heavily inspired by AS2 which was inspired by JavaScript/ECMAScript which were indirectly inspired by C++ and C. Since AS3 appeared in 2006, it’s only natural that it would take some inspiration from C#.
Is it therefore strange to switch from a “newer” language to an “older” one? Not at all. None of these languages ever eliminate their predecessors—except perhaps B—but instead provide yet-another tool in a programmer’s toolbox. There are plenty of situations where C# is clearly a better choice than AS3 and plenty of situations where AS3 is clearly the better choice. As has been stated many times, it’s about choosing the right tool for the job.
So this article and this series aren’t going to claim that C# is better than AS3 or visa versa. Specific situations and personal tastes make such claims nearly impossible to support. There is no “war” between the two languages or, in most cases, even their related software ecosystems. In areas where they have some overlap—e.g. Silverlight and Flash, Xamarin and AIR—it’s more like a healthy competition that provides us developers with more choices. More choices, as usual, yields happier, more productive developers and better products.
With that in mind, let’s talk in broad strokes about the differences and similarities between the languages. The details can be found in the first 22 parts of this series if you’d like the verbose version.
In general, AS3 allows for a somewhat looser programming style. You can skip compile-time checks in a variety of places including plain
Object instances and their field accesses, using untyped (
*) variables, simplifying all functions to
Function, dynamic classes, arrays of untyped elements, and the index (
[]) operator. It also eschews generic/template programming with the exception of some trickery with
Vector.<T>.
AS3 also keeps things simple by omitting various features like extension methods, enumerations, structures, “unsafe” code, lambdas, some basic types (e.g.
byte,
float), iterators, finalizers and destructors, the preprocessor, multi-threading, nullable types, operator overloading, and parameter modifiers like
out and
ref. Overall, AS3 is by far the smaller language.
Together, these make AS3 the much easier language to learn. There’s less of it to learn and in a lot of places it’s compiler is looser. Given Flash’s historical attempts at appealing to artists-turned-programmers, this is a great virtue!
On the other hand, C# is much more of an expert’s language. Yes, you can quickly become productive because a lot of the basics are easy to learn and similar to other languages, but the details take much longer to master simply because there are so many more features for you to get to know.
Despite these differences, the two languages have a lot in common. AS3 using C# as an inspiration and both of them using Java, C++, and C as inspiration virtually ensures that. Both have a C-style syntax with curly braces and semicolons everywhere. Both are object oriented and have direct support for classes and interfaces. Both have static and instance functions and variables, packages/namespaces, constructors, a garbage collector, var args, access specifiers, getters and setters, built-in strings, standard loops (
for,
while, …), a root
Object class, exceptions, and many more similarities. Newcomers to C# from AS3 or AS3 from C# should be able to get by in short order.
Neither language is as hardcore as C or assembler and neither is as high and loose as JavaScript or Lua. Both occupy a conceptual middle-ground where the programmer has some control over the lower levels like memory management and some convenience to not be burned by details like the manual releasing of memory. Still, C# on the whole offers more control over the lower levels and therefore appeals more to those interested in fine-grain control to optimize for memory usage or performance. AS3 is less suited to such tasks and instead usually takes the approach that the Flash Player or AIR should handle anything requiring low-level optimization.
As somebody programming for Flash Player or AIR, your main options are AS3 and Haxe. There are semi-supported alternatives like CrossBridge that allow for C++ and scripting languages built on it such as Lua to run. That said, AS3 and Haxe are quite suitable for many applications. Everything from simple banner ads to virtual worlds can be reasonably built.
As somebody programming for Unity3D or Xamarin or another .NET- or Mono-based environment, C# should be suitable to a very wide range of tasks. Unity3D, for example, provides escape hatches for areas where it isn’t suited. In environments that support it, you can call into C/C++/assembler code for ultimate control. Or you can use another .NET-based language such as F# or IronPython. The language continues to grow and be updated by Microsoft and standards organizations like ECMA and ISO. The platform continues to grow through Mono, Xamarin, .NET, and Unity3D.
For the purposes of this blog, C# should be a great tool for using Unity3D. UnityScript (a.k.a. “JavaScript”, which it actually isn’t) and Boo are officially supported too, but C# will be the main tool. Many games and non-games have been successfully built and launched over the years with C# and many more are being built all the time. It’ll allow us to target HTML5 and WebGL with Unity 5 and keep targeting mobile, game consoles, and desktops.
Moving forward we’ll start to discuss more Unity3D-specific topics starting next week. Stay tuned for many more articles to come and, in the meantime, feel free to discuss in the comments section!
#1 by Liam on July 24th, 2015 · | Quote
Great series of articles – I learned a lot.
I wondered if there were C# equivalents for a couple of AS3 features I’d found occasionally very useful, namely: Array.every() and Function.apply(). Or rather, what might be preferable patterns in C# for the same kind of behaviour? I guess LINQ gives you plenty of tools for acting on objects in a .every()/.some() like way.
#2 by jackson on July 24th, 2015 · | Quote
Glad you enjoyed the series. Your blog is cool, too. I just subscribed to the RSS feed. :)
As to your question about functional programming, LINQ is generally the answer. It’s often just a matter of finding the equivalent function in C#. For example,
Array.everyin AS3 is equivalent to IEnumerable.All in C#. Likewise,
Array.someis equivalent to IEnumerable.Any
Function.applyis different though. There’s no
Functiontype in C#. Instead, you’d usually use a delegate. If you want to pass an array of arguments like with
Function.apply, you can call Delegate.DynamicInvoke. It’s slower than normal invoking, but then again so is Function.apply.
#3 by vpmedia on August 23rd, 2015 · | Quote
Thanks for the articles!
I was looking for something similar with C# and Java:
#4 by vpmedia on August 25th, 2015 · | Quote
Also it would be interesting to read your opinion about the C# Capitalization Convention recommended by MS:
I’m not really used to write Pascal Casing everywhere except for parameters.
Also Unity uses Camel Case for public variables, so it seems a bit inconsistent for me.
Longer discussion about the topic:
#5 by jackson on August 25th, 2015 · | Quote
I personally use the MS conventions much more than the Unity ones. That means PascalCase for classes, interfaces, structures, enums, enum values, namespaces, functions, properties, and public fields and camelCase for local variables and private fields. I’m probably leaving some things out and there are definitely a million little details to code formatting, but in rough terms I follow the MS conventions as you can see from the code included in the 34 C# articles I’ve written since this series concluded.