4 ms·

> It introduces an alternative and does so as a superset; which is not only dangerous to existing code bases... How so?

• keyle 2y ago
  An alternative way to do something in a code base, for no other reason than style, is a recipe for technical debt. It builds up a larger cognitive load on the developers navigating and working the code base and induces more chances of bugs via half-refactors, or half-considerations. As for the superset comment, I meant that if you introduce a completely different language, you probably have a valid reason; e.g. it does something different. Adding to an existing language with a superset without any need for it is also dangerous. It's not like it's a DSL at a higher level helping people get repetitive or scriptable things done faster. It's only an alternative, leading people down rabbit hole and second guessing with a lot more to remember.
  • scubbo 2y ago
    I see. I misinterpreted your meaning of the word "existing" - I thought you were implying that, by virtue of the introduction of the alternative, any existing codebases would _immediately and instantly_ be worsened, whereas it seems that you're saying that continued (future) development _on_ existing codebases would deteriorate due to those alternatives. That's a fair criticism! I don't fall on the same point in the "alternatives provide better-focused tools <-> alternatives create cognitive load" spectrum as you do, but I see your point. > It's not like it's a DSL at a higher level helping people get repetitive or scriptable things done faster. I mean, I have to disagree with you there, because several of the comparisons on the main site page show >50% line-count reduction, and many of those that don't have (subjectivity-alert!) representations that more-clearly match my mental model of how the code works - so not only would I be executing fewer keystrokes to encode my idea (not the main bottleneck, but not irrelevant!), but also I'd be carrying out fewer mental translations to get from idea to code.