As to if you think TypeScript is worth it, of course its worth it. Whether or not you're writing JavaScript or TypeScript, you're still thinking in types, function signatures and data structures. TypeScript allows you to encode that information so you don't need to hold it in your head (or have other programmers figure it from usage, as would be the case for JavaScript). But that aside, TypeScript's tooling alone makes it worth it.
As for this flame war, i strongly suspect that most type system advocates have mostly likely used BOTH dynamic and static languages (C#, Java programmers have had to deal with JavaScript for decades), while I expect the majority of dynamic advocates (say Python, PHP, JavaScript) have primarily stuck with dynamic.
Those with the wider perspective have the better insight imo.
JavaScript is very strongly typed. Everything will have a type. And it will be enforced and checked during runtime.
This will prevent buffer overflows and memory leaks.
JavaScript is dynamically typed.
This allows you to to do funny things like [1,2,3] + ",4"
Because it's strongly typed, all values will be converted to a type.
JavaScript does type checking during compilation, but it's not considered a static language, because it allows "duct typing" meaning you can add or remove properties and methods on objects during runtime.
I am aware of those definitions. It was "sound" and "unsound" what threw me off.
> Whether or not you're writing JavaScript or TypeScript, you're still thinking in types, function signatures and data structures. TypeScript allows you to encode that information so you don't need to hold it in your head
Static vs dynamic, a flamewar that's over sixty years old to which I am not going to contribute.
> But that aside, TypeScript's tooling alone makes it worth it.
JavaScript has pretty good tooling too.
> As for this flame war, i strongly suspect that most type system advocates have mostly likely used BOTH dynamic and static languages (C#, Java programmers have had to deal with JavaScript for decades), while I expect the majority of dynamic advocates (say Python, PHP, JavaScript) have primarily stuck with dynamic.
Should we ask LISP developers? How about its derivates like Clojure or Scheme? There are many of them here in HN (in fact, I've dabbled on Clojure a little bit myself), though that would probably lead to a different flamewar entirely (functional vs oo).
In any case, I don't follow what point you were trying to make writing this suspicion, it was clear that you were going to get counterexamples and you didn't provide sources that at least gave support to having such a suspicion. I would appreciate if you elaborated what was your implication.
By the by, I worked in java during 2013 and 2014, and I've been working with Go exclusively for nearly a year now. I still don't really care about what type system any given language I've worked on has, there's good and garbage code everywhere. Though, since all this can only be opinion until someone conclusively demonstrates a given type system's superiority, I still prefer writing python code.
> Those with the wider perspective have the better insight imo.
Maybe we should ask Guido van Rossum's perspective.
I believe most of the best in class tooling for JavaScript borrows on leveraging TypeScript compiler for inference. And its still below the bar offered by TypeScript.
> Should we ask LISP developers? How about its derivates like Clojure or Scheme? There are many of them here in HN (in fact, I've dabbled on Clojure a little bit myself), though that would probably lead to a different flamewar entirely (functional vs oo).
OOP is not at odds with FP. They are different things entirely and can be leveraged in equal measure within a codebase. Consider C# and LINQ (with LINQ derived from lazy expressions in Haskell). As for LISP, TypeScript services as a good test case for layering dynamic languages with type systems, so why not TypeLISP?
Anyway, the point im trying to make is, irrespective of if the programmer is working with a type system or not, the programmer is still reasoning about software with types. The dynamic language programmer is still thinking about function signatures (arguments, return types), they are still thinking about 'the properties of some object' and they still think about generic abstractions (as in .map()). I don't understand why JavaScript programmers are adverse to encoding that information in a type system when it solidifies and communicates their intent. (both to other programmers as well as the compiler)
JavaScript on its own requires the programmer to infer the original developers rationale from usage, and assertions of 'correctness' can only truly be inferred by running a software (by test or otherwise). Obviously, both TS and JS need tests, but in the TS case, you've removed a whole class of issues around types and call signatures, where as in JS, one might be compelled to test both 'types' and 'logic'. A type system can at least narrow huge classes of problems, allowing a programmer to focus on testing logic, not the inadequacies of their (or others) brains to hold mountains of implied type information in their heads.
If you want one practical example..... refactoring. While JavaScript is dynamic, just change the name of a function, or move functionality elsewhere...what assertions can JavaScript or its tooling provide that all dependent code is appropriately updated as a result of that refactor?
Honestly, choosing to leverage of a type system, imo, is an open admission of the complexities of software, and the fallibilities of the human brain. Rejecting the benefits of a type system to me demonstrate a dangerous over-estimation of one own abilities, or a lack of personal introspection with respect to reasoning. While this debate seems to continue, I don't think my views on it ever will.
> As for LISP, TypeScript services as a good test case for layering dynamic languages with type systems, so why not TypeLISP?
Lisp users think that a 'dynamical' and a 'dynamically typed' language are two different things. Lisp is both. Being 'dynamically typed' supports or simplifies a lot of dynamical features.
There are a bunch of languages which implement a subset of Lisp features and which were adding type systems. Historically much of typed FP was developed out of Lisp tradition.
Common Lisp for example has CLOS definitions like:
(defclass person (living-thing)
((name :type string)))
So the definition makes clear that are a class/type which inherits from the class/type living-thing. It also defines that contents of the slot name are of type string.
A CLOS method then is:
(defmethod say ((from person) (to person) (m message))
...)
Which means that an object of class person sends to another object of class person an object of class message.
Multi-methods in CLOS allow us to define and dispatch on the class of several arguments.
Common Lisp then also has type declarations:
(defun collide (a b)
(declare (type moving-object a b))
...
)
This allows programs to document types, compilers to use types for optimization purposes and some compilers to do type checking.
What Common Lisp lacks is a more extensive/expressive type system which would be competitive with what Haskell/or similar would offer.
I'm a bit shocked that you haven't seen a discussion on the "virtues" of functional programming and "evils" of object oriented programming (and vice versa) here. If you truly haven't seen it, you might soon enough.
> Anyway, the point im trying to make is, irrespective of if the programmer is working with a type system or not [...]
Everything after this is one of the arguments in favor of static typing, and I've read variations of it for years. There are just as many, and just as old, counterarguments.
I wish there was a way to conclusively prove which type system is truly better, if only to put that discussion to rest and for the industry to converge upon that type system. And then we'll be able to focus on other things.
Until then, this is mostly a matter of opinion, which is why...
> I don't think my views on it ever will.
... Neither will almost anyone else's, there's no absolutely compelling reason to.
But, i can see the crease in those screenshots >_>
Foldable displays are probably the future, but they need to be actual value (like a significantly larger display) for them to properly take off. Waiting to see the next generation Samsung phones, should be interesting once they get the form factor right.
Static: Statically checked by a compiler.
Dynamic: Not Statically checked by a compiler
Strong: Types enforced by the runtime
Weak: Types not enforced by the runtime
Of these,
JavaScript: Dynamic, Weak
TypeScript: Static, Weak
C#: Static, Strong
As to if you think TypeScript is worth it, of course its worth it. Whether or not you're writing JavaScript or TypeScript, you're still thinking in types, function signatures and data structures. TypeScript allows you to encode that information so you don't need to hold it in your head (or have other programmers figure it from usage, as would be the case for JavaScript). But that aside, TypeScript's tooling alone makes it worth it.
As for this flame war, i strongly suspect that most type system advocates have mostly likely used BOTH dynamic and static languages (C#, Java programmers have had to deal with JavaScript for decades), while I expect the majority of dynamic advocates (say Python, PHP, JavaScript) have primarily stuck with dynamic.
Those with the wider perspective have the better insight imo.