5 ms·
I like this quotation: Languages talk about being multi-paradigm as if it's a good thing, but multi-paradigm means you can always do the bad thing if you feel
by pohl 13y ago
I like this quotation:
Languages talk about being multi-paradigm as if it's a good thing, but multi-paradigm means you can always do the bad thing if you feel you really need to, and programmers are extremely bad at doing sort of the the time-scale integration of the cost of doing something that they know is negative. I mean everyone will know...it's like "this global flag: this is not a good thing, this a bad thing - but it's only a little bad thing" and they don't think about how, you know, the next five years how many times that little bad thing is going to effect things. So brutal purity: you have no choice.
In particular, I like the bit about integrating your technical debt function with respect to time, over the time you have to live with the debt, and how bad programmers are at thinking in those terms. We tend to think about how much technical debt we have at a given fixed point in time, but the area under the curve is what bites you.
- rybosome 13y agoReminds me of something a former boss used to say. "Pay me now, or pay me later; either way, there has to be a payment". It sounds like Carmack is saying that brutal purity always forces the "pay me now" approach since it's harder to write this code, but it is worth it in the long run.
- oneandoneis2 13y agoAs credit cards have shown, people are very bad at making good decisions when they don't have to pay for them until "tomorrow"
- orclev 13y agoThat was more or less my take away as well, it forces you to deal with most of your technical debt up front and not let it pile up to some indefinite point in the future. Essentially brutal purity is a really strong anti-kruft coating. Since kruft can't stick to your code, it tends to stay nice and shiny well into the future, unlike the dirty impure code elsewhere that builds up a nice thick layer of kruft over time and eventually collapses under that weight (or else some poor soul ends up spending a bunch of time either scrapping all the kruft off, or just throws it out and builds a new one).
- Aqueous 13y agoWhile i can see his point, I'm not entirely sure this is the case. A text-book example of a multi-paradigm language is Scala. And yet with Scala, the more I've learned about the functional side of things, the more tempting it is just to avoid any imperative or object-oriented idioms or patterns and just go functional all the way. it's almost as if the designers of scala knew if they could convert java programmers over, the temptation to do bad things would go away if only because functional is so much more elegant that it doesn't make sense not to use it as much as possible.
- seanmcdirmid 13y agoMy experience with Scala was the opposite: it has great support for OO and imperative programming. The functional way of doing things often wasn't better, while on the other hand, traits are crazy flexible. I've seen people go crazy with functional code in Scala that is barely readable and impossible to debug; the JVM debugger is still optimize for imperative programs, while no one has really figured out a good debugger for functional programming yet. OO/imperative programming isn't all "bad." Being functional doesn't really ensure that the code is "good."
- justinpombrio 13y ago"There is no programming language, no matter how structured, that will prevent programmers from making bad programs." - Larry Flon The same applies to programming paradigms.
- nightski 13y agoThere are many programming languages, specifically structured, to prevent programmers from making a certain subset of bad programs. This is incredibly useful.
- marshray 13y agoYeah, but these languages tend to be not a good fit for inherently complex problems. When one tries to express complex ideas in those languages, you end up code that's either absurdly verbose, or code that experts in that language's idioms would call "bad". One can write simple, structured code for simple problems in any language. But complex problems require languages that don't attempt to babysit programmers. (IMNSHX, YMMV)