6 ms·

My impression is that there are various, even contradicting understandings and opinions in the wild what "worse is better" actually means. Rarely do people who

My impression is that there are various, even contradicting understandings and opinions in the wild what "worse is better" actually means. Rarely do people who interpret it in a cynical way demonstrate a good understanding of the total set of qualities that matter for the success of a technology. If you think LISP or Haskell are without flaws (despite all the years of hype), then... you're wrong.

lisper 7y ago
It's not that they are without flaws, it's that it is a lot easier to fix/ignore/work-around the flaws than in other languages, where the flaws are unchangeable (except by the standards committee) and constantly in your face.
- jstimpfle 7y ago
  hear, hear.
- ncmncm 7y ago
  No. You are just used to your flaws, and not used to theirs; and have learned not to complain about yours, but complaints about theirs are welcomed in your circle. In other words: other systems really are crap, but so is yours, really, but we all get our stuff done, despite it all. Sometimes things get better (Moore's law has forgiven all manner of evil) and sometimes they get worse (Java).
  - lisper 7y ago
    > You are just used to your flaws, and not used to theirs This is a testable theory: name me a flaw in Common Lisp that cannot easily be worked around. I'll bet that for any flaw you name, I'll be able to show you an easy way to work around it.
    - jstimpfle 7y ago
      Of course you will be able to give a brittle, half-assed work around for any issue that someone throws at you. But you know, not all people are obsessed with LISP, not all people are ok with half-assed workarounds. I think you are being very dishonest to yourself if you think that LISP is universally the best just because you can theoretically turn it into anything. You can't, really. Good tooling matters. Error messages matter. Standardization matters. Syntax matters (to some extent). Mindshare matters (a lot). There's a lot of subtle qualities that you can't just fake. When I write performance sensitive code I'll personally just pick C. I'm sure there's a Common Lisp solution available to specify machine types and compile efficient code. (Probably there's many, which is another problem). But what's the point in putting lipstick on a pig when I can just use the real deal that works perfectly for what I'm doing?
      - lisper 7y ago
        "Half-assed" is in the eye of the beholder. If you appoint yourself as the ultimate arbiter of half-assedness then your position becomes unfalsifiable. But I think you might be surprised at how un-half-assed these things can be.
        jstimpfle 7y ago
        > But I think you might be surprised at how un-half-assed these things can be. You might be surprised how little I care, because I'll just use a solid, battle-tested tool instead. Are you suggesting we should rewrite compression or imaging or ... software in Common Lisp because it will be so much better?
        lisper 7y ago
        > You might be surprised how little I care You obviously care enough to have taken the initiative to engage me on this. > Are you suggesting we should rewrite compression or imaging or ... software in Common Lisp because it will be so much better? No. It's generally never worthwhile to re-write anything. But one should not fall prey to the sunk cost fallacy either.

lisper 7y ago

It's not that they are without flaws, it's that it is a lot easier to fix/ignore/work-around the flaws than in other languages, where the flaws are unchangeable (except by the standards committee) and constantly in your face.

jstimpfle 7y ago
hear, hear.
ncmncm 7y ago
No. You are just used to your flaws, and not used to theirs; and have learned not to complain about yours, but complaints about theirs are welcomed in your circle. In other words: other systems really are crap, but so is yours, really, but we all get our stuff done, despite it all. Sometimes things get better (Moore's law has forgiven all manner of evil) and sometimes they get worse (Java).
- lisper 7y ago
  > You are just used to your flaws, and not used to theirs This is a testable theory: name me a flaw in Common Lisp that cannot easily be worked around. I'll bet that for any flaw you name, I'll be able to show you an easy way to work around it.
  - jstimpfle 7y ago
    Of course you will be able to give a brittle, half-assed work around for any issue that someone throws at you. But you know, not all people are obsessed with LISP, not all people are ok with half-assed workarounds. I think you are being very dishonest to yourself if you think that LISP is universally the best just because you can theoretically turn it into anything. You can't, really. Good tooling matters. Error messages matter. Standardization matters. Syntax matters (to some extent). Mindshare matters (a lot). There's a lot of subtle qualities that you can't just fake. When I write performance sensitive code I'll personally just pick C. I'm sure there's a Common Lisp solution available to specify machine types and compile efficient code. (Probably there's many, which is another problem). But what's the point in putting lipstick on a pig when I can just use the real deal that works perfectly for what I'm doing?
    - lisper 7y ago
      "Half-assed" is in the eye of the beholder. If you appoint yourself as the ultimate arbiter of half-assedness then your position becomes unfalsifiable. But I think you might be surprised at how un-half-assed these things can be.
      - jstimpfle 7y ago
        > But I think you might be surprised at how un-half-assed these things can be. You might be surprised how little I care, because I'll just use a solid, battle-tested tool instead. Are you suggesting we should rewrite compression or imaging or ... software in Common Lisp because it will be so much better?
        lisper 7y ago
        > You might be surprised how little I care You obviously care enough to have taken the initiative to engage me on this. > Are you suggesting we should rewrite compression or imaging or ... software in Common Lisp because it will be so much better? No. It's generally never worthwhile to re-write anything. But one should not fall prey to the sunk cost fallacy either.