151–158 of 158 posts
Earlier quoted context omitted.
I'm fairly certain you don't think it's a lie, and you are just envious. Either way, I don't see how any of this matters. I explained why I criticized the guy, and instead of working on that, you tried to undermine the anecdotal part.
No undermining, I just think you're lying about being popular and confident and good at sports. It's ok if that upsets you.
Earlier quoted context omitted.
...I rarely trust these kinds of name-generation tricks. So you're probably not a big fan of Rails, then?
I'm actually not a huge fan of implicit name-generation tricks, but I'm also not entirely opposed to them. The trick here I think is consistency - is name-generated type dispatch the standard across the entirety of the codebase? If it is, go wild. If it's not then I'd be much more wary of it. Consistency and building correct expectations for future maintainers is pretty important. Doing a smart trick in one place but…
Reading the comments in this thread is very interesting to me, because each programmer seems certain of the superiority of his own programming style. We have some comments that disparage the change, saying that it obfuscates the code and makes it more difficult to understand. We have others saying that this change is a basic technique and it's "shocking" that the author wrote a book without this simple knowledge. Wha…
Early in my career, a project manager said to me, "I've never heard one programmer praise another programmer's code. They always criticize!" I think that reinforced for me both that someone's approach might be good even if it isn't my own, and also that it's important to say when something is done well. Of course, there's also just a lot of bad code out there.... :-)
I feel ashamed when I touch it I dirty it up.
Earlier quoted context omitted.
It has a couple of patterns that have been more or less rejected by modern OO leaders: 1. "Singleton" (enough said) 2. "Template method" is more or less "inheritance over delegation" There's also a couple like Flyweight that are of such narrow applicability that they hardly merit placement on the short list with classics like Composites and Factories, and a few new items like Dependency Injection are surely worth a m…
What is your recommended introduction to design patterns? I've been meaning to read the original but I do get that old-school clunky Java feel from it. I'd be very interested in an updated Design Patterns for OO languages with mild functional capabilities like C++11, C#, Python.
Earlier quoted context omitted.
It has a couple of patterns that have been more or less rejected by modern OO leaders: 1. "Singleton" (enough said) 2. "Template method" is more or less "inheritance over delegation" There's also a couple like Flyweight that are of such narrow applicability that they hardly merit placement on the short list with classics like Composites and Factories, and a few new items like Dependency Injection are surely worth a m…
What is your recommended introduction to design patterns? I've been meaning to read the original but I do get that old-school clunky Java feel from it. I'd be very interested in an updated Design Patterns for OO languages with mild functional capabilities like C++11, C#, Python.
Earlier quoted context omitted.
It has a couple of patterns that have been more or less rejected by modern OO leaders: 1. "Singleton" (enough said) 2. "Template method" is more or less "inheritance over delegation" There's also a couple like Flyweight that are of such narrow applicability that they hardly merit placement on the short list with classics like Composites and Factories, and a few new items like Dependency Injection are surely worth a m…
Why has the singleton pattern been rejected? Similarly, why has the template method been rejected? Both seem entirely reasonable patterns to me - what is so wrong with them?
However, the template method pattern I do understand now. Far better to define an interface, then inject an instance object that implements the interface and work on that.
Earlier quoted context omitted.
When people disagree that doesn't imply that the situation is highly subjective and all opinions are equally valid. In this case I believe they most certainly are not and I think you are drawing stronger conclusions than is warranted. There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping cod…
I can agree with some of your points; however, I believe you make too many simplifying assumptions. > There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed. Hardly any…
but the question becomes: what is the best way to favor immutability [..]
I have found that age matters very little with regard to
someone's ability to write code. [..]
Earlier quoted context omitted.
My concern is the inverse of that: recommending something you either don't fully understand or haven't used long enough to speak to either its pros or cons. Being in a book usually is an indicator that something is a best practice or how the way things should be done, ostensibly being put forth by an expert. Perhaps we shouldn't hold such content to such a standard.
I checked out the self-published Object-Oriented Design Anthology that this Clay guy ostensibly wrote judging by the discourse in this thread. Instead, I found that he wrote from what I can tell the only book that introduces RubyMotion, published by PragProg, and endorsed by other authors. His blog post shows humility, an ability to praise the work of others, and an effort to add value to the world. All things that t…
I appreciate the humility. I just wish it manifested in a crawl before you can run mentality. There is actual value in understanding the fundamentals.