Not everyone can be Chuck Moore, sure, but anyone can easily exceed guys like John Resig or Guido Van Rossum. Folks here seem to think that if you're either as great as Moore or you're a drooling idiot. Because analogies are fun: You don't need to match Dirac to be a great physicist, or surpass Whitman to be a great writer.

No, it's not. (Thinking is a learned skill, after all.) That sort of egomaniacal nonsense is why so many programming communities are cesspits. Get over yourself.

I really wonder: When it's obvious that you're skilled at something because you put in effort, why deny yourself that accomplishment to pretend that it's through no effort on your part, but just dumb luck? It's like being proud that you were born on a Wednesday!

Is it because you're actually insecure and want to believe that those you admire for their talent are "just lucky"? Is it that you'd rather believe that it's not your fault that you're not as accomplished as you'd like to be? Isn't it far more empowering to accept that you're skilled because you put in effort and that you can continue to improve?

I just can't understand this mentality.

Not a bad start, gets right to the meat. Though I don't know how we go from 'Object' to 'OOP'.

We could ask 'are objects useful', but that's not the same discussion. It does remind me of this talk [pdf] which took longer to find than I expected.

Why not? There are just a few simple concepts you need to understand. It's why so many pre-teens were able to easily 'graduate' from BASIC to Assembly back in the 80's -- they already had all the necessary skills. The rest, like any skill, improves with practice.

Hey, let's face it: modern software is a disaster. A few easy examples: I've got a simple Pac-Man game I found for my phone that weighs in at nearly 30mb. I'm not even sure how that's possible. (Give it a shot. Over the weekend, write a pac-man clone. I'll bet that yours will be significantly smaller, even if you try to bulk it up by adding extras like flashy graphics and effects.) This isn't an anomaly, it's disturbingly common.

A $30,000/seat bit of industry specific software the folks at the office across from mine uses actually includes the full QuickBooks SDK as part of the installer -- not the redistributable, mind you, the bit intended for developers download and use. I don't recall exactly, but the program is well over a gig installed and took more than a minute to start. The kicker? It's a simple database and reporting app. The DOS app that it replaced fit on a floppy.

Modern software is getting bigger and more complex, but isn't actually *doing* a whole lot more. (The app mentioned earlier has two new features lacking in the DOS version: the ability for multiple terminals to use the same DB and the ability to electronically submit a few reports.) Sometimes, as you well know, it even does less.

I have no explanation for that other than lazy, apathetic and unmotivated developers working in an industry driven by fads promising quick and easy development. How else do you explain the countless articles in the form of "Use Framework-X with Does-It-All-Library-Y to do Simple-Thing"? It's pure madness!

Yes. It's why most people are bad at things, be it their profession or otherwise.

For example, I'm a third-rate cook. (I look upon Charlie Brown with envy.) The reason being of course, is that I have no interest in cooking. I do it only occasionally out of necessity. However, given enough interest and time, I have no doubt that I (or anyone else, for that matter) could learn to cook as well as my wife.

Why are there so many second-rate professionals in software? I can only offer speculation, but I think there may be some truth to it: Trade-schools and colleges have been churning out programmers at an alarming rate. A good number of those students 'liked computers' and, lacking other serious interests, elected to study CS, MIS, or whatever was offered. When they found out that CS is really math and that programming is a dull, tedious, activity, they plodded along anyway just to graduate. Having no other relevant skills, and the promise of easy money, they started off their careers in software. (I'd be willing to bet that a lot of students in CS programs in the mid to late 90's were lured in by the promise of easy employment and high salaries, without even a passing interest in computers.)

You've got quite the gap there! Anyone can learn basic auto maintenance, just as anyone can learn to become a competent mechanic. ('Competent mechanic' is on-par with 'good developer'. I'd even go so far as to say that the necessary skills for each are similar. The main difference, of course, is that auto mechanics, as a profession, isn't driven primarily by fads and folk-wisdom.)

If you really want to take that further, yes, anyone with sufficient interest and resources can become a skilled engineer capable of designing such systems. Programming, of course, is about as far from engineering as you can get. I consider it offensive to compare programming to engineering.

I have way too much to say about that Scotsman. The trouble, of course, is that it's impossible to produce an operational definition to which a suitable number of people will agree. I can type until my fingers bleed, but I can't escape the simple, yet perfectly reasonable, response: "Well, that's not really OOP."

Even I don't agree that most of my criticisms are necessarily against OOP, as my understanding of the concept is different than some of the more common variations. (For example, I don't think classes are an essential concept. Without classes, a lot of other "OOP" topics vanish from the discussion.)

It's just too nebulous to talk about in the general sense.

Odd. In my experience, the people who insist you need a 'special mind' to code are deeply insecure people with no other skills.

Programming is absurdly simple. Back in the 80's, you couldn't throw a stone without hitting a kid who wrote games for his home micro as a hobby. Hell, the bulk of the users here taught themselves before the age of 10!

You've probably noticed this yourself, but there are a LOT of really stupid professional developers. It doesn't take genius; just interest and a little time.

I'm sad to say that I completely agree.

The entire concept of design patterns, really. While I'll admit their book is widely misunderstood, and they address a lot of my concerns in the first few pages, the negative impact the book has had on software can't be overlooked. From the rampant misuse of patterns to the countless over-engineered systems they've inspired, their influence has caused far more problems than it solved.

The general understanding of design patterns is a problem as well. While broadly misunderstood as a 'language of design', the so-called patterns are not language agnostic. The explosion of 'new patterns' that followed further diluted any possible value that concept offered. Just replace the word 'pattern' with 'solution' next time your read about a pattern and you'll see what I mean. (That all stems from the *title* of the book! I've never seen a book's title alone cause so much confusion and harm.)

A note on that misunderstanding: The 'why' is often far more important than the 'what' when communicating with other programs. To say 'I used the visitor pattern here' gives you the 'what', but not the 'why'. There's also a strong indication there that the code is too complex to understand without hanging a common name around its neck.

Moving on... Sploski offered two points, to which I agree: 1) Patterns introduce unnecessary complexity. 2) Recurring use of patterns indicates a deficiency in the language. (There's also a discussion on c2 somewhere about that.) On (1) there's the use of patterns where far simpler solutions are more appropriate. They're often used here because too many developers think that using patterns mean their code is 'adheres to good principles of design'. This leads to a consequence in (2), related to my point that patterns are not language agnostic, which is the amazing amount of effort placed in to implementing patterns in languages that have no need for them.

So what about the premise? Are there, in fact, recurring design patterns? We'll never know. The GoF based their book on good feelings and personal experience, not actual research. You'd think if there were recurring solutions to common problems, they'd have been discovered -- though they're often simply invented, just like those in the book, by every neophyte developer out there. It's no wonder, then, that the term 'anti-pattern' found its way in to our vocabulary to combat the pattern explosion. I've even seen many of the GoF patterns described as anti-patterns. Being groundless, they're vulnerable to such subjective criticism.

Obvious questions like 'is this a recurring problem', 'is this solution effective', and 'is this solution efficient' never seem to enter the discussion. Without a lot of effort, you can't even begin the answer the first question, let alone start proposing solutions! Lacking actual research means that developers have no choice but to actively look for opportunities to use patterns (leading to pattern abuse) rather than simply determine if a particular pattern is appropriate based on the information they have available. That is, they can only ask 'can it be used' not 'should it be used'.

Patterns are folk wisdom, not engineering, and suffer the same problems. Next time you reach for the GoF book, ask yourself if you're putting butter on a burn.

I said no such thing!

I never said it was.

Did you read anything I posted? Fucking troll

You are! I've pointed out several times that the bulk of their software is not, in fact, little front-end apps. (From the OS to BES, there's a lot of non-Java code!) I've also pointed out, that even those front-end apps, while written in Java, rely on an entirely different API. Hell, just on their legendary security alone, Android can't even begin to compete. That is, your claim that it would have been 'easier' to switch to Android than QNX because their front-end apps were written in java is wrong in every possible way.

You're a willfully ignorant troll. Go away.

No one knows. Those who think they know all disagree with one another.

Really? I think the GOF should be round-up and shot. No other group has caused more harm to the industry.

There are a few languages I'd call works of genius, like LISP and Forth. C++, however, is not one of those languages.

Fortunately, more people are starting to recognize that. I'm amazed it took this long.

Where's Tablizer? He's owed some vindication.

You're just trolling now. At this point, we both know that isn't true. Insisting otherwise won't change history.

I don't even know how to respond to this. Android isn't a selling point. It's something informed buyers overlook, and the rest don't care about.

A good thing that never happened then!

You can predict the future! Amazing! How about this: What happens next year when BB has 128k screens and eleventy billion cores and users of last years Android phones see that; who's going to be envious?

To answer your question: No one. Because no one cares. All that matters to Passport users is "will this let me work more efficiently" It's an entirely different market than the market that you're in. You're in the market for a gameboy that sends text messages. A lot of smartphone users are as well.

The rest of us, well, we've got work to do. I mentioned earlier that my wife ditched her first and only Android phone for a BB. What I didn't tell you was that it wasn't the latest model, but an older one. It was slower and had a smaller display, but it was infinitely more useful to her. Managing her complex schedule and email was significantly easier and faster.

Different people have different needs. You want a toy. Passport and Classic users want a tool. You think BB should have abandoned their core market to sell silly playthings. They'd have been dead before the end of the quarter had they done something so foolish.

Go away now. I'm bored with your uninformed, ill-considered, ramblings.