Kind of agree with refactoring with python. While prototype building was easier with python, I used to have lot of changes and always has this nagging problem that something is not right.
Becoming Productive in Haskell
21–30 of 213 posts
Re: Becoming Productive in Haskell
#22> Composing functions out of other, smaller functions offers a big reduction in complexity. If they’re named well, this allows you to write functions that are easy to read.
there are only two problems in CS, cache invalidation and naming things - phil karlton
Re: Becoming Productive in Haskell
#23Whenever I try to be productive in Haskell I end up taking the research phase too far and end up over-my-head in category theory that I don't understand. I'm never productive in Haskell.
Re: Becoming Productive in Haskell
#24I don't think I have ever used a haskell program written by someone else that wasn't ghc. Is that usual? Are there now a bunch of .debs for useful things other than writing haskell that are actually written in Haskell? I'm not trolling, it's just a good test of what something is useful for when it's been around a while is to ask "Well, what has it actually been used for?"
I daily use Xmonad, hledger and sometimes pandoc.
pandoc is probably the one I see discussed the most without people knowing it's written in haskell.
Re: Becoming Productive in Haskell
#25Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination.
While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?" It let's you recognize and apply common patterns and implement them in abstract ways without having to think about what kind of values you actually have at runtime. In that way Haskell is the most powerful language I know.
Have a tree/list/whatever? Need to apply a function to each of the elements? Make your tree/list/whatever an instance of the Functor type class and you're done. Need to accumulate a result from all the elements? Make it foldable.
Something depends on some state? Make it a Monad.
You either get a result or you don't (in which case any further computations shouldn't apply)? Use the Maybe Monad.
You need to compute different possible results? Use the List Monad.
Need to distinguish three different possible values that are different compositions of elementary types? Make yourself your own type and pattern match the behavior of applying functions.
Need to output in a certain way? Make it an instance of the Show class.
Most concepts that are used every day have some kind of idea behind them that is abstract and implementation independent. Haskell kind of forces you to reference those ideas directly. The downside is that you actually have to know about those concepts. However, knowing about the such concepts makes you also a better programmer in other languages, so it's not like it's a bad thing.
Re: Becoming Productive in Haskell
#26I don't think I have ever used a haskell program written by someone else that wasn't ghc. Is that usual? Are there now a bunch of .debs for useful things other than writing haskell that are actually written in Haskell? I'm not trolling, it's just a good test of what something is useful for when it's been around a while is to ask "Well, what has it actually been used for?"
For what we have learnt from the history of mathematics, you might have to give it some hundred years before people realize usefulness. As a practical note, the fact that educated people use it is an indicator that it is useful.
> As a practical note, the fact that educated people use it is an indicator that it is useful.
Possibly. It could also be that they use it because it's interesting and informative rather than useful per se.
It could also be that it's useful in particular contexts in the same way that Feynman diagrams are useful.
Re: Becoming Productive in Haskell
#27I don't think I have ever used a haskell program written by someone else that wasn't ghc. Is that usual? Are there now a bunch of .debs for useful things other than writing haskell that are actually written in Haskell? I'm not trolling, it's just a good test of what something is useful for when it's been around a while is to ask "Well, what has it actually been used for?"
ShellCheck [0] is actually a pretty useful tool.
Re: Becoming Productive in Haskell
#28> So, I started calling it Mappable. Mappable was easy for me to remember and was descriptive of what it did. A list is a Functor. A list is Mappable. I wish there was a language or library that was willing to take the Haskell functionality and just give it all names like this.
A fork of Haskell with descriptive names and operators could be really popular, I think.
Actually wouldn't be a fork. It's just an alternative Prelude library. People do this occasionally. The result tends to be idiosyncratic.
Re: Becoming Productive in Haskell
#29Whenever I try to be productive in Haskell I end up taking the research phase too far and end up over-my-head in category theory that I don't understand. I'm never productive in Haskell.
You might not be productive in the traditional sense of "delivering business value". However over the years of letting Haskell change my brain a little piece at a time, the results have accumulated. I wouldn't swap that deeper understanding for all the productivity in the world. :-)
Re: Becoming Productive in Haskell
#30Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…
IIRC, the Show class is supposed to be the reverse of the Read class -- so you should not use it to pretty print stuff.