5 ms·

I was almost 100% certain it was a joke until I read the paragraph that quote is from. I want to reassure you that most Haskell evangelists (myself included) t

• skybrian 8y ago
  I think the large amount of effort the Rust community puts into explaining what they're doing with their type system, making it a first-class feature that's included in standard tutorials and having a lot of ergonomic effort put into error messages, is actually essential to making it work for ordinary users. (And even then, just barely; fighting the borrow checker is a thing.) A language that allows someone to build this as a library is much more scary. What other incomprehensible type hackery could someone do? Haskell can be fun but it's always going to look like a somewhat more practical research language to me.
  • hardwaresofton 8y ago
    > I think the large amount of effort the Rust community puts into explaining what they're doing with their type system, making it a first-class feature that's included in standard tutorials and having a lot of ergonomic effort put into error messages, is actually essential to making it work for ordinary users. (And even then, just barely; fighting the borrow checker is a thing.) 100% agree -- they've learned a lot from other languages and have padded their steep learning curve (due to the ownership/borrowing scheme and advanced type system), and it's done wonders for them. I spend a lot of my time these days trying to decide between Haskell and Rust for new projects, there are seemingly a lot of people in both camps that are freely moving between these two languages because of their similarities. > A language that allows someone to build this as a library is much more scary. What other incomprehensible type hackery could someone do? Haskell can be fun but it's always going to look like a somewhat more practical research language to me. I think it's a bit more than a library (many of the things in the original post and in linear types require deeper changes), and a ton of these features require extensions to GHC (via language extension pragmas in the source file), but I do agree, the type trickery involved is intense. In my opinion type-level hackery in haskell is not the same as when you do crazy class hierarchies/patterns in other languages (let's say Java) -- for a few reasons: - Haskell is pretty darn legible, for example, servant[0] is a library that lets you express an API as a type. It does a lot at the type level with advanced techniques, but here's an example of an API: type TodoAPI = "todos" :> Get '[JSON] [WithUUID Task] :<|> "todos" :> Capture "uuid" UUID :> Get '[JSON] (WithUUID Task) :<|> "todos" :> Capture "uuid" UUID :> ReqBody '[JSON] (Partial TaskF) :> Patch '[JSON] (WithUUID Task) :<|> "todos" :> Capture "uuid" UUID :> Delete '[JSON] (WithUUID Task) :<|> "todos" :> ReqBody '[JSON] Task :> Post '[JSON] (WithUUID Task) Despite the fancy type level trickery that servant is doing under the covers this is impressively readable. In many instances the advanced type stuff (like `Partial t`, `WithUUID t`, `Capture "uuid" UUID`) actually helps the code be easier to understand, but doesn't detract from readability. - You can step up the levels of expressiveness on your own terms -- the simpler way to write things is always right next to the more complicated way, and you can choose to push more into the type level when you choose. Example: data Task = Task { tName :: TaskName , tDesc :: TaskDesc , tState :: TaskStateValue } deriving (Eq, Show, Read, Generic) -- the "f" below can be swapped for a polymoprhic type like "Maybe" or "Identity" (which is equal to itself) -- You can think about this by literally replacing the f with the word "Maybe" everywhere you see it in the below definition, it even makes sense in the semantic english sense. data TaskF f = TaskF { tfName :: f TaskName , tfDesc :: f TaskDesc , tfState :: f TaskStateValue } data TaskFInState (state :: TaskState) f where FinishedT :: f TaskName -> f TaskDesc -> TaskFInState 'Finished f InProgressT :: f TaskName -> f TaskDesc -> TaskFInState 'InProgress f NotStartedT :: f TaskName -> f TaskDesc -> TaskFInState 'NotStarted f -- | The case where we don't know what the state actually is -- Ex. when we pull a value from the DB, we can't be polymorphic over state with the other constructors -- but the database *has* to know what was stored forthe state. -- Once we have an UnknownStateT we can write functions that try to translate to what we expect/require and fail otherwise. UnknownStateT :: f TaskName -> f TaskDesc -> f TaskStateValue -> TaskFInState state f -- | Similar case, but for when we need to fix the state type variable to *something* SomeStateT :: f TaskName -> f TaskDesc -> f TaskStateValue -> TaskFInState 'Some f This code isn't the greatest but it's what I've been working with in a recent blog series with an in-depth guide to writing a simple rest-ish API. You can go from `Task` to `TaskF` to `TaskFInState` as you graduate, and even let these types go between each other and use the level that is required. Want to write a function that only works on fully-specified Tasks that are in a very specific state? specialize the types! fore example: `cancelTask :: TaskFInState 'InProgress Identity -> TaskFInState 'NotStarted Identity`. Just reading this signature tells you important information about the function. More on-topic, the "hello world" program for a dependently typed language is usually length-typed vectors (i.e. `Vector Int 5` to represent a list of ints with 5 elements) -- from my experience people start trying to get more sophisticated with types when they see cool advanced type trickery that they think would be useful, and start doing the reading/trudging uphill to figure it out. This probably is a bit difficult for new developers thrust into a codebase with tricks they don't understand, but again the legibility of haskell code and the clarity provided by type signatures and the syntax helps.
• jcelerier 8y ago
  > For example I'd argue that when people when people first hear "enum", what they really want is a sum type I'll be honest, I'm pretty sure the first time I header "enum" I had exactly 0 idea of what it would be, so it can be whatever the language designer wants, it will always work out for someone.
• atilaneves 8y ago
  > Haskell is simple That it might be, but it sure as hell isn't easy. Brainfuck is simple, but nobody would choose to write a real project in it. Most programmers struggle trying to understand what a monad is. That's not easy. The free monad is not easy. Monad transformers are not easy. Understanding foldable/traversable/arrows/applicate is not east. Lens is/are not easy. I have personally worked with dozens of programmers that would never be able to write "proper" Haskell.
  • hardwaresofton 8y ago
    Comparing Haskell to brainfuck is a little hyperbolic -- you do not have fully understand Monads and their underpinnings to be productive in Haskell. Just like when new programmers write "public static void main" and have no idea what it does, or how JAR files work, or how cout works, newbies can type `do` and get off and running. In Haskell most of your time is spent writing non-monadic code -- writing pure functions that don't care about the outside world. Another important distinction I want to draw is that while you're that Haskell isn't easy, the difficulty contained within is fundamental to computation itself. Haskell uses it's type system to buddy-up with category theory which is considered a dual to typed lambda calculus[0]. There are spooky (to me at least, less so to actual mathematicians) natural equivalencies here in that there are certain things you can talk about at the level of Haskell types (category theory) that are universal, and since we're talking about computation, they start becoming universal truths about computations. This is a powerful concept because it changes the way you think about problems. Regardless of whether it's useful in your day job (which might be plumbing two RESTful APIs together) -- I'm not trying to convince anyone to use haskell for everything (you should use the right tool for the job given the constraints), I'm trying to encourage people to try it at least once to see the difference. Haskell in my mind offers a step stool to understand the deeper theory/mathematics underpinning of computation as a whole, by providing a language that can essentially do both -- express complex concepts and actually do useful things -- it's somewhere on the opposite end of the spectrum from assembly, but not as far as a pen and paper/chalkboard/your mind. To follow on the point above, all the concepts you're discussing as hard are what we're building in other languages -- the other languages are just giving us versions of the power/expressiveness with corners cut for ergonomics sake, or in the worst cases, drastically reduced power. There is a tradeoff, and it obviously does not always make sense to use Haskell's version of some abstraction, if you do not understand it or it takes you 5x as long to code up. That said, knowing the underlying concepts that underpin these things is the kind of knowledge you can take from project to project -- concepts like traversable show up in file/folder walking, graph traversal, all these problems that you might think were not generically solvable if you only ever dealt with libraries that worked at the lower level (as in one library for walking graphs and the other for walking the filesystem). You're right that understanding the concepts isn't easy, but this is the best kind of understanding to struggle and overcome -- it's fundamental to the field itself. No one is going to come up with a new Monad/Foldable/Traversable tomorrow, they can generally at best discover new concepts. > I have personally worked with dozens of programmers that would never be able to write "proper" Haskell. As long as these programmers learn the paradigms I don't care, use another language that's easier to write. The problem is that you can happily write language x for years and never scratch the surface of these deeper truths/paradigms/approaches, but that doesn't mean it's a good idea for your own personal development as a developer/computer scientist/whatever else. If you don't see value in exploring different, likely fundamental ways of thinking about computing then you do you. Maybe it's just me, but I see value in languages that expand the way I think -- just like that aha moment when I figured out how to use map/filter/reduce instead of writing for loops. I learned to think in transformations, one step abstracted from the imperative reality. Haskell may not be for everyone, but the paradigms it exposes are for all computer scientists (as far as I can tell anyway), and thus software developers/engineers who want to work smarter and not harder. [0]: https://math.stackexchange.com/questions/589311/lambda-calculus-and-category-theory https://math.stackexchange.com/questions/589311/lambda-calcu...
• hardwaresofton 8y ago
  Just realized the list is messed up... - non-nullable + option types - function composition (a bunch of languages get stuck in the filter/map phase but never get to the) - typeclasses + data types over classes + interfaces/abstract classes - pattern matching - Monads - The Free(R) Monad and attempts to make programs more like state machines and encode it at the type level