3 ms·

I might be picking this up. Most OOP design books I avoid, as I have little money and I dislike code with Java Syndrome (heavy focus on inheritence and hierarch

I might be picking this up. Most OOP design books I avoid, as I have little money and I dislike code with Java Syndrome (heavy focus on inheritence and hierarchy, extreme verbosity, IDE focus, boilerplate with no end in sight, patterns to replace your favorite features from Lisp, java.net.org.lang.lang.really.long.reallylong.import.paths.path, IteratorStrategyProviderFactoryFactoryFactory, etc. yes, I'm exaggerating quite a bit, but there's a reason I avoid Java like the plague), but Ruby tends to play home to practicality, and smalltalk refugees. This is good, and means that this book is a far safer bet than, say, flashy OO design book of the week. Although, I should probably get around to reading Refactoring, and Design Patterns. I've heard those are good...

stcredzero 10y ago
heavy focus on inheritence and hierarchy, extreme verbosity, IDE focus, boilerplate with no end in sight, patterns to replace your favorite features from Lisp, java.net.org.lang.lang.really.long.reallylong.import.paths.path, IteratorStrategyProviderFactoryFactoryFactory, etc. What people need to get their heads around is that everything is about cost/benefit in particular languages in particular contexts/environments. What is the "density of reward" in the edit/test/debug cycle? What is the density of punishments? What comprises the cognitive load and where does it come from? Just because something is good for one thing, doesn't mean it's good for another.
- qwertyuiop924 10y ago
  Well, yeah, but lighening up on the boilerplate and shortening your import path a bit never hurt anybody. 50 copy-pasted lines don't make your app more flexable. Some of the other stuff I mentioned CAN work and be useful, though.
  - stcredzero 10y ago
    Well, yeah, but lighening up on the boilerplate and shortening your import path a bit never hurt anybody. My point is that often adopting patterns/tools/conventions from other languages results in cruft like that.
    - qwertyuiop924 10y ago
      Yes, but you seem to be arguing that that cruft is good. If not, than I really don't see where we disagree.
      - stcredzero 10y ago
        Yes, but you seem to be arguing that that cruft is good. Arrgh, NO! I'm saying cruft is bad! You're taking something that's good in one context, then naively trying to use it in a different one, mistakenly thinking it will have the same goodness. Analogous errors: taking a crop from one environment, then expecting it to grow well in a different one. Doesn't always work. A clever saying from one social context might bomb in another.
        qwertyuiop924 10y ago
        Oh. Sorry. You misread my comment. Yes, I know what it says, and in retrospect, I should have been clearer. After doing a bit of simple Java programming for a bit, I thought it was okay, if a bit verbose. A while later I looked into how to start with Android development, which is what I really wanted to get into. I had seen some of the hate spewed at java, and had been having some frustrations with it myself, and was starting to feel a little unsure about the language. Little did I know... The first few lines of the Android tutorial were, "copy-paste about 20-30 lines of code, and then type a few more. This should get you a button in the middle of the screen that says "hello world." This is the moment when I gave up on Java. Because that wasn't me, tossing my warped ideas, taken from other languages at the thing. These were professionals, who wrote an API, and clearly thought that this level of boilerplate was acceptable, nay, necessary. If it takes 20+ lines to instatiate a simple component, and have it say, "hello world," than how do you write applications in this thing? In JS, I could've been done in less than 5 lines (android uses an interface builder, so the comparison isn't unqualified). In TCL, this is maybe two lines. In C, maybe the program would have been comparable, but in C, you have to malloc and instantiate objects that the library and runtime take care of for you in java. There is no excuse. The fact that Java didn't have lambdas, still lacks many common features from higher level languages, and locks you an an OO straitjacket is irritating for me sometimes, but understandable. The verbosity, on the otherhand, is unneccessary, unusable, and unacceptable. Reasonable people may disagree.
SomeCallMeTim 10y ago
>code with Java Syndrome You might find that most of the Design Patterns and even some of the Refactoring book are focused on working around limitations in Java/C++-style languages. >Although, I should probably get around to reading Refactoring, and Design Patterns I'd been programming for 20 years before reading either. Both were...entirely unsurprising. Design Patterns at least defined a useful vocabulary for talking about different patterns, so I found it useful in that respect, and at least some of the patterns are useful outside of a Java/C++ language. Refactoring had some good wisdom on OO design, but it was pretty much all stuff I'd picked up elsewhere or come up with on my own. Wouldn't hurt to read through both at least once to see if there are any surprises for you. Might be safe to just check them out of the library, though. I kept Design Patterns around but gave away my Refactoring copy.
- taco_emoji 10y ago
  Personally I really liked "Head First: Design Patterns" because it's more about the overarching strategies (e.g. composition vs. inheritance) which design patterns are merely examples of. It was more of a top-down approach - I didn't realize memorize the patterns themselves, but internalized the justifications for them.
  - qwertyuiop924 10y ago
    Than I may look at that: I have long since learned the truism that it's better to know how to think than what to think.
- qwertyuiop924 10y ago
  Seeing as I have the freedom to code in lisp, etc., much of Design Patterns may be of questionable value. However, knowing my own weaknesses writing code (every piece of code I have written is terrible), and my relative newness to programming (I've been doing this on and off for 7 years, but rarely seriously), Refactoring seems like it may be of value.

stcredzero 10y ago

heavy focus on inheritence and hierarchy, extreme verbosity, IDE focus, boilerplate with no end in sight, patterns to replace your favorite features from Lisp, java.net.org.lang.lang.really.long.reallylong.import.paths.path, IteratorStrategyProviderFactoryFactoryFactory, etc. What people need to get their heads around is that everything is about cost/benefit in particular languages in particular contexts/environments. What is the "density of reward" in the edit/test/debug cycle? What is the density of punishments? What comprises the cognitive load and where does it come from? Just because something is good for one thing, doesn't mean it's good for another.

qwertyuiop924 10y ago
Well, yeah, but lighening up on the boilerplate and shortening your import path a bit never hurt anybody. 50 copy-pasted lines don't make your app more flexable. Some of the other stuff I mentioned CAN work and be useful, though.
- stcredzero 10y ago
  Well, yeah, but lighening up on the boilerplate and shortening your import path a bit never hurt anybody. My point is that often adopting patterns/tools/conventions from other languages results in cruft like that.
  - qwertyuiop924 10y ago
    Yes, but you seem to be arguing that that cruft is good. If not, than I really don't see where we disagree.
    - stcredzero 10y ago
      Yes, but you seem to be arguing that that cruft is good. Arrgh, NO! I'm saying cruft is bad! You're taking something that's good in one context, then naively trying to use it in a different one, mistakenly thinking it will have the same goodness. Analogous errors: taking a crop from one environment, then expecting it to grow well in a different one. Doesn't always work. A clever saying from one social context might bomb in another.
      - qwertyuiop924 10y ago
        Oh. Sorry. You misread my comment. Yes, I know what it says, and in retrospect, I should have been clearer. After doing a bit of simple Java programming for a bit, I thought it was okay, if a bit verbose. A while later I looked into how to start with Android development, which is what I really wanted to get into. I had seen some of the hate spewed at java, and had been having some frustrations with it myself, and was starting to feel a little unsure about the language. Little did I know... The first few lines of the Android tutorial were, "copy-paste about 20-30 lines of code, and then type a few more. This should get you a button in the middle of the screen that says "hello world." This is the moment when I gave up on Java. Because that wasn't me, tossing my warped ideas, taken from other languages at the thing. These were professionals, who wrote an API, and clearly thought that this level of boilerplate was acceptable, nay, necessary. If it takes 20+ lines to instatiate a simple component, and have it say, "hello world," than how do you write applications in this thing? In JS, I could've been done in less than 5 lines (android uses an interface builder, so the comparison isn't unqualified). In TCL, this is maybe two lines. In C, maybe the program would have been comparable, but in C, you have to malloc and instantiate objects that the library and runtime take care of for you in java. There is no excuse. The fact that Java didn't have lambdas, still lacks many common features from higher level languages, and locks you an an OO straitjacket is irritating for me sometimes, but understandable. The verbosity, on the otherhand, is unneccessary, unusable, and unacceptable. Reasonable people may disagree.

SomeCallMeTim 10y ago

>code with Java Syndrome You might find that most of the Design Patterns and even some of the Refactoring book are focused on working around limitations in Java/C++-style languages. >Although, I should probably get around to reading Refactoring, and Design Patterns I'd been programming for 20 years before reading either. Both were...entirely unsurprising. Design Patterns at least defined a useful vocabulary for talking about different patterns, so I found it useful in that respect, and at least some of the patterns are useful outside of a Java/C++ language. Refactoring had some good wisdom on OO design, but it was pretty much all stuff I'd picked up elsewhere or come up with on my own. Wouldn't hurt to read through both at least once to see if there are any surprises for you. Might be safe to just check them out of the library, though. I kept Design Patterns around but gave away my Refactoring copy.

taco_emoji 10y ago
Personally I really liked "Head First: Design Patterns" because it's more about the overarching strategies (e.g. composition vs. inheritance) which design patterns are merely examples of. It was more of a top-down approach - I didn't realize memorize the patterns themselves, but internalized the justifications for them.
- qwertyuiop924 10y ago
  Than I may look at that: I have long since learned the truism that it's better to know how to think than what to think.
qwertyuiop924 10y ago
Seeing as I have the freedom to code in lisp, etc., much of Design Patterns may be of questionable value. However, knowing my own weaknesses writing code (every piece of code I have written is terrible), and my relative newness to programming (I've been doing this on and off for 7 years, but rarely seriously), Refactoring seems like it may be of value.