Why I never finish my Haskell programs • Hacker News Board

Re: Why I never finish my Haskell programs

#211

Post by geogeim » Wed, Sep 05, 2018, 12:55 AM UTC

abecedarius wrote: post #42

ainar-g wrote: post #8

>I ought to be able to generalize this I've never understood this. Unless you write a library that you plan to publish, or already have actual cases where you need a more general solution, why spending time trying to generalise code instead of switching to the next task?

If you spend some fraction of each task reflecting on how you could've written it 'better', then over time you'll learn to write more of your code 'better' from the start. (You could say making it more general is not always better, and that's true. But it is a win often enough to make it a skill worth cultivating.)

What (non-abstract) client would want you to do this in their own project? Sure, he'll want the people who spent (wasted?) their own time doing this but would categorize you as a non-professional time waster if you do this out of their own pocket and would probably fire you after too many strolls in the 'abstract' realm

Re: Why I never finish my Haskell programs

#212

Post by AlexCoventry » Wed, Sep 05, 2018, 6:17 AM UTC

l0b0 wrote: post #195

AlexCoventry wrote: post #167

Earlier quoted context omitted.

There needs to be a balance. You should choose an architecture which will accommodate predictable future needs without too much refactoring. A suite of unit tests can't help you much if you need to unmangle a bunch of severe abstraction violations between what you now need to be well-encapsulated components.

Actual red-green-refactor TDD results in the simplest possible code to solve a problem, IME. Over- or under-abstraction tends to be pretty well instantly recognizable when working with a well written test suite, and can then be easily and safely refactored away.

The simplest possible code for the current test suite is not always strategic.

Re: Why I never finish my Haskell programs

#213

Post by gmueckl » Wed, Sep 05, 2018, 9:39 AM UTC

slx26 wrote: post #172

gmueckl wrote: post #161

Earlier quoted context omitted.

It takes experience to get a sense of where to spend that time. There are parts in any project that are write only fluff that will not be changed or extended much once written. Then there are the others where you know that things will need to grow and change a lot. There, it is incredibly important to find a good starting point fron which the code can grow with as little pain as possible. A day or two to find the rig…

how to build the foundations of an everchanging building in an everchanging environment. not specifically directed to the parent comment, but it lead me to write this: I think the discussion here is too focused on business/productivity. I feel like different people have different approaches to coding. Some of us really need to write beautiful code, and we are ok with "wasting" a lot of time thinking about fluff until…

I like playing with ideas and code as much as the next guy. But I have this distinction between things I do to learn and things I do to create results useful for others. For the later I need to find efficient ways to create what I need to create or I will take too long and the need is gone and my time is wasted.

Ultimately I want to be able to tell the world that my work had a positive impact in some form. I do not want to be the guy who did useless things. This is my main motivation these days.

Re: Why I never finish my Haskell programs

#214

Post by snaky » Wed, Sep 05, 2018, 12:26 PM UTC

codebje wrote: post #88

zengid wrote: post #79

Earlier quoted context omitted.

I think Rich Hickey described it pretty well when he said (paraphrasing from [0]) that static languages present the programmer with neat little puzzles to solve that feels like we're writing applications but we're just creating intricate types and abstractions. I think he has a point, but I certainly don't want to give up the benefits of static languages, like being able to catch all of my silly errors. [0] https://y…

His argument begs the question. If you pre-suppose that describing types and finding appropriate abstractions aren't "writing applications", that is, they offer no value in the process, then spending time doing them is of course solving neat little puzzles to no benefit. On the other hand, if you pre-suppose that types and abstractions offer some value to the process of writing an application, then solving those puzz…

And most often the most beneficial is to spend more time on the problem and its domain, brilliantly illustrated in this comment https://news.ycombinator.com/item?id=17906700

Re: Why I never finish my Haskell programs

#215

Post by jlebar » Wed, Sep 05, 2018, 4:51 PM UTC

desdiv wrote: post #152

jlebar wrote: post #106

I am not a Haskell programmer, but is this correct? (Poly a) + (Poly b) = Poly $ addup a b where addup [] b = b addup a [] = a addup (a:as) (b:bs) = (a+b):(addup as bs) Imagine a simple example, adding `x+2` and `10`. In OP's representation, these would be represented as the lists [1, 2] and [10]. That is, the first element is the coefficient of the term of highest degree. But doesn't this implementation add list ele…

You're misreading OP's representation: > The polynomial x^3 −3x +1 is represented as Poly [1, -3, 0, 1] It starts with the 0th coefficient and goes up. So adding `x+2` and `10` would be zip-adding lists [2,1] and [10,0].

>> The polynomial x^3 −3x +1 is represented as Poly [1, -3, 0, 1]

> It starts with the 0th coefficient and goes up.

Is a list in Haskell canonically written in the opposite order of what I expect? I expect that the 0'th element of the list [a, b, c] is `a`. In Haskell, is it `c`? Assuming `a` is the 0th element, then the coefficient for the highest-degree term is the 0th element of the Poly. And since the degree of the two polynomials doesn't necessarily match, matching up the two highest-degree coefficients and adding them is obviously wrong.

Or am I going crazy here?

Re: Why I never finish my Haskell programs

#216

Post by abecedarius » Wed, Sep 05, 2018, 6:24 PM UTC

geogeim wrote: post #211

abecedarius wrote: post #42

Earlier quoted context omitted.

If you spend some fraction of each task reflecting on how you could've written it 'better', then over time you'll learn to write more of your code 'better' from the start. (You could say making it more general is not always better, and that's true. But it is a win often enough to make it a skill worth cultivating.)

What (non-abstract) client would want you to do this in their own project? Sure, he'll want the people who spent (wasted?) their own time doing this but would categorize you as a non-professional time waster if you do this out of their own pocket and would probably fire you after too many strolls in the 'abstract' realm

Good thing my employers were more enlightened. This is a matter for negotiation like anything else, and depending on timescales may be in the employer's narrow interest.

Re: Why I never finish my Haskell programs

#217

Post by KirinDave » Wed, Sep 05, 2018, 11:13 PM UTC

sdegutis wrote: post #204

KirinDave wrote: post #134

Earlier quoted context omitted.

I agree lazy file I/O can be dangerous and needs to vanish, but I'm not sure this counts as an "algorithmic" complaint, which is what I was really curious about. I also don't think you need Conduit or Pipes or any other performance destroying free Monad libraries to deal with it. My hot take: Conduit is in fact awful and radically overused and multiple superior options exist.

By saying "algorithmic," I used the wrong word. Lazy IO is a great example of what I meant.

I totally agree the prelude is full of cruft and needs to be scraped and redone fully. But the data structures libraries are all really good and if we could just pull in the succinct and unordered stuff, it's gone some of the best data structures a standard library can ask for.

Re: Why I never finish my Haskell programs

#218

Post by dan-robertson » Thu, Sep 06, 2018, 12:02 AM UTC

vmchale wrote: post #114

rossdavidh wrote: post #82

I've seen this, and I've never had a Haskell gig. One of the best pieces of advice I ever got re: programming was, "don't write the abstraction until you've written three cases first". This is good advice in the intended way (you will write the abstraction better when you get to it), but even better because you probably often won't ever write three of the thing in question, in which case you shouldn't write the abstr…

> One of the best pieces of advice I ever got re: programming was, "don't write the abstraction until you've written three cases first". This is good advice in the intended way (you will write the abstraction better when you get to it), I don't think this is good advice in the context of Haskell. Haskell allows some abstractions that aren't just "black boxes" or glorified templates. It's of kind like elementary logic…

I half agree with you. I think the “abstraction” your parent is talking about would correspond to typeclasses rather than polymorphic functions. That is, I think that this would be a reasonable type for a function even if it is only called once:

  Eq a => a -> MyObj a -> Maybe Foo

Whereas I think the following would not be ok (probably even if you had a lot of instances)

  class HasFoo o where
    getFoo :: Eq a => a -> o -> Maybe Foo
  
  instance HasFoo MyObj where ...

I think the rule should be that one should write the most general code that minimises the entropy/size of the source code. That way one can prefer polymorphic functions (as they need less type-signature entropy and bytes, unless they have loads of constraints, in which case one should consider wrapping those constraints together), while still preferring not making crazy single-instance typeclasses.

Re: Why I never finish my Haskell programs

#219

Post by yogthos » Thu, Sep 06, 2018, 12:05 AM UTC

pka wrote: post #205

yogthos wrote: post #107

Earlier quoted context omitted.

I find that the Haskell community is very friendly as long as you buy into their approach to solving problems. However, my experience is that if you question the effectiveness of static typing, or ask for evidence in support of the claimed benefits you'll get a very hostile reaction. The comment above where pka snidely claims that using any alternative to types amounts to yolo is quite representative. He outright dis…

> However, my experience is that if you question the effectiveness of static typing, or ask for evidence in support of the claimed benefits you'll get a very hostile reaction. That's an interesting thing to say, seeing how representative figures of (specifically) the Clojure community get really defensive really quickly once somebody questions the effectiveness of dynamic typing - which I specifically didn't do. > He…

I'm not really sure what you're referring to by people getting defensive to be honest. People are just telling you that their experiences don't match yours.

You've already conceded that your solution is not appropriate for production, yet you keep saying the claim is incorrect. You can't have it both ways I'm afraid, and it's the definition of being defensive. You can't even acknowledge that your preferred approach to dealing with side effects has any drawbacks to it.

Meanwhile, the opposite of what you're claiming is the case in practice. Other languages allow you to use monads to encode side effects if you wanted to, but Haskell is the language that doesn't give you other options.

Re: Why I never finish my Haskell programs

#220

Post by pka » Thu, Sep 06, 2018, 3:18 AM UTC

yogthos wrote: post #219

pka wrote: post #205

Earlier quoted context omitted.

> However, my experience is that if you question the effectiveness of static typing, or ask for evidence in support of the claimed benefits you'll get a very hostile reaction. That's an interesting thing to say, seeing how representative figures of (specifically) the Clojure community get really defensive really quickly once somebody questions the effectiveness of dynamic typing - which I specifically didn't do. > He…

I'm not really sure what you're referring to by people getting defensive to be honest. People are just telling you that their experiences don't match yours. You've already conceded that your solution is not appropriate for production, yet you keep saying the claim is incorrect. You can't have it both ways I'm afraid, and it's the definition of being defensive. You can't even acknowledge that your preferred approach t…

> You've already conceded that your solution is not appropriate for production

I’ve done no such thing.

> You can't even acknowledge that your preferred approach to dealing with side effects has any drawbacks to it.

It does, probably not the drawbacks you think of though (“conceptual overhead of types”?).

Generally, you seem to be awfully incompetent in a language you claim to have used for a year. That’s not a bad thing, but you don’t present your arguments with a big fat disclaimer stating that. If you did, I think there would be much less tension in these kind of discussions.