The adoption of C++ was a necessary mistake. Why necessary? Legions of C programmers were not going to adopt OOP unless they could use the code they've already written and the libraries they've come to depend on. Also, the idea of not having to learn radically new syntax was a big ++ as well. In order to persuade the majority of the programming community to adopt OOP, it needed to feel safe and low risk. These programmers knew they needed a way to write better code. C programs were plagued by hard to maintain code that was as fragile as a new iPhone. Memory management pitfalls and buffer overflows could drive any normally sane person to question the virtue of being born at all. Many programmers surely went outside during a pouring rainstorm and, with outstretched hands reaching to the sky, would exclaim, "Why do you torment me so? Surely there must be something else you meant for us to use! Send me a sign!"
Unfortunately, the universe's answer was still unsigned.
"This new language was developed by Bjarne Stroustrup and was called C++. Stroustrup states that the purpose of C++ is to make writing good programs easier and more pleasant for the individual programmer. When he designed C++, he added OOP (Object Oriented Programming) features to C without significantly changing the C component. Thus C++ is a 'relative' (called a superset) of C, meaning that any valid C program is also a valid C++ program." (A Brief History of C++)
The idea that a modern language with OOP could exist seamlessly along with their C code and libraries seemed like a dream come true to developers. They would get all the benefits of polymorphism and encapsulation while still writing in a familiar syntax that works so well with their existing code!
C++ had the same pitfalls and caveats of C while trying to force procedural-minded programers to fumble clumsily with objects. What resulted was a collection of classes producing objects that were nothing more than struct function libraries and data objects. Polymorphism was often utilized as a clever tool of code reuse rather than creating true subtypes. C++ by virtue of being a subclass of C inherited everything that made mistakes easy to make while failing to override the procedural thinking that sabotages OOP design.
Enter TypeScript
Legions of C programmers have now been replaced with legions of JavaScript developers. NPM has over 350,000 packages ready to be downloaded. The amount of JavaScript in browser libraries is nigh uncountable. Developers once intoxicated with the magic of JQuery are now attempting to maintain thousands of lines of code with no type-checking and no structure to speak of other than the developer's own sense of propriety. When faced with finding the code that is mysteriously changing the value of an input box, the programmer's only choice is grep or its like.
- JavaScript has no compile time type-checking. There are no types.
- JavaScript's var does not respect block level scope.
- There are no classes but there are functions that can have functions!
- Things are equal when they are not equal.
- Oh yeah, there is undefined, and there is null, and no, they are not the same thing.
- Many more
TypeScript has come to save the day from all this waaay too permissive insanity (or so it would seem).
Your JavaScript syntax works perfectly well inside of TypeScript, and as a matter of fact, you can still use all your favorite JavaScript libraries! You get OOP without learning drastically new syntax and still have the structure and the features of a modern language! Yippee!
Sound familiar?
TypeScript's supposedly biggest advantage is its ease of interoperability with existing JavaScript code and libraries. I argue that this is in fact its biggest weakness. TypeScript amounts to merely a superset of JavaScript and will bring with it all of JavaScript design issues and pitfalls. Too often in TypeScript code I've seen the "any" type all over the place. This interoperability leads to a culture of permissibility that is a deep flaw existing in JavaScript. Sure you can be disciplined and write pure TypeScript code, but the very fact that you don't have to makes it unlikely that you will.
Dart is the new Java
Dart is a clean break from JavaScript but still compiles to JavaScript. It's rigid handling of JavaScript interoperability protects it from toxic permissibility while enabling the Web developer all of the tools and protections of a first rate modern language.
Top comments (3)
Why Dart? There are numerous languages already that compile to JavaScript, and now with WebAssembly the options expand even further. What's unique about TypeScript is the fact it is a superset and keeps pace with proposed language updates. If that's not the solution, why not consider the full spectrum of options available for non-JavaScript languages that compile to either JavaScript or WASM as a target?
Dart is a stand alone language in its own right that also has the option of javascript interop. It has modern language features such as optionals, class-as-interface and async/await while having a first rate collections api. I work daily with both TypeScript, Dart, JavaScript and C++ in various layers of our application stack and I can see how programmers tend to succumb to "toxic permissibility" when it is available to them. I am guilty myself and the design suffers.
As far other languages that also compile to javascript/wasm I'd love to hear what you think is a better option than Dart for OOP?
Javascript is good ! Typescript is good ! WebAssembly is good !
so
assemblyscript.org/