91–100 of 101 posts
Previous discussion: https://news.ycombinator.com/item?id=11032296
Why not just make successful "dupe" link stay but not bring karma to the poster ? That will stop the perverse incentive to try to submit old successful link for easy karma.
My favorite example of code you should almost always[0] duplicate are view classes (in MVC terminology). Instead, I see people subclassing views to change their behavior and dealing with absolutely mind-numbing behavioral bugs in their subclass. Furthermore, the subclass's implementation is totally dependent on the _exact_ implementation of the superclass. Change it, and you get a whole crop of new, hard to debug, bu…
That might work if you have a very small app (example: HN, Reddit, Twitter web client etc) Imagine, on the other hand, large-ish web app (example: Salesforce, Netsuite). 300 tables in the database. Perhaps 50 of those can be manipulated directly from the menu. Customers, Purchase orders, Quotes, Reports, plus all the supporting stuff like Countries, States, Currencies and so on and so forth. Each of those need at lea…
In MVC terms, that's either (a) the M, or (b) the C. Not the V.
I suggested not trying to fight the (hidden) behavior in a superclass when working on the V layer. I stand by that.
I've also advised some extremely large projects (over 5000 unique screens). My advice scales really well.
You can do whatever the hell you want on small (toy) projects.
Earlier quoted context omitted.
You can remove the judgement call by making it a design rule, as extreme programming did long ago. When you've duplicated something 3 times, it's time for some abstraction because you have enough examples now to see what needs abstracting and what doesn't. The problems you're describing are just symptoms of premature abstraction. Abstractions tend to fail when they come before the concrete, they tend to succeed when…
Agree with all of that. My hatred of extreme DRY is due to having been burned by premature/poor abstraction so many times. Also, there are even exceptions to that rule.. I've seen a number of cases, let's say you've got a bunch of command line utilities that launch different jobs, there's some code that's duplicated across like 10 of them. Be careful with deduplicating that, you can wind up forcing very different thi…
20.timesRepeat(() => doStuff());
for(var x = 0; xEarlier quoted context omitted.
Agree with all of that. My hatred of extreme DRY is due to having been burned by premature/poor abstraction so many times. Also, there are even exceptions to that rule.. I've seen a number of cases, let's say you've got a bunch of command line utilities that launch different jobs, there's some code that's duplicated across like 10 of them. Be careful with deduplicating that, you can wind up forcing very different thi…
We're probably in close agreement then. However I'll disagree with your last statement as that's actually often a standard abstraction and the clearer less error prone way to write an n times loop. I'd rather see 20.timesRepeat(() => doStuff()); than for(var x = 0; x for and foreach loops are virtually always in need of some cleaner functional abstractions that are already standard parts of virtually every collection…
Earlier quoted context omitted.
We're probably in close agreement then. However I'll disagree with your last statement as that's actually often a standard abstraction and the clearer less error prone way to write an n times loop. I'd rather see 20.timesRepeat(() => doStuff()); than for(var x = 0; x for and foreach loops are virtually always in need of some cleaner functional abstractions that are already standard parts of virtually every collection…
That depends on the language, I love flatMap, but I never want to see functions attached to the integer type. Just stop with that :) Principle of least astonishment and all.
10 timesRepeat: [ self doStuff ]
Earlier quoted context omitted.
That depends on the language, I love flatMap, but I never want to see functions attached to the integer type. Just stop with that :) Principle of least astonishment and all.
An integer is an object, objects have methods, such methods are standard fare; if it's astonishing, try more languages. This is the idiomatic way to do this for example in Smalltalk. 10 timesRepeat: [ self doStuff ] What's relevant isn't whether you're astonished or not, but whether it's idiomatic or not. If you can't see an integer as an object with methods, then you haven't fully grokked OO.
WTF does "timesRepeat" have to do with what an integer represents? Nothing, that's what. Integer is a noun, conventionally a 32-bit value type, while "timesRepeat" is a control structure. It's absolutely crazy for "timesRepeat" to be a member of integer.
Earlier quoted context omitted.
An integer is an object, objects have methods, such methods are standard fare; if it's astonishing, try more languages. This is the idiomatic way to do this for example in Smalltalk. 10 timesRepeat: [ self doStuff ] What's relevant isn't whether you're astonished or not, but whether it's idiomatic or not. If you can't see an integer as an object with methods, then you haven't fully grokked OO.
I've tried lots of languages, thanks. It's still astonishing and will always be astonishing. WTF does "timesRepeat" have to do with what an integer represents? Nothing, that's what. Integer is a noun, conventionally a 32-bit value type, while "timesRepeat" is a control structure. It's absolutely crazy for "timesRepeat" to be a member of integer. http://thecodelesscode.com/case/223
Same thing applies to ranges.
1 to: 10 do: [:num | Transcript show: num ]
[ aList isEmpty ] whileFalse: [ aList removeFirst ]
Previous discussion: https://news.ycombinator.com/item?id=11032296
I generally agree that it's good not to have many dupe but in this case there was a lot of upvotes and a lot of comments and tagging the link as "dupe" just destroy the discussions. Why not just make successful "dupe" link stay but not bring karma to the poster ? That will stop the perverse incentive to try to submit old successful link for easy karma.