The more I see it in use, the more I want to learn Haskell, but I can't think of a practical reason to do so.
I don't know about you, but sometimes I do things just because I want to.
Haskell in Production
131–140 of 242 posts
Re: Haskell in Production
#132How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from On top of trying to remember that is string concatenation and >>= and <- have something to do with monads.
Operators are just functions. Learning the type system is the key. You can easily check any function's type signature in the docs once you understand how the type system works.
Or, it's worth mentioning, you can do `:t ()` in the repl to quickly get the type.
Re: Haskell in Production
#133> Haskell is great for business and great in production. Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell. If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to…
Syntax is the absolute best thing about Haskell and it's ML relatives, especially coming from C++ and Java as I did. It's succinct and very easy to read, without braces, parens and type annotations scattered everywhere. For example, defining a function is as simple as "let f x = ..x.."
The succinctness of Haskell really matters when dealing with non-trial code or types. Just compare the type signtaure of "SelectMany" in C# to an equivalent in Haskell.
Re: Haskell in Production
#134Earlier quoted context omitted.
This is opinion. Haskellers have opinions too. Whatever you like and whatever gets the job done: bravo
Nope. Not everything is "every way is just as good as the other". >Whatever you like and whatever gets the job done: bravo "The job" is this: it's an optimization problem of maximizing development throughput. That's the job in the business world, at least. There can and should be a conversation about doing this job well. Mandating strong static typing across the board is exactly what Haskell does. My claim is this is…
If it happens every time then it should be easy for you to give a small example. Please do! It’s very hard to understand what you mean otherwise.
Re: Haskell in Production
#135Earlier quoted context omitted.
Are you speaking from experience? The article is about the author’s experience from a year of using Haskell. I don’t think it’s fair or constructive to disagree with his findings unless you also have experience using the language, and it doesn’t sound like that is the case.
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 ha…
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.
Re: Haskell in Production
#136Earlier quoted context omitted.
Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. I agree that haskellers have a tendency to disregard the cost of using sophisticated typ…
> Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. This is not accurate or prove me wrong. Opting out of Haskell's type system may be "do…
astuary is not suggesting opting out of Haskell’s type system. He/she is suggesting using constructs whose interaction with the type system is straightforward.
Re: Haskell in Production
#137We are a YC company doing very well, all our back end code is written in Haskell. We have produced a lot of functionality with a relatively small team. I would say we are existence proof that Haskell is good for business.
For the problem you are solving and at your scale. Things start to change when you need to hire n+1 teams or engineers quickly.
They... might? I worked at a Haskell start-up for a bit. Hiring wasn't easy. But it doesn't seem to be easier at the mostly-JS start-up I'm working at now.
Re: Haskell in Production
#138How is such an obscure language - with associated difficulty in finding talented engineers - ever going to be a better choice than a more mainstream language, which probably has many of the same features?
Re: Haskell in Production
#139The amount of knowledge required just to have a clean design o the simplest of things, i.e. a few functions that add and delete users is very big; almost all of Haskell's important parts need to be known.
Is that good? for me, it's an obstacle. I can't expect all the developers that come and go to have a perfect understanding of monads in order to use/debug/extend such code.
And what did Haskell actually buys us here? my apologies for being skeptical, but it doesn't seem to buy us anything...in other languages, such things as creating a user, deleting a user, logging actions requires a lot less boilerplate and complexity.
Re: Haskell in Production
#140Earlier quoted context omitted.
>but what's wrong with the syntax? I'll just link to this blog about readable Haskell. If everyone followed his advise, it would be much better. http://www.haskellforall.com/2015/09/how-to-make-your-haskel...
Thanks. That's a good blog. The $ operator is definitely confusing in Haskell. F# uses print This means: Take the result of 4 * 2 and send it to `even`, then take that result and send it to `print`. Or you can write it with forward pipes to make it even clearer: 4 * 2 |> even |> print The thing about backward pipes is that they're often used to avoid parentheses, which is IMHO a good idea. It's just that thinking of…
I don't see the above better than
print(even(4*2))