From AS3 to C#, Part 23: Conclusion
Today’s article wraps up the series with some closing thoughts comparing and contrasting AS3 and C#.
Table of Contents
- From AS3 to C#, Part 1: Class Basics
- From AS3 to C#, Part 2: Extending Classes and Implementing Interfaces
- From AS3 to C#, Part 3: AS3 Class Parity
- From AS3 to C#, Part 4: Abstract Classes and Functions
- From AS3 to C#, Part 5: Static Classes, Destructors, and Constructor Tricks
- From AS3 to C#, Part 6: Extension Methods and Virtual Functions
- From AS3 to C#, Part 7: Special Functions
- From AS3 to C#, Part 8: More Special Functions
- From AS3 to C#, Part 9: Even More Special Functions
- From AS3 to C#, Part 10: Alternatives to Classes
- From AS3 to C#, Part 11: Generic Classes, Interfaces, Methods, and Delegates
- From AS3 to C#, Part 12: Generics Wrapup and Annotations
- From AS3 to C#, Part 13: Where Everything Goes
- From AS3 to C#, Part 14: Built-in Types and Variables
- From AS3 to C#, Part 15: Loops, Casts, and Operators
- From AS3 to C#, Part 16: Lambdas and Delegates
- From AS3 to C#, Part 17: Conditionals, Exceptions, and Iterators
- From AS3 to C#, Part 18: Resource Allocation and Cleanup
- From AS3 to C#, Part 19: SQL-Style Queries With LINQ
- From AS3 to C#, Part 20: Preprocessor Directives
- From AS3 to C#, Part 21: Unsafe Code
- From AS3 to C#, Part 22: Multi-Threading and Miscellany
- From AS3 to C#, Part 23: Conclusion
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.
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
AS3 also keeps things simple by omitting various features like extension methods, enumerations, structures, “unsafe” code, lambdas, some basic types (e.g.
float), iterators, finalizers and destructors, the preprocessor, multi-threading, nullable types, operator overloading, and parameter modifiers like
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 (
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.
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.
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 ·
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 ·
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 ·
Thanks for the articles!
I was looking for something similar with C# and Java:
#4 by vpmedia on August 25th, 2015 ·
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 ·
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.