4 ms·
"But I know of no scientific studies actually backing up the (sometimes implicit) claim that this types-first methodology leads to better languages, from the po
by js8 10y ago
"But I know of no scientific studies actually backing up the (sometimes implicit) claim that this types-first methodology leads to better languages, from the point of view programmer productivity."
So here's my problem, maybe I am using Haskell wrong, and somebody can give a good answer (FYI - I am big fan of Haskell, but I am still much more efficient in Python).
Let's say I write a library, I annotate all the functions with types, so I give it a nice API, and then what happens.. I realize I should have used a different type for this parameter in this library. For instance, a type class instead of normal type. But boy, it's like everywhere. Or it's a third party library and I can't really change the type signatures. I just wish sometimes that I could just "forget" the types temporarily and just borrow the existing logic, and then reintroduce different types, type check, done.
To be fair, Haskell has potential solution for this type of problem - type inference. But the thing is, once you write the (expected) type signatures into your program (which is sometimes needed to actually help the type inference, and it's also useful as a documentation), they are always there, and sometimes, they obstruct.
So I guess I wish there was a tool with which I could manage type information in the program in a lot more dynamic way than I currently do. That would, IMHO, close the gap to the dynamic languages.
What about making every type into a type class, would it do the trick? But how would the concrete type be specified, then? Would the compiler pick it?
(Maybe it's obvious, but let me point out the connection of this question to lambda calculus. I can have two functions in typed lambda calculus which are different, because they have different type signatures, but their actual semantics is identical (provided they get arguments of correct type); or in other words, if we convert both into untyped lambda calculus, we get identical functions. So the question is, why cannot we somehow reuse code from the first function, why we have to define the same code twice with different type signature?)
- imh 10y agonewtype BusinessLogicThing = BLT Int Then you use the semantic thing instead of the other thing (with no overhead). That can help in some situations.
- clusmore 10y agoSome really interesting points in here. >So I guess I wish there was a tool with which I could manage type information in the program in a lot more dynamic way than I currently do. I write a small amount of Haskell for personal projects and I always use type annotations for top-level definitions for two reasons. 1) I write them in advance because it helps me think about what I'm doing, and 2) I like that the compiler will tell me if I accidentally change the type between successive compilations. If it weren't for the first point though, I can imagine it would be nice to omit the type signatures and then have the compiler not only infer them for me but actually place them into the source code to save itself the trouble next time whilst improving my documentation. If it could do that, the logical next step would be to have another tool to strip out all the type signatures, to give you that design-time dynamic feeling whilst still being very much static at compile time. You can refactor all you want changing signatures and the compiler will put them all back in again when you're done.
- tome 10y agoWhat's wrong with just wrapping and unwrapping values as different types, at the few points you need to do so?
- js8 10y agoNot only it becomes ugly, but it also doesn't help you in all situations. Let's say you have a function in a library that has signature Int32 -> Int32. Then you realize you need to do the same thing, but for Int64. You can't reuse it by wrapping. The above can seem silly, but problems like that are very real for Haskell strings. I mean, from type-purity perspective, this behavior is OK. But from practical perspective (like Python's), it's a bummer. Why you shouldn't be able to reuse existing code just with different type signatures?
- tome 10y ago> Let's say you have a function in a library that has signature Int32 -> Int32. Then you realize you need to do the same thing, but for Int64. You can't reuse it by wrapping. For that we have typeclasses.