You're delusional. The BB10 UI was nearly universally praised. For multitasking, it's still unmatched. Its gesture suite, unlike iOS, is simple and intuitive.
It hides almost all functionally off the screen, under buttons in menus and side screens
With very few exceptions, 80's and 90's games are the only ones I play.
Really, anything made after 1977 is lame modern crap.
Fancy new games like NES Open Tournament are just pale imitations of games like Apawamis Golf on the PDP-10. If you thought Moral Combat was controversial, you haven't played Dr. Sluggo's Torture Chamber!
Did anyone ever make a sci-fi survival horror game that could compete with Jeff Shaevel's Chase?
It's rambling, obtuse, and pretty much incomprehensible. One can read it, but there's nothing of value to be obtained by reading it. [...] its lack of substance and insight, if not its outright incorrectness, means that reading it is a pointless activity.
Re:He's not "conceited". He's absolutely correct!
on
Is Ruby Dying?
·
· Score: 1
JavaScript is objectively a bad language.
Objectively, you say? Maybe you don't know what that word means.
Its object system is a joke (prototype OO is always inferior to class OO
Are you high? No one could possibly be THAT stupid.
Its comparison operators are broken.
Nope, they work just fine. Maybe you are that stupid...
For crying out loud, the most respected JavaScript book is Crockford's "JavaScript: The Good Parts". Almost the entire book tells you to not use significant features of JavaScript!
I see that you haven't read it. You should. You'll find it enlightening. Well, assuming you can work through it. You'll find code examples that use operators. You seem to have an awful lot of trouble with those.
A language divorced of the prototype hogwash and weird 'this' scoping of JS which causes (OOP headaches) would be nicer.
You're still trying to treat it like Java or C++. That "prototype hogwash" is undoubtedly the more powerful and flexible approach. The "weird 'this' scoping" makes perfect sense once you have a basic understanding of the language.
This is what Javascript was meant to provide to Java, hence it's name.
Wow, no. Not even close.
I probably shouldn't hold it against you. From the remainder of your post, it appears that you've cracked. Get some sleep.
You claim the patterns do not exist in the real world.
That's not what I'm claiming.
They provide plenty of examples with citations. That's the research you keep hallucinating the nonexistence of.
We've been over this. What do you think constitutes research? Put yourself in the authors position. You want to know if there are common solutions to common design problems. What do you do? You'll need a sample of computer programs to examine. How do you select that sample? You want to identify the design problems that appear most frequently, what is your methodology? How do you classify the solutions so that you can identify which solutions are common?
What if we go even simpler? Let's say you believe that you've identified a common solution to a common design problem. How would you test that?
What did the authors do?
I'd forgotten that bit to be honest. I also don't agree with that part. It's a book on design, not a religious text.
To the introduction. I've directed you to the introduction several times already. This should be clear from my previous post -- and several other older posts.
It's not long, it validates my claims, and (as you've seen) even directly contradicts a few of your points. It shouldn't take you more than a few minutes to read through the introduction.
Given some of your claims (like the "apply" bit from earlier), I'm not convinced that you've ever read the book you're defending. Perhaps you should reserve your opinion until you've read it yourself?
Patterns are not intended to do anything.... Many people (including you according to elements of your reply) seem to believe that patterns are things to be "applied"
From Page 1: "These patterns solve specific design problems" "...can apply them [patterns] immediately to design problems" Yes, the very first page.
From Page 3: "a pattern has four essential elements [...] The problem describes when to apply the pattern"
Have you read the book?
A pattern does nothing. It is not intended for anything. It is an observation of how people solve the same problem.
Some obvious facts: They didn't examine a large sample of programs (how were they selected?), identify common problems (using what methodology?) and how those problems were solved. They didn't compare their "patterns" to alternative solutions they would have found in their research to those common problems. (We don't even know if their nonsense "patterns" are the most common or even if they're comparatively good solutions!)
Why is this so damn difficult for you to accept? According to the book, even the authors don't disagree with me here! "Patterns" are not based on any actual research. (They're pretty up-front about that. This shouldn't be a contentious point!) This is what you don't like --> It's just wishes and good feelings from a few snake-oil salesman who seem to think that personal experience is superior to rigor.
Why don't you like that last bit? Because you're convinced that programming is (or can be) just like engineering. It's not, obviously, but a lot of people think it should be. Nonsense like "design patterns" appeals to you because it's a simple idea (people love simple ideas) that looks like it could turn software development in to a real engineering discipline. It's the exact same scam we've seen with countless other programming fads. It's doomed to failure, of course, as unlike data structures and algorithms, "patterns" are not language agnostic, nor are they subject to the same level of examination.
Well, they are common within the set of examples
Yes, you actually wrote that. I didn't make that up.
You seem to be confusing "evidence" with "conclusions you agree with"
What? I essentially said that a few anecdotes do not constitute evidence. (In context, they certainly aren't evidence that the authors based their "patterns" on actual research!) Again, If you'd like, I'll happily offer you numerous examples of where use of GoF "patterns" has been harmful. Would that convince you that GoF patterns are harmful? After all, they show a clear "pattern" of harm "common within the set of examples" I'll supply.
What would you do with that? For the sake of argument, let's say I provided you with a long, boring, post showing ten solid examples of where use each GoF pattern has been harmful (230 examples!) Would you say that I did research and was forced to conclude that use of design patterns is harmful? Or would you say that I went out and found a few examples to fit my pre-determined conclusion? (See, this isn't complicated.)
To my point, that the authors did not base their snake-oil on actual research, that's clearly an insufficient argument. For that, I'll direct you to the GoF book, which explicitly supports my claim that the authors based their nonsense on personal experience and not actual research.
In the intro they mention experience, in the book they actually provide evidence
No, they provide a few examples. That's not evidence. See, the examples are there to imply that these alleged "patterns" actually are common solutions to common problems.
There is no reason to believe that "patterns", by their definition, exist at all. There is no reason to believe that the "patterns" they present are representative. There is no reason to believe that the problems the "patterns" are intended to solve are common. (How frequently the problems appear) There is no reason to believe that the "patterns" are common solutions to said problems. (How often the "solutions" are used compared to alternatives)
All because no actual research has been done!
Of course, if you think a couple examples is sufficient evidence, I can happily provide you with numerous examples of how the use of GoF patterns is harmful. When you figure out why you wouldn't consider that "evidence" then you'll understand why the "evidence" you present isn't.
Your inability to comprehend the seemingly obvious isn't my problem.
You'll find that, upon competent examination, the claims I made are undeniably true.
I'm sorry that reality does not conform to your preconceptions.
you've asserted it without a shred of evidence.
It's all in the book. As I've pointed out, you've already offered substantial evidence in support of my assertions.
Hell, just read the introduction, which makes it clear that the nonsense "patterns" are based on personal experience, not actual research. Try reading the book instead of just reading about it on blogs and forums.
As I pointed out, your evidence isn't. Take a look at it yourself. Your "evidence" completely supports my earlier assertions! Go ahead and actually look at what you're offering as "evidence". You're in for quite a surprise.
It's not my fault that reality doesn't support your irrational beliefs.
Slashdot Mirror
You're delusional. The BB10 UI was nearly universally praised. For multitasking, it's still unmatched. Its gesture suite, unlike iOS, is simple and intuitive.
It hides almost all functionally off the screen, under buttons in menus and side screens
WTF are you talking about?
Smells like bullshit to me. What do you think?
No. "god does not exist" is indeed an assertion. It is not "the null hypothesis". Learn basic statistics.
I see that you don't understand basic science. I'm so very sorry about that.
If you weren't a moron, you'd know the "burden of proof" lies with whomever is making the assertion.
Not even a good troll.
I wouldn't say that. Judging from the number of replies, I'd say that he was very successful.
After reading the Darwin-bait summary? Don't worry, I'm certain you're not alone.
What could go wrong?
I suspect that we'll read about more than one actualized possibility over the next few weeks.
we can HOPE for reason to prevail
Reason doesn't even prevail in skeptical and rationalist communities. Be reasonable here.
Wait a minute. I know that guy! I hired him because 100% of the time, the code he had written was 100% correct.
Let's just say that you should have killed him.
If you're just being sarcastic, you should know that there's a patch available.
Er, the "the blood sucking scum called Hollywood" has already pissed all over Sherlock Holmes. I don't see how this changes anything.
With very few exceptions, 80's and 90's games are the only ones I play.
Really, anything made after 1977 is lame modern crap.
Fancy new games like NES Open Tournament are just pale imitations of games like Apawamis Golf on the PDP-10. If you thought Moral Combat was controversial, you haven't played Dr. Sluggo's Torture Chamber!
Did anyone ever make a sci-fi survival horror game that could compete with Jeff Shaevel's Chase?
they can be hipsters with good taste
Wait, if they have good taste, would they still be hipsters?
It depends. Do you want your children living in your basement 40 years from now?
It's rambling, obtuse, and pretty much incomprehensible. One can read it, but there's nothing of value to be obtained by reading it. [...] its lack of substance and insight, if not its outright incorrectness, means that reading it is a pointless activity.
JavaScript is objectively a bad language.
Objectively, you say? Maybe you don't know what that word means.
Its object system is a joke (prototype OO is always inferior to class OO
Are you high? No one could possibly be THAT stupid.
Its comparison operators are broken.
Nope, they work just fine. Maybe you are that stupid...
For crying out loud, the most respected JavaScript book is Crockford's "JavaScript: The Good Parts". Almost the entire book tells you to not use significant features of JavaScript!
I see that you haven't read it. You should. You'll find it enlightening. Well, assuming you can work through it. You'll find code examples that use operators. You seem to have an awful lot of trouble with those.
A language divorced of the prototype hogwash and weird 'this' scoping of JS which causes (OOP headaches) would be nicer.
You're still trying to treat it like Java or C++. That "prototype hogwash" is undoubtedly the more powerful and flexible approach. The "weird 'this' scoping" makes perfect sense once you have a basic understanding of the language.
This is what Javascript was meant to provide to Java, hence it's name.
Wow, no. Not even close.
I probably shouldn't hold it against you. From the remainder of your post, it appears that you've cracked. Get some sleep.
You claim the patterns do not exist in the real world.
That's not what I'm claiming.
They provide plenty of examples with citations. That's the research you keep hallucinating the nonexistence of.
We've been over this. What do you think constitutes research? Put yourself in the authors position. You want to know if there are common solutions to common design problems. What do you do? You'll need a sample of computer programs to examine. How do you select that sample? You want to identify the design problems that appear most frequently, what is your methodology? How do you classify the solutions so that you can identify which solutions are common?
What if we go even simpler? Let's say you believe that you've identified a common solution to a common design problem. How would you test that?
What did the authors do?
I'd forgotten that bit to be honest. I also don't agree with that part. It's a book on design, not a religious text.
We may agree more than we disagree.
To the introduction. I've directed you to the introduction several times already. This should be clear from my previous post -- and several other older posts.
It's not long, it validates my claims, and (as you've seen) even directly contradicts a few of your points. It shouldn't take you more than a few minutes to read through the introduction.
Given some of your claims (like the "apply" bit from earlier), I'm not convinced that you've ever read the book you're defending. Perhaps you should reserve your opinion until you've read it yourself?
[citation needed] ... You love clipping out actual quotes except to suport your main point.
If you can't be bothered to read the book you're defending, at least take the few minutes it takes to read the introduction.
I've directed you there several times already.
Patterns are not intended to do anything. ... Many people (including you according to elements of your reply) seem to believe that patterns are things to be "applied"
From Page 1: "These patterns solve specific design problems" "...can apply them [patterns] immediately to design problems" Yes, the very first page.
From Page 3: "a pattern has four essential elements [...] The problem describes when to apply the pattern"
Have you read the book?
A pattern does nothing. It is not intended for anything. It is an observation of how people solve the same problem.
Some obvious facts: They didn't examine a large sample of programs (how were they selected?), identify common problems (using what methodology?) and how those problems were solved. They didn't compare their "patterns" to alternative solutions they would have found in their research to those common problems. (We don't even know if their nonsense "patterns" are the most common or even if they're comparatively good solutions!)
Why is this so damn difficult for you to accept? According to the book, even the authors don't disagree with me here! "Patterns" are not based on any actual research. (They're pretty up-front about that. This shouldn't be a contentious point!) This is what you don't like --> It's just wishes and good feelings from a few snake-oil salesman who seem to think that personal experience is superior to rigor.
Why don't you like that last bit? Because you're convinced that programming is (or can be) just like engineering. It's not, obviously, but a lot of people think it should be. Nonsense like "design patterns" appeals to you because it's a simple idea (people love simple ideas) that looks like it could turn software development in to a real engineering discipline. It's the exact same scam we've seen with countless other programming fads. It's doomed to failure, of course, as unlike data structures and algorithms, "patterns" are not language agnostic, nor are they subject to the same level of examination.
Well, they are common within the set of examples
Yes, you actually wrote that. I didn't make that up.
You seem to be confusing "evidence" with "conclusions you agree with"
What? I essentially said that a few anecdotes do not constitute evidence. (In context, they certainly aren't evidence that the authors based their "patterns" on actual research!) Again, If you'd like, I'll happily offer you numerous examples of where use of GoF "patterns" has been harmful. Would that convince you that GoF patterns are harmful? After all, they show a clear "pattern" of harm "common within the set of examples" I'll supply.
What would you do with that? For the sake of argument, let's say I provided you with a long, boring, post showing ten solid examples of where use each GoF pattern has been harmful (230 examples!) Would you say that I did research and was forced to conclude that use of design patterns is harmful? Or would you say that I went out and found a few examples to fit my pre-determined conclusion? (See, this isn't complicated.)
To my point, that the authors did not base their snake-oil on actual research, that's clearly an insufficient argument. For that, I'll direct you to the GoF book, which explicitly supports my claim that the authors based their nonsense on personal experience and not actual research.
In the intro they mention experience, in the book they actually provide evidence
No, they provide a few examples. That's not evidence. See, the examples are there to imply that these alleged "patterns" actually are common solutions to common problems.
There is no reason to believe that "patterns", by their definition, exist at all.
There is no reason to believe that the "patterns" they present are representative.
There is no reason to believe that the problems the "patterns" are intended to solve are common. (How frequently the problems appear)
There is no reason to believe that the "patterns" are common solutions to said problems. (How often the "solutions" are used compared to alternatives)
All because no actual research has been done!
Of course, if you think a couple examples is sufficient evidence, I can happily provide you with numerous examples of how the use of GoF patterns is harmful. When you figure out why you wouldn't consider that "evidence" then you'll understand why the "evidence" you present isn't.
Your inability to comprehend the seemingly obvious isn't my problem.
You'll find that, upon competent examination, the claims I made are undeniably true.
I'm sorry that reality does not conform to your preconceptions.
you've asserted it without a shred of evidence.
It's all in the book. As I've pointed out, you've already offered substantial evidence in support of my assertions.
Hell, just read the introduction, which makes it clear that the nonsense "patterns" are based on personal experience, not actual research. Try reading the book instead of just reading about it on blogs and forums.
As I pointed out, your evidence isn't. Take a look at it yourself. Your "evidence" completely supports my earlier assertions! Go ahead and actually look at what you're offering as "evidence". You're in for quite a surprise.
It's not my fault that reality doesn't support your irrational beliefs.