4 ms·

I've read most of LYAH, and I have no problem understanding mathematical concepts, but man, Haskell people truely don't know how to convey this "awesomeness" th

I've read most of LYAH, and I have no problem understanding mathematical concepts, but man, Haskell people truely don't know how to convey this "awesomeness" they keep talking about. 1. Where do you use automatic differentiation? I've done machine learning, signal processing, etc., but never even heard of it until now. Why should I care? Your pitch should include that (especially when the wikipedia article doesn't really provide real use cases). 2. What's special about lenses? I tried reading http://www.haskellforall.com/2013/05/program-imperatively-using-haskell.html http://www.haskellforall.com/2013/05/program-imperatively-us... but there's no summary of what this is about, and from the first paragraphs it seems like a Haskell workaround for setters and immutability. Again, I feel like the community is not pitching these things correctly. People like me start reading, don't understand the point of it all, and give up. And I can go on... What is the target audience of these features (or Haskell itself)? Is it people like me, or is it more hardware validation engineers, automatic proof system developers, database people? EDIT: If anyone is interested, edwardkmett has replied to me in http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_some_killer_libraries_and_frameworks/cbm1ic6 http://www.reddit.com/r/haskell/comments/1k3fq7/what_are_som...

mjn 13y ago
Re: applications for automatic differentiation, there's a list of applications here: http://www.autodiff.org/?module=Applications http://www.autodiff.org/?module=Applications. That's a list for the approach generally though, not the Haskell version.
andolanra 13y ago
Haskell's great contributions to its users are quite often advantages conferred by the type system. A number of the libraries mentioned (e.g. ad, lens, mtl, QuickCheck, MTL, among others) are made either possible or efficient by Haskell's ability to work with static types in a sophisticated and nuanced way. Users of dynamically typed languages talk about "fighting" the type system—and yes, there can be a bit of that, espencially early on—but once you become a proficient Haskell user, you learn to use the type system and the guarantees provided you by the language to enforce properties you want to be true, and thereby effectively use the compiler as a pre-emptive, exhaustive testing mechanism for the correctness of your code. A good Haskell programmer will set up types in such a way that the logic errors of their program will be translated into type errors, so an incorrect program cannot even be compiled. So, I suppose, the target audience of Haskell is people for whom program correctness is a stronger motivation than, say, the speed gains of C/C++ or the development time increases of dynamic languages[1] or the like. (EDIT: To avoid the charge of excessive language zealotry, I should clarify that I don't think program correctness is the overriding factor in all cases, and consequently I don't think Haskell is the correct tool in all situations, as well.) [1]: I personally don't find Haskell particularly slow to develop in—in fact, I find it much faster and easier to develop in than the dynamic languages I know—but I do use it literally daily, and, to be frank, a new programmer will likely find it tricky and confusing until familiarity sets in. Similarly, Haskell can—used correctly—have spectacular performance, sometimes matching C and beating out C++, but again, it takes experience and understanding to milk the best performance out of Haskell.
tel 13y ago
Lenses begin with getting and setting. Since Haskell is immutable, setting is a little different—it's a method of quickly generating a mutation function for a type. Lenses keep getting and setting bound together as a first-class value which creates the idea of it being a value representing a "focus" on a particular field in a complex, nested value. Then you can compose these lenses together and retain these properties. You can also pick lenses which operate with different multiplicities from 0 to infinity. Finally, you can use their seemless connection to object isomorphisms to create a very general interface for working with various kinds of "similar" objects in Haskell. At the end of the day you can write a first-class lens which represents getting and setting over a set of parameterized Map keys deeply inside of a stateful computation, mapping over anything that looks like a string, and viewing/modifying it as decoded JSON. obj . ix "aKey" . each . _Object . ix "3" . _Number .~ 4 might modify a record in a type like this IsString s => SomeState { obj :: Map s s } where the string values of the Map have a JSON schema like {"1" ..., "2" ..., "3": <aNumber> }
- bjourne 13y ago
  But you haven't presented anything that is special about lenses. For example, your lens expression would be trivially translated to this Python: for o in obj["aKey"]: o["3"] = 4 The OP:s point was that lenses seem like a workaround for Haskell's lack of mutable state. EDIT: What I'm meaning is that to show lenses unique benefits, you would have to come up with an example in which the code is more succinct than the equivalent code implemented without lenses in another language.
  - tel 13y ago
    But, that isn't anything resembling a faithful translation. It's non-first class, non compositional, only a "setter", lacks a decent error handling code (I didn't mention that, but it's built into "mistargeted" lenses) and depends upon parsing the JSON in some other step. Lenses let you think of a JSON-encoded string as an actual JSON string without ever explicitly doing the decoding due to their close connection to Isomorphisms and "partial Isomorphisms" (called, non-standardly, Prisms here). Furthermore, lenses don't really have anything to do with mutable state—they just happened to form a convenient wrapper for using the State monad, but that's really a coincidence. Succinctness is difficult to grasp. It'd be a good exercise that I'm not going to try in an HN comment to even translate the entirety of the concept embedded in that one line into, say, Python. It would start to feel like an XPath implementation. (Edit: Also, as usual, the whole typesafe thing. That Python fragment can lead to runtime errors. The Haskell one never does—using it inappropriately is simply impossible.)

mjn 13y ago

Re: applications for automatic differentiation, there's a list of applications here: http://www.autodiff.org/?module=Applications http://www.autodiff.org/?module=Applications. That's a list for the approach generally though, not the Haskell version.

andolanra 13y ago

Haskell's great contributions to its users are quite often advantages conferred by the type system. A number of the libraries mentioned (e.g. ad, lens, mtl, QuickCheck, MTL, among others) are made either possible or efficient by Haskell's ability to work with static types in a sophisticated and nuanced way. Users of dynamically typed languages talk about "fighting" the type system—and yes, there can be a bit of that, espencially early on—but once you become a proficient Haskell user, you learn to use the type system and the guarantees provided you by the language to enforce properties you want to be true, and thereby effectively use the compiler as a pre-emptive, exhaustive testing mechanism for the correctness of your code. A good Haskell programmer will set up types in such a way that the logic errors of their program will be translated into type errors, so an incorrect program cannot even be compiled. So, I suppose, the target audience of Haskell is people for whom program correctness is a stronger motivation than, say, the speed gains of C/C++ or the development time increases of dynamic languages[1] or the like. (EDIT: To avoid the charge of excessive language zealotry, I should clarify that I don't think program correctness is the overriding factor in all cases, and consequently I don't think Haskell is the correct tool in all situations, as well.) [1]: I personally don't find Haskell particularly slow to develop in—in fact, I find it much faster and easier to develop in than the dynamic languages I know—but I do use it literally daily, and, to be frank, a new programmer will likely find it tricky and confusing until familiarity sets in. Similarly, Haskell can—used correctly—have spectacular performance, sometimes matching C and beating out C++, but again, it takes experience and understanding to milk the best performance out of Haskell.

tel 13y ago

Lenses begin with getting and setting. Since Haskell is immutable, setting is a little different—it's a method of quickly generating a mutation function for a type. Lenses keep getting and setting bound together as a first-class value which creates the idea of it being a value representing a "focus" on a particular field in a complex, nested value. Then you can compose these lenses together and retain these properties. You can also pick lenses which operate with different multiplicities from 0 to infinity. Finally, you can use their seemless connection to object isomorphisms to create a very general interface for working with various kinds of "similar" objects in Haskell. At the end of the day you can write a first-class lens which represents getting and setting over a set of parameterized Map keys deeply inside of a stateful computation, mapping over anything that looks like a string, and viewing/modifying it as decoded JSON. obj . ix "aKey" . each . _Object . ix "3" . _Number .~ 4 might modify a record in a type like this IsString s => SomeState { obj :: Map s s } where the string values of the Map have a JSON schema like {"1" ..., "2" ..., "3": <aNumber> }

bjourne 13y ago
But you haven't presented anything that is special about lenses. For example, your lens expression would be trivially translated to this Python: for o in obj["aKey"]: o["3"] = 4 The OP:s point was that lenses seem like a workaround for Haskell's lack of mutable state. EDIT: What I'm meaning is that to show lenses unique benefits, you would have to come up with an example in which the code is more succinct than the equivalent code implemented without lenses in another language.
- tel 13y ago
  But, that isn't anything resembling a faithful translation. It's non-first class, non compositional, only a "setter", lacks a decent error handling code (I didn't mention that, but it's built into "mistargeted" lenses) and depends upon parsing the JSON in some other step. Lenses let you think of a JSON-encoded string as an actual JSON string without ever explicitly doing the decoding due to their close connection to Isomorphisms and "partial Isomorphisms" (called, non-standardly, Prisms here). Furthermore, lenses don't really have anything to do with mutable state—they just happened to form a convenient wrapper for using the State monad, but that's really a coincidence. Succinctness is difficult to grasp. It'd be a good exercise that I'm not going to try in an HN comment to even translate the entirety of the concept embedded in that one line into, say, Python. It would start to feel like an XPath implementation. (Edit: Also, as usual, the whole typesafe thing. That Python fragment can lead to runtime errors. The Haskell one never does—using it inappropriately is simply impossible.)