5 ms·

So if somebody asserted that INTERCAL-72 is the proper language to use for production code, you would consider it unfair to contradict them until you've used IN

So if somebody asserted that INTERCAL-72 is the proper language to use for production code, you would consider it unfair to contradict them until you've used INTERCAL in production code yourself? Personally, I would not necessarily disbelieve somewhat propagating Haskell as a production ready language. However, I'm fairly confident that it would be thoroughly unsuited to any areas of work I regularly operate in. I have tried a number of times to learn Haskell (from a variety of tutorials and text books). I find myself nodding along sympathetically at the fundamentals (functional purity, non-strict evaluation). I can follow the initial chapters. And somewhere between "Functor" and "Applicative", I tend to lose the plot. Then I look at supposedly real world code like the URL shortener in Allen/Moronuki's "Haskell Programming from First Principles", and I just can't make heads or tails of it: https://github.com/bitemyapp/shawty-prime/blob/master/app/Main.hs https://github.com/bitemyapp/shawty-prime/blob/master/app/Ma... app :: R.Connection -> ScottyM () app rConn = do get "/" $ do uri <- param "uri" let parsedUri :: Maybe URI parsedUri = parseURI (TL.unpack uri) case parsedUri of Just _ -> do shawty <- liftIO shortyGen let shorty = BC.pack shawty uri' = encodeUtf8 (TL.toStrict uri) resp <- liftIO (saveURI rConn shorty uri') html (shortyCreated resp shawty) Nothing -> text (shortyAintUri uri) If that's supposed to be the way to write production code in the future, count me out!

whateveracct 7y ago
What exactly is wrong with it? I've never even used the Scotty library or monad being used and I can understand it.
- microtherion 7y ago
  1. I have a vague idea what the second "do" is for. I don't have the slightest idea what the first "do" does. 2. I have some idea what "$" is, but I have no idea what it does in this context. 3. param "uri" is presumably extracting a parameter, presumably from the result of an incoming HTTP request. How is that request passed into "app"? How is it passed into the "get"? How is it passed to "param"? 4. Why does "parsedURI" need a type signature? 5. "Just/Nothing" more or less makes sense, but "Left/Right" (used outside the excerpt I quoted) is a notation that makes about as much sense to communicate meaning as "car/cdr" does in Lisp. 6. A response is generated. How does that response get back to the client? 7. What does liftIO do? 8. The overall syntax is just a pile of wrongness. There are left pointing arrows and right pointing arrows, which have completely different (and entirely non-symmetric) functions. There is an equals sign, which has a somewhat similar role to a left pointing arrow, but for some reason needs a completely different operator. There is a right pointing arrow in the function signature which is completely unrelated to the arrow in the case statement. There is an empty pair of parentheses doing Curry knows what. There are return values, which you can identify by following the peaks and valleys of the indentation. So, TL;DR, this is an incomprehensible control and data flow, wrapped in an ugly syntax.
  - whateveracct 7y ago
    Look, I sympathize with you because Haskell is not easy to learn by any means so I understand someone not liking it. If I get time later I'll go item-by-item and explain. There's a lot of questions there but it's actually just a few fundamental concepts. But I've seen engineers with only C/C++ experience get onboarded and write code with the same concepts & more complicated ones as the link shortener above. The key was onboarding by someone who knew Haskell well. Haskell companies need a culture of learning _and_ teaching to truly thrive and counteract downsides of the language like hiring pool and learning curve.
  - wolco 7y ago
    Could be a fun game. I'll guess. No haskell knowledge. PHP background. 1. Connect to remote connection. DO - wait.. 2. $ Loop-over 3. It comes from a config file with a hardcoded value and is globally included 4. Because it could be reused to handle a different types. 6. Text is printing to standard output. 7. Creating and Repointing the response to the resp var
  - phlakaton 7y ago
    At the risk of proving your point (this part of the code is indeed a bit of a hash), but in the hope that this will help a little with learning, here are some answers: 1. The first do in your snippet does nothing - it's redundant. In the actual code you linked, though, it sequences the `get "/" ...` and the `get "/:short" ...` expressions into a single application initializer. When the app starts up (i.e. when `app` is called), this outer "do" runs through your endpoint-defining expressions and registers each endpoint in turn with the HTTP server. 2. That `get` function takes two arguments: the URI pattern and the action to run if the pattern matches. The whole rest of your snippet _is_ the second argument! Because of the low precedence of the "$" operator, using "$" means you don't have to enclose all that code in parentheses. It is a tiny bit of syntactic sugar that is wildly popular in Haskell-land because Heaven forfend any of your code ends up looking like LISP. ;-) 3. The answer is in the monad being used in this case to sequence these steps together (`ActionT Text IO <some return type>`). Think of `param "uri"` not as an expression returning a string, but a partially-constructed function that takes an HTTP request as an additional argument. The monad takes care of threading the request into this function when the request is actually handled, and `uri` will be bound to the resulting value. 4. I'm guessing it doesn't. Many type signatures in Haskell are optional, and are added if either 1) there's a genuine ambiguity in the code that needs to be clarified, 2) the author thinks it will make things clearer, or 3) the author hit a bug where the compiler inferred some crazy generic type that the author didn't intend or understand, and they put in some type signatures as sanity checks and constraints on what type is actually expected.
tome 7y ago
This is roughly the same structure as the code you’d write in Python flask. There’s nothing unusual about it beyond Haskell’s syntax.
mbrodersen 7y ago
> If that's supposed to be the way to write production code in the future, count me out! Eh? Sorry but the code is really clear to me? Which parts do you find difficult to read?
dragonwriter 7y ago
The only thing I see bad about that code is some bad variable naming, especially shorty/shawty, and possibly a couple bits of needless and unhelpful verbosity. Neither are inherent to Haskell.

whateveracct 7y ago

What exactly is wrong with it? I've never even used the Scotty library or monad being used and I can understand it.

microtherion 7y ago
1. I have a vague idea what the second "do" is for. I don't have the slightest idea what the first "do" does. 2. I have some idea what "$" is, but I have no idea what it does in this context. 3. param "uri" is presumably extracting a parameter, presumably from the result of an incoming HTTP request. How is that request passed into "app"? How is it passed into the "get"? How is it passed to "param"? 4. Why does "parsedURI" need a type signature? 5. "Just/Nothing" more or less makes sense, but "Left/Right" (used outside the excerpt I quoted) is a notation that makes about as much sense to communicate meaning as "car/cdr" does in Lisp. 6. A response is generated. How does that response get back to the client? 7. What does liftIO do? 8. The overall syntax is just a pile of wrongness. There are left pointing arrows and right pointing arrows, which have completely different (and entirely non-symmetric) functions. There is an equals sign, which has a somewhat similar role to a left pointing arrow, but for some reason needs a completely different operator. There is a right pointing arrow in the function signature which is completely unrelated to the arrow in the case statement. There is an empty pair of parentheses doing Curry knows what. There are return values, which you can identify by following the peaks and valleys of the indentation. So, TL;DR, this is an incomprehensible control and data flow, wrapped in an ugly syntax.
- whateveracct 7y ago
  Look, I sympathize with you because Haskell is not easy to learn by any means so I understand someone not liking it. If I get time later I'll go item-by-item and explain. There's a lot of questions there but it's actually just a few fundamental concepts. But I've seen engineers with only C/C++ experience get onboarded and write code with the same concepts & more complicated ones as the link shortener above. The key was onboarding by someone who knew Haskell well. Haskell companies need a culture of learning _and_ teaching to truly thrive and counteract downsides of the language like hiring pool and learning curve.
- wolco 7y ago
  Could be a fun game. I'll guess. No haskell knowledge. PHP background. 1. Connect to remote connection. DO - wait.. 2. $ Loop-over 3. It comes from a config file with a hardcoded value and is globally included 4. Because it could be reused to handle a different types. 6. Text is printing to standard output. 7. Creating and Repointing the response to the resp var
- phlakaton 7y ago
  At the risk of proving your point (this part of the code is indeed a bit of a hash), but in the hope that this will help a little with learning, here are some answers: 1. The first do in your snippet does nothing - it's redundant. In the actual code you linked, though, it sequences the `get "/" ...` and the `get "/:short" ...` expressions into a single application initializer. When the app starts up (i.e. when `app` is called), this outer "do" runs through your endpoint-defining expressions and registers each endpoint in turn with the HTTP server. 2. That `get` function takes two arguments: the URI pattern and the action to run if the pattern matches. The whole rest of your snippet _is_ the second argument! Because of the low precedence of the "$" operator, using "$" means you don't have to enclose all that code in parentheses. It is a tiny bit of syntactic sugar that is wildly popular in Haskell-land because Heaven forfend any of your code ends up looking like LISP. ;-) 3. The answer is in the monad being used in this case to sequence these steps together (`ActionT Text IO <some return type>`). Think of `param "uri"` not as an expression returning a string, but a partially-constructed function that takes an HTTP request as an additional argument. The monad takes care of threading the request into this function when the request is actually handled, and `uri` will be bound to the resulting value. 4. I'm guessing it doesn't. Many type signatures in Haskell are optional, and are added if either 1) there's a genuine ambiguity in the code that needs to be clarified, 2) the author thinks it will make things clearer, or 3) the author hit a bug where the compiler inferred some crazy generic type that the author didn't intend or understand, and they put in some type signatures as sanity checks and constraints on what type is actually expected.

tome 7y ago

This is roughly the same structure as the code you’d write in Python flask. There’s nothing unusual about it beyond Haskell’s syntax.

mbrodersen 7y ago

> If that's supposed to be the way to write production code in the future, count me out! Eh? Sorry but the code is really clear to me? Which parts do you find difficult to read?

dragonwriter 7y ago

The only thing I see bad about that code is some bad variable naming, especially shorty/shawty, and possibly a couple bits of needless and unhelpful verbosity. Neither are inherent to Haskell.