6 ms·
Type-Signature.com
- drdeca 4y agogot 4/6 on PureScript, and 5/6 for Elm, and I don't know either language. 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?
- scubbo 4y agoNeat idea! 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 :)
- baby 4y agoI was thinking today that there's something wrong about thinking too much in types and type relations. 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. [1]: http://users.ece.utexas.edu/~adnan/pike.html http://users.ece.utexas.edu/~adnan/pike.html
- Waterluvian 4y agoI loosely learned this too and live by it. In particular, it’s so easy to change algorithms but so hard to change data structures. The latter inform (pollute) everything about your functions and architecture. Functions are just boring implementation detail. The structures tell you everything.
- lolinder 4y agoTypes just describe your data structures, and type relations describe mappings between data structures. In this sense, functional programming is actually the purest form of data-first programming: It discourages inventing algorithms at any point in the process, instead asking you to think exclusively about what data structure you have and what data structure you want to end up with. You may have to step between multiple data structures to get from A to B, but the focus is always on the data, never on the algorithms. 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.
- baby 4y agoI guess it wouldn’t disagree with you as hard if most relations weren’t typed so loosely because of the polymorphism
- nequo 4y agoThinking in types and type relations sounds to me like Rule 5 taken to its logical conclusion. Types are your data structures, and they guide how you write your functions. 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 https://www.youtube.com/watch?v=bRudW0aBNg8 [2] https://www.youtube.com/watch?v=X36ye-1x_HQ https://www.youtube.com/watch?v=X36ye-1x_HQ [3] https://haskellwingman.dev/ https://haskellwingman.dev/
- hcarvalhoalves 4y ago> Types are your data structures 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.
- lolinder 4y agoYou made that type artificially abstract by leaving out the type names, which in a nominally-typed language are a first-class part of the type signature, not arbitrary symbols you can leave out. 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.
- hcarvalhoalves 4y agoThe moment you name the type, you're talking about a particular implementation, no? The type system doesn't know about the semantics humans ascribe to names, it just matches shapes. 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.
- epgui 4y agoYou should look into "category theory for programmers" by Bartosz Milewski, or look into the dependently typed languages other people mentioned (Idris, Agda...), or how type theory is replacing set theory as the foundation of mathematics because it makes things computable and is not fundamentally broken (there is an interesting "HoTT book" you can look up that might be relevant).
- Lacaranian 4y agoThere's one perspective (popular in funtional programming circles) that says data structures simply _are_ a special sort of function; that is, one that take no arguments. 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.
- mdm12 4y agoIn my perusals into the Haskell ecosystem, discovering Hoogle[1] was definitely a revelation on the power of a strongly-typed language. Sometimes, you know the _shape_ of the thing you are looking for, but not the name. The ability to search a repository of packages for all functions conforming to a certain type signature (e.g., (a -> Bool) -> [a] -> [a]) is a superpower. [1] https://hoogle.haskell.org/ https://hoogle.haskell.org/
- DonaldPShimoda 4y agoA minor nitpick: the crucial element here is that Haskell is statically typed. "Strong" typing is not well-defined, and even in contexts where that word is appropriate, it only exists as a relative descriptor (not in a vacuum). 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.
- msla 4y ago"Strong" as a descriptor makes more sense if you see a type as a kind of contract: You agree that you will only perform these operations on this value, and the language agrees that all of those operations will be well-defined. "Strength" is how difficult it is to disregard those contracts and peel back the abstraction they enforce to get at some underlying representation, possibly all the way down to where "Bits Is Bits" and everything is permitted. You'll notice that this makes Python's type system stronger than the one C++ has, once you get over the idea that Python's types attach to values, not variables.
- DonaldPShimoda 4y agoRight, so it's not very rigorously defined; it's kind of a "feeling" about how easy it is to subvert the high-level system, and it only makes sense to describe a language as "strong" in contrast to another language — which is kind of what I'd said originally. ;) In any case, I think we agree that it's not what the parent comment of mine had intended to refer to!
- eyelidlessness 4y agoTip for anyone who doesn’t know Haskell (eg me): if the signature has an IO return type, the answer has a verb in the name.
- hexane360 4y agoAmazingly, I got 6/6 on Haskell despite only dabbling in it a few years ago. I suppose that says something about the descriptiveness of type signatures, or the generality of Haskell's functions.
- l0b0 4y agoWTF. 5/6 on Haskell despite having barely touched it 10+ years ago. Pretty descriptive signatures, although the function names could do with some clarification.
- deleted 4y ago[deleted]