It won't happen. With a flood of idiots making 'educational videos' looking to turn a quick buck, you're going to end up with a lot of nonsense. You won't find an accrediting body willing to overlook that.
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.
Innovating and coming up with clever solutions to complex problems is beyond most people
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?
but you can't equate that level of programming with modern software development.
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!
Do you honestly believe that such a proportion of people who make their living developing software are that bad at it purely because they're lazy, apathetic or unmotivated?
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.)
For the obligatory car analogy, most people are probably capable of learning to swap to a spare tyre, change the oil, or top up the radiator (learning some simple scripting). Most people are probably not capable of learning to design high-flow intake manifolds or variable valve timing mechanisms (useful commercial software development).
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
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.
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.
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.
Their developers already knew Java, since most of their code was Java,
You're just trolling now. At this point, we both know that isn't true. Insisting otherwise won't change history.
Instead they locked themselves out of the biggest market in the smartphone world.
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.
Being more or less absent from the market for several years was stupid
A good thing that never happened then!
So in the next year
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.
and their passport's weird screen size (1440x1440) is also a problem for many purposes, unless you like your videos letterboxed.
Not a deep thinker, eh? It's an excellent choice for their target market -- business users. Go ahead and read the reviews. You'll be amazed at how good the passport is at handling actual work. See, some people need a phone to do work, not play angry birds or watch movies on a tiny screen. (Who does that anyway?)
. It also would have been easier for them to port their existing software
You're joking, right? The little apps on the front end? There's a whole lot more to BB than brick breaker! Though even there your comment is foolish. Android's API was light-years behind RIM's. If you think it would have been "easier" for them to port their front-end apps you don't know much about Android or BB.
After all, it's not the superior OS that wins - look at Windows.
Sure. I can agree with that. Though I'm curious as to why you think people with superior products should toss them out because there exists a shitty, but popular, alternative? Should the guys at Bentley just close up shop because Toyota (or whatever) has the most popular car on the market?
Or would a computer analogy work better? Do you think that Apple should drop OSX and embrace Windows just because "it won"? Or do you think that such a decision would be unimaginably bad?
Slashdot Mirror
That's not an uncommon story...
As they complete exclusively with each other, I'd say that swift taking the 10 spot is unlikely without Objective C vanishing from use completely.
Hasn't that ridiculous rant been debunked to death yet? It's like the homeopathy of blog posts.
Groovy? I know it looked hot back in 2013, but that was the result of some foul-play. It has since dropped off the radar.
I honestly didn't know that anyone still cared about it.
I find the above more readable than
Sure, I can see that. But both are infinitely less readable than a for loop.
This. Even the antique version on my craptastic ZTE Open is like a breath of fresh air.
Hell, even if you don't like it, it's well-worth supporting. If Mozilla can do for the mobile OS landscape what they did for the browser we all win.
Switch to FireFoxOS, BlackBerry, or Windows Phone. Hundreds of users, myself included (BB10 & FFOS), couldn't be happier.
"It is a damn poor mind indeed which can't think of at least two ways to spell any word."
-- Andrew Jackson
It won't happen. With a flood of idiots making 'educational videos' looking to turn a quick buck, you're going to end up with a lot of nonsense. You won't find an accrediting body willing to overlook that.
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.
Innovating and coming up with clever solutions to complex problems is beyond most people
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.
but you can't equate that level of programming with modern software development.
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!
Do you honestly believe that such a proportion of people who make their living developing software are that bad at it purely because they're lazy, apathetic or unmotivated?
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.)
For the obligatory car analogy, most people are probably capable of learning to swap to a spare tyre, change the oil, or top up the radiator (learning some simple scripting). Most people are probably not capable of learning to design high-flow intake manifolds or variable valve timing mechanisms (useful commercial software development).
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
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.
You said they didn't know Java so that it wouldn't have been easier to switch to Android.
I said no such thing!
BES is not a "front-end app." So, you're totally wrong,
I never said it was.
Did you read anything I posted? Fucking troll
Blackberry and Java. So who's trolling now
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.
What is true OO
No one knows. Those who think they know all disagree with one another.
the OO design patterns people.
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.
Their developers already knew Java, since most of their code was Java,
You're just trolling now. At this point, we both know that isn't true. Insisting otherwise won't change history.
Instead they locked themselves out of the biggest market in the smartphone world.
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.
Being more or less absent from the market for several years was stupid
A good thing that never happened then!
So in the next year
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.
and their passport's weird screen size (1440x1440) is also a problem for many purposes, unless you like your videos letterboxed.
Not a deep thinker, eh? It's an excellent choice for their target market -- business users. Go ahead and read the reviews. You'll be amazed at how good the passport is at handling actual work. See, some people need a phone to do work, not play angry birds or watch movies on a tiny screen. (Who does that anyway?)
. It also would have been easier for them to port their existing software
You're joking, right? The little apps on the front end? There's a whole lot more to BB than brick breaker! Though even there your comment is foolish. Android's API was light-years behind RIM's. If you think it would have been "easier" for them to port their front-end apps you don't know much about Android or BB.
After all, it's not the superior OS that wins - look at Windows.
Sure. I can agree with that. Though I'm curious as to why you think people with superior products should toss them out because there exists a shitty, but popular, alternative? Should the guys at Bentley just close up shop because Toyota (or whatever) has the most popular car on the market?
Or would a computer analogy work better? Do you think that Apple should drop OSX and embrace Windows just because "it won"? Or do you think that such a decision would be unimaginably bad?