Type-Signature.com
type-signature.com
type-signature.com
But I agree with your takeaway. Hoogle is one of the coolest development tools I've ever used, and I desperately wish every other statically typed language had their own Hoogle.
In any case, I think we agree that it's not what the parent comment of mine had intended to refer to!
So we have at least three axes: Static vs Dynamic, Weak vs Strong, and Conceptual vs Semantic, where more Semantically-typed languages allow you to represent more of the meaning you're going for in the type system, and have the language enforce semantic rules like not being able to add person-height to person-weight even if they're both integral types.
(Note that my imaginary string-only language is also statically typed of necessity, given that all variables must have type string and no value can ever move from a variable of one type to a variable of another type.)
https://docs.scala-lang.org/scala3/guides/scaladoc/search-en...
But at least the usual programming language rankings would suggest that Scala is quite mainstream by now.
We have it currently at place 15 on RedMonk, place 15 on the IEEE Spectrum ranking, place 19 on PYPL; whereas Haskell does not show up in the Top20 anywhere there.
Also Scala job opportunities and salaries are quite good when looking at the IEEE and Stackoverflow surveys, ranking quite a bit ahead of Haskell.
I would say Scala is pretty much a mainstream language. There's not much room in the Top20 given there are hundreds of languages out there.
Still, scala has always been promoted as being easier to learn (more like Java?) and being on the JVM, rather than winning on its own merits. So kotlin will probably eat scala.
Kotlin is only competition in the "better Java" space. But that's more or less quite a small part of Scala. Scala starts to be an interesting language in its own regard beyond this point. Kotlin OTOH does not even offer comparable features. So it can't replace Scala where Scala shines.
I would say that in the long run it's Kotlin that's "in danger" as Java becomes more and more a "better Java" itself. There is not much stuff left in Kotlin these days (besides the nicer syntax) that is still missing in Java. And it gets less with every Java release. As Kotlin, mostly "just a better Java", has not much to offer besides some syntax sugar it will have a hard stand against a future Java, imho. Scala does not have this problem as people mostly given up using it as a "better Java", or migrated to Kotlin (or even back to Java) for this purpose anyway, and are using it now in a more idiomatic way that can't be simply replaced by any "better Java".
Regarding simpler: That's for sure a strong point in favor of Scala compared to Haskell. Scala 3 is on its surface not more complicated than Python, I would say[1]. It's also easier to pick it up gradually, compared to Haskell where understanding even "Hello Wold" will require some understanding of monads.
For people who don't know Scala by now or didn't look into it for a long time: It's one of the better FP languages currently out there, but it won't drown you in alien concepts right form the start. It's easy to pick up. But it's still at least as powerful as Haskell. But more pragmatic and down to earth. It's worth having a look for sure!
The simplest and quickest way to give it a try is installing scala-cli[2], I guess.
Than, for bigger / real projects you would use likely Metals[3] for VS Code / vim, the Scala IDEA plugin, or, for the Emacs diehards, the new Ensime. (Where the Metals experience is imho currently the smoothest).
---
[1] https://docs.scala-lang.org/scala3/book/scala-for-python-dev...
There are two things that I miss any time I try to go back to Java from Kotlin, and recent improvements haven't helped matters:
1) Null safety. Java has Optional now, but most of the standard library still may or may not return null, and you have to read the javadoc to find out if you should be handling for null.
2) The collections library. Kotlin has the most comprehensive and consistent collections library I've ever seen in any statically typed language; it's comparable to Python in expressive power. Java doesn't even come close.
The features that Java has adopted (sealed interfaces, records, etc) are nice, but not the core of why I use Kotlin.
https://klaftertief.github.io/elm-search/?q=c%20-%3E%20(a%20...
The page could probably stand to have a sentence saying that it is a quiz about "can you tell which of these 4 names of functions are the name of a function with the following type signature?" . Instead it has a picture of a unicorn's face?
I suppose that says something about the descriptiveness of type signatures, or the generality of Haskell's functions.
Anecdotally, though, I got 4/6 while knowing nothing about Haskell just by meta-analysis - a type signature including a "Foldable" term is most likely to relate to a method with "Fold" in the name :)
Rule 5 of Rob Pike[1] says:
> Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
which makes a lot of sense to me. You see this concept being used all over the place in Golang/Rust.
But functional languages make you think in very different ways, which makes your program organized in much different ways as well. Although I can't quite put my finger on what exactly is so different.
Functions are just boring implementation detail. The structures tell you everything.
From what I've seen, this is where people usually struggle when it comes to learning functional programming. People are so wrapped up in the algorithms that they have a hard time thinking in data in the way that is required to do functional programming effectively.
Agda[1] and Idris[2] turn this idea into interactive editing with typed holes. You put a "?" in the code and the compiler fills the hole in for you based on the type that it infers for it. Haskell has a less expressive type system but it also has typed holes and Wingman[3] extends the Haskell Language Server to use them for interactive editing.
[1] https://www.youtube.com/watch?v=bRudW0aBNg8
Is this true? I understand types are abstract, while data structures are concrete.
Like, the type...
x -> a x y -> z y
...tells me nothing. But that is, among many things, the type for a hash map lookup. Still, a hash map is a particular implementation, and the type alone doesn't capture this – it could mislead me into thinking any implementation that fits this shape is fine.
This is the actual type of Haskell's dictionary lookup:
k -> Map k a -> Maybe a
I don't know about you, but that's pretty self-explanatory to me.
That's only because you, the programmer, expect a type named "hash map" to implement a hash map – but this information is not being described by the type itself, it's out-of-band. The actual definition of the hash map data structure is given by the algorithm. In fact, without inspecting the algorithm, it's impossible to know it correctly implements a hash map, you're just trusting the arbitrary name of the type.
Depending on the language, no. In many languages types can be subtyped, and if you name the supertype you do not know necessarily which implementation you have. (Incidentally, in Haskell, a Map is not a HashMap, it is a tree map.)
> The actual definition of the hash map data structure is given by the algorithm. In fact, without inspecting the algorithm, it's impossible to know it correctly implements a hash map, you're just trusting the arbitrary name of the type.
This is exactly my point! The question we started with is: does the type signature help you to reason about how to transition from one data structure to another data structure without having to think about the details of the algorithm? I argue that it does, because I tend to trust that standard library designers aren't capriciously violating my expectations for what a Map is.
If you trust the standard library designers, then the type signature abstracts away the implementation details of the algorithm so you can do what Rob Pike recommends and focus on the data.
If you don't trust your language's standard library, you have worse problems than difficulty reasoning about type relations.
You don't even need to trust them. The compiler checks that their Map is the same as what you call a Map.
In the scenario that I am imagining, you have defined your data structures as types. You're looking for an algorithm to perform a particular transformation on your data. This transformation is from one data type to another, so you know the "type signature" of the algorithm. If the algorithm is already implemented, then you can find it with typed holes or Hoogle. If it doesn't exist yet, you can write it.
Rob Pike's Rule 5 says that if your types are good, it will be self-evident what functions to use to transform them.
Sort of. I think the person I was replying to was indicating that the implementation could be wrong and still match the type signature. As a simple example, `insert` could return the exact same Map object as was passed in (rather than one that has the key updated) and still match the type signature of `insert`.
On the whole you're right, because if your standard data structures are that bad you should really be using a different language, not choosing to ignore types because they might not be helpful this time.
> x -> a x y -> z y
> ...tells me nothing.
I am guessing that you wouldn’t see a type signature like this in a real codebase. The type signature of Data.HashMap.Strict.lookup is
(Eq k, Hashable k) => k -> HashMap k v -> Maybe v
https://hoogle.haskell.org/?hoogle=x%20-%3E%20HashMap%20x%20...
Not really. Types include datastructures. They define the set of values that a datastructure can assume. They do the same for everything else, like variables, functions etc.
Really, in practice this means data is a partially applied, curried, identity function. Put something in, get the same thing out later, acting as memoization.