5 ms·

I find the constant conversation around code style extremely tiring. I can't claim it isn't important. I do get the impression we think it is more important th

• ilyt 4y ago
  It's a tool to be used in parts where it makes sense. "Writing functional" (or any other paradigm really) code should never be a target
  • pklausler 4y ago
    The target, of course, is writing correct code. I find recursive functions over immutable values easier to prove to be correct than iterative loops over mutable storage.
    • ilyt 4y ago
      The target is frankly to get paid. Sometimes you're making a prototype. Sometimes you're making one off get some info out of data and never use it again. Provably correct app that now costs 10x and is essentially yet another CRM or CRUD app is a failure because competition already delivered theirs 2 years ago and ate your market. Go too far in another direction and you're living in house of cards with tech debt killing all velocity you had and users leaving over app having bugs or just being slow, while you're drowning in rotten spaghetti. I do think that "doing the minimum to do the job at hand" is wrong approach for near everything that will live more than two or three months, but there is definitely threshold on other side of that where you're essentially just gilding the lilly and wasting time. The key is to pick your battles, time is resource that thing that every other component of your infrastructure is going to use probably could use more of that time than random feature someone up top invented on a whim.
      • pklausler 4y ago
        I find that I can prototype most quickly when I'm not wasting time debugging, and I tend to have the fewest bugs when writing recursive functions over immutable data and the result is either going to be correct or it's not going to pass the type checker.
• agumonkey 4y ago
  It can be so. But depending on the topic it's an absolute nuclear weapon. I've seen people accumulate pages of imperative code. Side effects everywhere, no reuse of small logical bits. 80% waste, averaging 4-6h per bugfix. On the other hand short immutable code is more readable (yes even with a single letter vars), is linearly ordered, and often reusing the same combinators.
  • taeric 4y ago
    I mean, you aren't wrong. Bad code is indeed bad code. I've also seen mountains of abstractions in a "declarative" style that was just as impossible to deal with. I think I've been responsible for some of it. Edit to add: The example I used to use was to look at the imperative version of the Koch snowflake. Then look at a version that is not. Indeed, even the examples you will find in Haskell are typically reaching for a much more imperative style than typical Haskell programs.
  • UncleMeat 4y ago
    Immutable data does not necessarily let you answer the "what state does this value hold" question easier than mutable data. Imagine you've got an immutable List. x.append(blah) does not mutate x but instead it returns a new list with blah at the end. If you want to know the state of this new list, you need to know the state of x. You still chase a chain of operations to figure out what your data can look like at some program point. You get the advantage that mutation cannot be hidden inside of functions, but this is achieved just fine with "const" or whatever.
    • agumonkey 4y ago
      If your logic is about differentials then code around differentials. Which is also one value of FP. This is, IMO, what lead to timetravelling stuff like redux.
    • sodapopcan 4y ago
      But you do know absolutely for sure that you aren’t accidentally changing some other reference to x.