> I think Scala is the best mainstream language with a sophisticated type system. Sophisticated type systems are money in the bank. Going from TypeScript to Scala is like going from JavaScript to TypeScript.
The new text is
For me, from a type system perspective,
going from TypeScript to Scala is like
going from JavaScript to TypeScript.
(I love TypeScript and write a lot of it!)If I see `A`, the search space to understand where that comes from is quite large for most Scala.
package mypackage
import shapeless._
import anorm._
import mything.MyObject._
import com.seriouscompany.Foo
object MyThing {
val a = new A()
}
One of the 15 files in the anorm package? Does it come from one of the 40 files in the shapeless package? What about mything.MyObject and the dozen mixin traits that it has?
Alright, let me clone the repo, startup my 4GB IDE, wait 15 minutes for it to download JARs and index eveything and then I can get an answer to where `A` is defined.
Scala wildcard imports are very common in practice, but even if I eschew them, there still another 50 files in the mypackage package that could contain its definition.
---
The same thing can happen in TS with globals, but those are rather few.
Python doesn't have this problem (unless you use wildcard imports, which is often recommend against [1]).
Java does not have this problem, except for protected/internal classes which have only local use anyway (yes there are wildcard imports, but they are rather rare [2]).
Go has this problem for files in the same package, but not from other packages.
C and C++ are far from a hallmark of readability. Though there is at least a common C++ practice to at least always use the fully qualified name [3].
Ruby shares this issue.
---
What makes Scala worse is that wildcard imports are strongly encouraged by libraries and in very frequently found practice, for things such as implicits whose whole purpose is to not be explicitly named.
Plus in Scala, object, classes, fields, methods...all of these can be imported into the scope. So in practice this becomes a more common problem.
[1] https://stackoverflow.com/questions/3615125/should-wildcard-...
[2] https://stackoverflow.com/questions/147454/why-using-a-wild-...
[3] https://stackoverflow.com/questions/1452721/why-is-using-nam...
Just like every language has an untyped/unsafe method of operation. But some languages use that sparingly; others have that for the whole language.
Now that's an interesting perspective on a language that seems too magic. A whole ecosystem of objects who must not be named!
Unsound, inconsistent, overly complicated, poorly abstracted, improper paradigms.....any of those would be a more legitimate criticism than "unsophisticated".
Usually that happens using generic types. They are almost completely worthless in Typescript, and have no analog whatsoever in JS. So you are mucking around just to please the transpiler but adding a type unsafe hack anyway in place of a generic argument.
Typescript should have just stuck with providing checks on type declarations. That's it. Stop adding features from Java/C# when they make no sense in JS.
I would pick another language in a heartbeat, given a choice.
You're right if by "more expressive" you meant "not really safe at all". By using the types of hacks you proposed, you end up losing type information and safety guarantees. So why bother using Typescript in the first place then? Your example is the perfect argument against Typescript.
If you were referring to generic types, then there's no good reason to do that in the first place. Use a base type. Polymorphism 101. Anything else would be duck typing, and not safe.
There's no middle ground with type safety: it is either safe or not. And if there's a chance it's not, then you've lost and all of your efforts are pointless without resorting to manual checks.
And if you were somehow referring to C++ like templating (unlikely), then Typescript doesn't support that anyway.
Probably, but the thing you are doing doesn't accuse TypeScript of being unsophisticated but of having an unsophisticated type system (these are as different as describing a person as being short is different from describing them as having short hair.) And, yeah, a type system that lacks soundness, lacks consistency, is overly complicated and poorly abstracted, and uses improper paradigms can fairly and succinctly be described as unsophisticated compared to one that does not have those shortcomings; the descriptions you point to may be more specific, but are not more legitimate, nor are they more appropriate when the context isn't a detailed dissection of the language.
Avoid them.
> Unsound, inconsistent, overly complicated, poorly abstracted, improper paradigms
apply to the current stable version of Scala as well. You'd be comparing Typescript as it is in production right now to a best case scenario of where Scala could end up in a couple years.
I think that's a legitimate and, most importantly, factually correct point to make.
If you're interested in what these "Higher-kinded types" are: https://typelevel.org/blog/2016/08/21/hkts-moving-forward.ht...
An HKT encoding using conditional types: https://github.com/pelotom/hkts
You better have money in the bank to allow for all the refactoring you will be doing once you realize your data model needs to change in unforeseen ways ;)