3 ms·

> I'll bet that some of those that I named above are now deprecated or superseded by others. All of them are in common use. > if I understand correctly you ar

by tome 6y ago

> I'll bet that some of those that I named above are now deprecated or superseded by others. All of them are in common use. > if I understand correctly you are making my point by stating that a PhD thesis is not the level where you already make language extensions I'm not entirely sure what you're trying to say. I thought you were trying to say that many things that people depend on in Haskell are merely the result of a PhD thesis, i.e. perhaps a messy body of work designed by an inexperienced person. On the contrary, language extensions are well designed and thoroughly thought through. On the other hand, sometimes people get the idea that Haskell can encode everything in types. It can't. They get stuck and get into messes. Nonetheless the ability to encode some things into types makes Haskell by far the most practical language I've used.

jstimpfle 6y ago
> On the other hand, sometimes people get the idea that Haskell can encode everything in types. It can't. They get stuck and get into messes. Nonetheless the ability to encode some things into types makes Haskell by far the most practical language I've used. It's not even that, I'll assume that the majority of Haskell novices are aware that there are humble limits to the expressiveness of most (including Haskell's) type systems. The real problem IMHO is the dichotomy that this approach entails. You have to decide which language to use to model a concept (type language or run time language), and if the idea of what you want to do changes a little, chances are you can't continue on your current path. In other words, I think the type system approach prevents a lot of the fluidity that I want from a programming language as a tool to get things done.
- tome 6y ago
  Personally my experience doesn't match that description. I find it's fairly reasonable to convert existing code between "run time type checking" and static types as necessary. I realise that it doesn't click for everyone immediately. Sorry you had a bad experience with Haskell. If you ever try again I'm happy to help. Feel free to drop me a line with any questions whatsoever. My contact details are in my HN profile.
dllthomas 6y ago
> I'm not entirely sure what you're trying to say. My understanding is that "because it took a whole PhD thesis to come up with, it must take a lot of effort to understand". But I don't think that holds up. Much like the "if I had more time I'd have written a shorter letter", it can often take effort and skill to make a thing smaller and easier to understand.

by tome 6y ago

jstimpfle 6y ago

> On the other hand, sometimes people get the idea that Haskell can encode everything in types. It can't. They get stuck and get into messes. Nonetheless the ability to encode some things into types makes Haskell by far the most practical language I've used. It's not even that, I'll assume that the majority of Haskell novices are aware that there are humble limits to the expressiveness of most (including Haskell's) type systems. The real problem IMHO is the dichotomy that this approach entails. You have to decide which language to use to model a concept (type language or run time language), and if the idea of what you want to do changes a little, chances are you can't continue on your current path. In other words, I think the type system approach prevents a lot of the fluidity that I want from a programming language as a tool to get things done.

tome 6y ago
Personally my experience doesn't match that description. I find it's fairly reasonable to convert existing code between "run time type checking" and static types as necessary. I realise that it doesn't click for everyone immediately. Sorry you had a bad experience with Haskell. If you ever try again I'm happy to help. Feel free to drop me a line with any questions whatsoever. My contact details are in my HN profile.

dllthomas 6y ago

> I'm not entirely sure what you're trying to say. My understanding is that "because it took a whole PhD thesis to come up with, it must take a lot of effort to understand". But I don't think that holds up. Much like the "if I had more time I'd have written a shorter letter", it can often take effort and skill to make a thing smaller and easier to understand.