begin quoting Wade Curry as of Sat, Jun 16, 2007 at 01:03:18PM -0700: > Stewart Stremler([EMAIL PROTECTED])@Sun, Jun 10, 2007 at 12:28:34AM -0700 > wrote: > > begin quoting Christopher Smith as of Sun, Jun 10, 2007 at 12:00:46AM > > -0700: > > > but frankly Java without generics just had this huge > > > gaping eyesore of a problem in its type system, > > The sheer verbosity of the code is what assaults my eyes. I can > appreciate the OO method for a variety of reasons. Verbosity tends > to follow along with OO languages, though. It's like being in the > car with someone who farts; usually not deadly, but you don't want > to ride with them again. :-)
One man's verbosity is another man's readability ... on the flip side of "verbosity" there's "conciseness" -- and if it's too concise, it's just noise. Somewhere in the middle is a happy medium. But OO doesn't mean that it has to be verbose. C++ is verbose; Java is less verbose than C++; and Smalltalk is less verbose than either. I once read (no cite!) an assertion that the "average method size" in C++ was about 50 LOC, in Java, 20 LOC, and in Smalltalk, 5 LOC. [Values taken from failing memory, YHBW] Of course, in Smalltalk, you tend to get a lot more methods, which makes reading it kind of annoying, and it makes the LOC/method ratio a *little* misleading. But if you wanted, you could come up with an APL-style OO language, that was VERY concise... it's just that by the time you pull out your OO stick, you're likely to also be a little gun-shy of the "cryptic as possible" style of thought. So most OO-friendly programmers wouldn't use your language anyway, I bet. > > Never bothered me. Bothered some of my collegues, but I figured that > > if you're passing around raw collections, you're writing poor OO code > > anyway, so why worry about it. > > That's a reasonable response. Although, I can see how it would > frustrate your colleagues. When a tool restricts me because the > tool's developer assumes knowledge of how/why I'll use it, it > really ticks me off. Isn't really a situation that can be fixed, > IMO. It's a question of human nature, more than of tools. They wanted the return types to be type-checked, so they wouldn't have to cast 'em. I was happy to put a contract (in the comments) that method Y on class X would return a collection of objects of type Z... then write a unit-test or three to verify that. They wanted compile-type type-checking for the collections. So they returned (and accepted) arrays. Quit a lot of code would convert an array into a collection for processing, or it would build up a collection and then turn it into an array when returning it. Sure, it only takes a couple of lines of code, but that just seemed a bit excessive. In the big scheme of things, however, this sort of trick didn't seem to show up in the profiler very often, so it probably wasn't a BIG problem. > > All I wanted was covariant return types. > > Ah. Now, when I know what generics are, maybe I'll understand > explanations of "raw collections" and "covariant return types" :-) > Oh, and synchronize. > > If anyone is willing to instruct, please do! I'll compose a separate response. [snip] > > "Wouldn't it be neat if..." is a poor design aesthetic. > > Design _aesthetic_?? Who cares? "Wouldn't it be neat if..." is > what leads to the best innovation. Nope. I don't really need brown-carpet-covered toilet seats. I don't need a screwdriver built into the head of my hammer. I don't need a mounting bolt on the blade of my chainsaw so I can use it as a tablesaw as well. > It's obviously hard to invent > successful software design solutions... and the cruddy ones will be > packaged and marketed to those who can't tell the difference. Which ends up being everyone. Drek drives out quality. And I'm not even talking about "good enough" being the enemy of the best. Crap kills "good enough", if "good enough" is sufficiently difficult to do. > Still, it seems to me that a language developed with that focus > should have value to those who _can_ tell the difference by > providing disproof of concept (or at least of implementation). ....and this becomes an aesthetic. "Will that work well in the long term? No? It sucks." > > I don't want a one-language-fits-all-problems language. It just results > > in a language that is equally unpleasant for all problems... > > I wonder about that. Is it the language itself that is unpleasant? I assert so. :) > Maybe it has more to do with how each individual approaches > decomposing a project. I suspect people gravitate to certain > languages because of how it fits their approach to the problem(s) > at hand (but obviously not that alone). Oh, indeed. And language choice influences the decomposition process. When all you have is a hammer, every problem looks like a nail, yes? (When you have a sawsall, every problem looks like fifteen minutes of fun!) > > I have more than one screwedriver in my toolbox. And more than one toolbox. > > Me too, but that's more because I want to have a screwdriver > _anywhere_ I can find one after the kids have borrowed it. :-) Just because you *can* use your leatherman to pound nails doesn't mean you'd be in very good shape if you tried to build a house with it... -- Lots of tools for lots of jobs and lots of problems. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
