 This is going to be another short one because really the only thing that needs to be talked about for this part of it is operators and operator overloading. Now, I'm of the mindset that as long as the feature is justified in how complex the implementation is, then it's fine to add it. Just because something has the potential for abuse does not mean that the language component should outright be removed. This is a big reason why Java, who takes the, oh, it's abusable, let's not allow it stance, isn't well suited for and doesn't have much of a space in numerical competing. In fact, there are other languages which attempt to address this issue on top of the JVM and don't really advertise themselves for much else. They're kind of just, hey, I'm for numerical computing and that's it. That's pretty obvious that this feature should be allowed. But furthermore, operators are essentially just functions with a special syntax associated with them. And I don't think anybody would outright ban the use of functions or procedures. Now, the argument given against operator overloading still applies to those as well. Think about it. A operator can do something other than what the operator symbol is defined as creating undefined behavior or unexpected behavior rather. Well, so can a function or procedure or method. They can do something other than what the name is. One glaringly obvious example of that is method stubs, where it doesn't actually do what it says. It throws a not implemented exception. Funny how that works. And it's okay for that, but not for operators. So with this in mind, with my, they're okay attitude in mind and explained, what do I think about how a C sharp address them? Well, C sharp is problematic in how it does it. There's a limited set of operators that you can define, which is okay. If nothing else, let's keep with the already existing operators, because that's at least something. And they cover the situations that most things would need. But what does it get wrong? In C sharp, like most class based object oriented languages, you're not given a choice where things are defined. They all get thrown in a class. This means that you can't define new operators for an existing type, because you can't add things to that class. Now there are extension methods that kind of look like they're added to that class, but they're not really. And you you can't do operators as extension methods. They have to have a full name. People have even tried by using the little special name that they're given. And while it works, and you can call it with that special name, the operator resolution, the way it works, doesn't allow that to actually happen. So you can get creative with special wrappers and whatnot, but it doesn't it's crafty and it doesn't work in a lot of situations. So situations where I think even the anti operator overloading people would agree that it's justifiable, like linear algebra. Those operators have very well defined semantics, but just just aren't defined for the array type. You'd like to add them in, but effectively can't and have to fall back to functions to do the work for you. That's less than ideal. In C sharp, it's simply not possible to add these operators in either and you, much like with Java, have to fall back to specially defined methods. I don't like that and I don't think anybody particularly likes that. F sharp addresses this issue and I'll talk a little bit more about that, but it really shouldn't be surprising that that's the case at all because functional programming languages, as I've stated numerous times, tend to be extremely good for math. They tend to be specialized for math and various other calculi. Ada, on the other hand, gets this a little bit more right. Much like C sharp, you're only able to define operators that are already defined and there are certain symbols, so if you think about as operators, which are not actually operators, assignment is one such example and I do agree with assignment not being something that you should allow to be overridden. C++ gets that a little wrong, although given the way C++ works, it's understandable, but I think there are better ways to address that whole thing that's its own other issue entirely. So what Ada does right, I think, is that the declarations are allowed to be top level constructs. So you can define operators at the package level, which is essentially namespaces. And once you include that package, you get those operators. This prevents polluting the namespace and situations where you're simply not going to need those semantics or could possibly need other semantics, but still allows you to provide them on even pre-existing types. Now, this makes for linear algebra through operators something that you can pretty easily achieve with Ada. There are certain operators which you simply can't wind up providing or have to do special overloads that gets a little bit complicated, but not horrible considering they're all context sensitive. What I mean by that is the difference between the cross product and dot product. They are differentiated based on the return type. And since Ada does do overloading that factors in return type, you can have both of them implemented through the same operator symbol and which one actually gets done depends on what it can resolve out of the return type. Now, there are situations in which, since you're overloading both of them, you may wind up with expressions where it cannot actually resolve those, but if you're assigning them immediately to a named variable, it's no longer an issue because you will get the exact thing that you meant to. Better than either of these, I feel, is how F-sharp addresses them. Much like how Ada does it where their top level declarations, F-sharp does the same thing. Now, you can define operators as part of the actual type, much like in C-sharp, and that's done for compatibility's sake, but you can always define them as top level static operator things. And similarly, as long as you've included that namespace, that module, whatever their module for that, they'd be living in a module, not a namespace, as long as you've opened up that module, you have access to those operators. That's really convenient, but F-sharp goes one step further in that there is a set of symbols which you can use for composing new operators. Now, they have some special rules for that. It doesn't allow you to use anything you would like. I find that a little bit unfortunate, but it's definitely a lot better off than Ada has because you can, again, define new special operator symbols. This allows for differentiation between, say, linear algebra and array arithmetic, both of which would share the symbols, both of which would operate on the same types, but which have different semantics in some cases. Not all, but some. As an example, the cross product between two arrays and the multiplication of two arrays yields incredibly different results because of the two different schools of math, two different algebras specifically. That matters, and F-sharp lets you get two different symbols for that. Then you can address that by having those in two entirely different packages in Ada and include only the one you need. You're unlikely to ever be using both of those at the same time, so the collisions are largely a non-issue. But there's one approach taken by another language, seed seven, that I think gets this perfectly. I do, to an extent, agree with the Java guys. Operator overloading is dangerous, and people in an effort to write as few keystrokes as possible have resulted in overloading operators in some well-intentioned but very problematic ways. What seed seven does is considering its way of defining new syntax allows operators as part of that new syntax, because that's what it is. When you're defining a new operator, there is a precedence and associativity you have to give it. These do not have to exist for new functions. This additional requirement means that downstream programmers are going to have to put additional effort into defining them in the first place. Additional effort means additional thought. That pushes developers towards actually using functions like they probably should, and only doing operators when they've really thought it over. I think that is the best possible approach. You're given far more freedom in what those operators can be, but you're encouraging the developers to do the more reasonable thing and not use them, unless it's really truly justified. In an ideal language, it would take what seed seven does. That's all for operators. I don't know what will be coming out next. So probably sub-routines in general, but until then, have a good one, guys.