3 ms·

I'm not sure I got an answer to the question in the title. Prettier is rock solid because it was based on a paper by someone who designed Haskell? That's a cool

I'm not sure I got an answer to the question in the title. Prettier is rock solid because it was based on a paper by someone who designed Haskell? That's a cool link, but I'm not sure what the insight is, is this evidence that functional programming-style algorithms lead to a more stable codebase?

itishappy 3y ago
I think prettier's initial author answered the question quite concisely in the article's first link. Title and excerpt copied below: > Dig into past research. > If you're excited about an idea, it's super tempting to sit down an immediately get going. But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely changes how I am going to solve it. https://archive.jlongster.com/How-I-Became-Better-Programmer https://archive.jlongster.com/How-I-Became-Better-Programmer
- noam_k 3y ago
  I can't agree more, and I can't disagree more. There's a great deal to be learned by experimenting yourself. My workflow is: * Learn the concept * Implement it * Research prior art * Throw away my first implementation and rewrite it properly (Edit: formatting)
  - rkangel 3y ago
    Yes - I quite often get into research paralysis where I keep looking and trying to work out the solutions to different problems I'm going to encounter and never getting started. Whereas if I start protoyping I learn a lot very quickly.
  - chubot 3y ago
    Yeah I kinda think people are always "learning from their last mistake" (and that's definitely true for me) - Sometimes you hack, and you end up with a mess. And then the lesson you learn is to study the prior art first. - Sometimes you spin your wheels reading stuff that isn't actually applicable to the problem you have. Then the lesson learned is to "do the simplest thing that could work", "solve 80% of the problem with 20% of the effort", etc. So to me, programming is really a cycle of learning, and you can't really generalize the order of doing things ... It's iterative stumbling and learning, in both orders :)
  - yard2010 3y ago
    This is the way. Unfortunately this is not going to work, not in a startup environment. You probably do everything except the throwing away and re-implementing part..
    - rob74 3y ago
      Nor in any environment where a client is paying you to develop something. Try showing them an MVP and then telling them "ok, now I know how to do this I will throw it away and redo it from the beginning". Not to mention that, with unclear and constantly changing requirements, you are unlikely to ever arrive at a point where you can say that...
  - 8n4vidtmkvmk 3y ago
    +1 I think there's something to be gained by just trying it your way first. Maybeyou'll come up with something new and insightful by not tainting your brain first, and if not, you will at least gain a deeper understanding of the problem space.

itishappy 3y ago

I think prettier's initial author answered the question quite concisely in the article's first link. Title and excerpt copied below: > Dig into past research. > If you're excited about an idea, it's super tempting to sit down an immediately get going. But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely changes how I am going to solve it. https://archive.jlongster.com/How-I-Became-Better-Programmer https://archive.jlongster.com/How-I-Became-Better-Programmer

noam_k 3y ago
I can't agree more, and I can't disagree more. There's a great deal to be learned by experimenting yourself. My workflow is: * Learn the concept * Implement it * Research prior art * Throw away my first implementation and rewrite it properly (Edit: formatting)
- rkangel 3y ago
  Yes - I quite often get into research paralysis where I keep looking and trying to work out the solutions to different problems I'm going to encounter and never getting started. Whereas if I start protoyping I learn a lot very quickly.
- chubot 3y ago
  Yeah I kinda think people are always "learning from their last mistake" (and that's definitely true for me) - Sometimes you hack, and you end up with a mess. And then the lesson you learn is to study the prior art first. - Sometimes you spin your wheels reading stuff that isn't actually applicable to the problem you have. Then the lesson learned is to "do the simplest thing that could work", "solve 80% of the problem with 20% of the effort", etc. So to me, programming is really a cycle of learning, and you can't really generalize the order of doing things ... It's iterative stumbling and learning, in both orders :)
- yard2010 3y ago
  This is the way. Unfortunately this is not going to work, not in a startup environment. You probably do everything except the throwing away and re-implementing part..
  - rob74 3y ago
    Nor in any environment where a client is paying you to develop something. Try showing them an MVP and then telling them "ok, now I know how to do this I will throw it away and redo it from the beginning". Not to mention that, with unclear and constantly changing requirements, you are unlikely to ever arrive at a point where you can say that...
- 8n4vidtmkvmk 3y ago
  +1 I think there's something to be gained by just trying it your way first. Maybeyou'll come up with something new and insightful by not tainting your brain first, and if not, you will at least gain a deeper understanding of the problem space.