Comment Re:One page book (Score 1) 155
Not quite what I meant -- see my other reply. Apparently I can't communicate ideas today.
Not quite what I meant -- see my other reply. Apparently I can't communicate ideas today.
So does using the "but everyone else is doing it" argument.
That's not the argument I'm making
PHP is ubiquitous. That's certainly an advantage as far as maintaining it's share of the web. However, that didn't happen overnight. PHP is ubiquitous today because it did the job it was designed to do better than competing languages. This is still true today, as evidenced by several "superior" fad-languages failing to gain any ground. If PHP was garbage that no professional would touch, it couldn't have possibility achieved such an astonishing share!
You can criticize any language you want. With enough effort, you can make C appear to be the worst language ever improperly designed. (Just poke around the usenet archives and you'll see what I mean.) PHP has it's share of warts, no question, but it's not the worthless pile of garbage that language snobs have made it out to be.
Really the biggest problem with PHP is not the language itself, however, it's all the bad information out there about how to use it.
You'll find that's true of all popular programming languages. (You should see the nonsense out there about JavaScript -- written by respected professionals!) Though I'll admit that it might be a bit worse for PHP due to the large number of beginners the language attracts due to it's astonishing ease-of-use.
Really, I think that ease-of-use is exactly why we see so many "PHP is garbage" comments on forms like this. Developers are (undeservedly) considered by the general public to be brilliant-- a bit like MD's. The difference, of course, is that anyone can become a computer programmer in their spare time -- even children. Hell, I'll bet that the majority of Slashdot users were writing games for their home micro before the age of 12. It's an easy skill to learn -- and everyone developer knows it. Being insecure, the last thing they want is some easy language out there that's easy to learn and use. If their little secret got out, no one would think they were brilliant! They'd just be another nobody -- their worst fear!
Languages like PHP are a huge threat to those insecure developers. I'm not surprised that they bash it at every opportunity.
Yeah, only idiots use PHP -- that's why it's only used by 80% of the web.
Language snobbery benefits no one. Unless you're Chuck Moore, it also makes you look like an idiot who can't form their own opinions.
Indeed. GOTO is not inherently evil. You'll find it used appropriately in some surprising places -- including the Linux Kernel.
When describing a process, the oft-maligned GOTO certainly comes in handy. The over 30 crowd might remember seeing GOTO's in any number of guide books from auto repair to taxes. (The word wasn't always used, sometimes "skip to
That's right: GOTO can actually make things easier to read and understand.
Even in software today, I'm willing to bet even the most ardent anti-GOT zealot has used a GOTO -- and recently at that -- cleverly disguised as a break or return statement.
You claim OOP isn't defined when it is
No, I said that there was no consensus on the definition. That is true. Indeed, it's indisputable! You seem to like wikipedia, so you can check there. I did a quick google seach for you and found a few neat discussions that may be helpful for you.
, you claim it's just how closures work and C# works the same whilst demonstrating how Microsoft have fixed the very problem because it is a language problem
Pay attention. Microsoft changed how foreach works, not how for works. Your example deals with for loops. You'll find that my statement is correct.
Additionally, you should consider what a similar "fix" for the non-problem in for loops would entail, and why the behavior of for remains the same.
That's all irrelevant, however, as the problem the poster had in the example you gave was a simple misunderstanding of how closures work. It's not a language design issue.
the fact you're entirely unaware of the problems in it's equality operators shows how painfully little knowledge you have.
Pray tell, then. What are the problems? (I've explained why NaN!=NaN already. See IEEE 754 if you forgot) If you're talking about things like intransitive equality, you're just confused. You'll find identical behavior in virtually every other language. Not just those with dynamic typing -- recreate the examples you found in some blog post in Java or C, applying relevant type casts. Look at that! The behavior is the same!
Now, you're welcome to list which type conversions you find irrational, though once you look, you'll find they're all perfectly sane. It behaves exactly as you would expect from experience with your exemplar languages.
you don't understand why unnecessarily verbose code leads to more bugs
Check my post again. I agreed with that specifically. I also challenged you on Java (one of your exemplars) as it is unnecessarily verbose! JavaScript and PHP are positively terse in comparison.
I will offer, for your consideration, that unnecessarily terse code also is less readable, often leading to more bugs and making maintenance difficult.
Moving on. I find it odd that in response to evidence that directly contradicts your claims, and which support my own, you offer only bold assertion.
I asked you some very simple questions so that you could make a stronger case. (Well, to let you actually make a case!) If I'm wrong about something, I like to know. I'm disappointed that you'd rather insult me than actually discuss the issues.
This whole dialog started with your objection to some simple advice I offered another user: don't use JavaScript like it's a class-based OO language. I still don't know why you found that unreasonable, as JavaScript is prototype-based. (There's a paper you might find instructive here: D. Ungar & R. B. Smith (1987) "Self: The Power of Simplicity", OOPSLA '87 Conference Proceedings, pp. 227-241)
Anyhow, with this post I've left you with some reading and experimenting to do. Give it a go and let me know the results. I expect that you'll be unpleasantly surprised.
No it isn't indisputable fact, and where it's "established" in literature that literate is rather old and dated
So we should toss out relativity and quantum mechanics as well, eh? (Old doesn't mean invalid.) Put that ACM DL subscription to good use. You shouldn't have too much trouble finding more modern if that's important to you.
The arguments made a bit more sense when keywords like protected weren't implemented, or were implemented poorly
Again, you don't understand the problem. It's a fundamental problem, not something that can be fixed by adding a few language features!
Compare and contrast this to the original argument that Javascript does not properly implement OO and is badly designed as a result
A couple things: 1) There is no such thing as "proper" OOP. There is no consensus on the definition. 2) You have not established that JavaScript "does not properly implement OO" As I explained earlier, it's prototype based, not class based -- like several other languages. It's not bad simply because you don't like it.
I've explained twice why inheritance doesn't inherently have to break encapsulation in well designed languages
The problem is that your explanations don't actually address the issue at all! Again, it's fundamental -- this is very well established in the literature. It's not magically changed simply because a book you found on wikipedia and the paper I offered were older. Put that ACM DL subscription to use and find something to make your case -- you'll find that it's indisputable: Inheritance breaks encapsulation.
An example of a design flaw is PHP's === equality operator not working consistently and it's == operator not being transitive. There's not excuse for this
Assuming you're talking about the NaN thing from before, you'll find that it's a natural consequence of IEEE 754 -- and that that behavior is correct and expected in all languages. (Seriously, it's in the damn standard.) If you're speeking more generally, you'll find that PHP's == and === operators do indeed work consistently, behaving like similar dynamically typed languages. (Go ahead and try out some of the examples you found of "inconsistency" online in C, with explicit casts and you'll find the behavior is identical. Don't like C? The same will hold for Java as well.)
One language is better than another if it has less design flaws
That's not an answer to the question. What are these "design flaws"? How can they be identified?
The required additional syntax to create a new scope to make this work is nonsensical and a result of the lack of foresight in the language's design
No, the problem was that the stackoverflow posted doesn't understand closures. You'll find the EXACT same behavior in C# -- one of your exemplar languages. In fact, this confusion over closures lead Microsoft to change the behavior of foreach loops!
It's not an issue of language design, it's just how closures work. (Imagine how bizarre and unexpected the behavior of for loops would be if MS decided to change their behavior to match that of foreach!)
Surely you must at very least understand that simplified and more readable syntax to solve an identical problem is both better for developer efficiency and is better for supporting less buggy software.
Readability is important. I couldn't agree more. However, in the example you gave, C# behaves just like JavaScript. It's not a language design problem. It's not a problem at all. It's just how closures work.
I hope you can finally grasp why unnecessarily verbose code to solve simple problems resulting from lack of foresight during language design is a bad thing.
Now we've got to the meat. Is this what constitutes bad design in your eyes? Simply unnecessarily verbose code to solve simple problems? Should we all switch to Forth? Java is particularly verbose -- is it badly designed? You held it up earlier as an exemplar.
That's a relief. I was worried about lamp-wielding caddies terrorizing the back nine.
So... It's a bad idea to play golf?
Wrong.
No, it's true. Inheritance breaks encapsulation. This is a indisputable fact. It's VERY well established in the literature. The problem, it seems, is that you simply don't understand what that means. Do you have an ACM DL subscription? If not, get one. You'll find plenty has been written about that very subject.
That's exactly the point, just as with Javascript they don't slog through them, they're just not even aware of them and as a result they write wrong code, buggy code, vulnerable code.
Have any evidence? Because I don't think you do. (I think you're making this up as you go along.) Where's the research? Make use of your ACM DL subscription.
That's not fair. I know you can't actually produce anything like that. How about some specific examples like I asked for in an earlier post? Surely, you have something specific in mind?
Now, I will agree that people don't use JavaScript correctly. That was the point of my first post. The problem isn't the language, of course, but people trying to use the language like it's a class-based, not prototype-based. Once you learn the language, you'll find that there's nothing wrong with it. There are no "quirks", as you like to say, it's just different. Give Scheme and Forth a go and you'll find they're just as different, but not poorly designed in any way. (The difference? You can't pretend that Scheme and Forth are just like Java and C# like you can with JavaScript. If there's any problem with JavaScript, it's that the familiar syntax makes naive developers think that there's nothing new to learn.)
More buggy than an equivalently skilled developer would produce with better designed languages
Again, what makes a language poorly designed? What makes a language "better designed"? Is there some ultimate ideal language design? I still don't think you've thought this through.
instead quoting lines from books that are now nearly 20 years old
I did no such thing! (I actually had a much older paper in mind when I told you that inheritance breaks encapsulation.) You had never heard of such a thing and did a google search (as I asked), landing on Wikipedia, where you learned that the subject was mentioned in the GoF book.
you're obviously not willing to learn enough about this topic to have a rational conversation
I'm not willing to learn?!
How about answering the very basic questions about your assertions? Asking questions shows a willingness to learn, doesn't it? I've not asked any difficult questions, after all. If you want me to learn, surely you could take the time to answer them, or at least direct me to the relevant research from which I'm sure you've formed your opinions?
You're not just repeating empty platitudes, right?
That you don't know much about language paradigms? The problem is that the three pillars of OOP are inheritance, encapsulation, and polymorphism. In Javascript you can't do inheritance without sacrificing encapsulation
Umm... Inheritance is fundamentally incompatible with encapsulation. This isn't exactly a big secret. Google "inheritance breaks encapsulation".
The fact you believe PHP has no underlying quirks that are a result of bad language design and that must be learnt to use even the base language properly without introducing faults speaks volumes
Well, what are they? (Dare I ask after your failure to do the same for JavaScript?) One of the greatest strengths of PHP is that it is incredibly simple to learn and use. What are these mysterious quirks that millions of amateurs are apparently willing to slog through learning before hacking out yet another home-grown CMS?
not have poor design traits that result in inherently more buggy software at all skill levels. Javascript has all too many of those, and that's the problem.
What are these so-called "poor design traits that result in inherently more buggy software". More buggy that what?
I don't think you've thought this through.
Hint: It doesn't matter if learning the language let's you work around these things, the fact I highlighted them demonstrates precisely that I do know the language,
As I pointed out, Your "points" 1 and 4 show that, in fact, you don't understand the language. (This statement isn't even coherent: "This is a relic of the fact that Javascript wants to be both OO and Prototype based". What other conclusion could I draw?)
Points 2 and 3 clearly shows that you don't understand the scoping rules. Once you actually learn the language it becomes clear that there are no issues to "work around". The rules are simple and clear. There are no inconsistencies. Though it looks like you want to introduce some...
Why in a code block like a function would you ever want a variable to become global by default? This is kludgy, it would've been better to only go global if you explicitly declare global.
If you understood the very simple rules, you'd know exactly why that happens. You'd also understand why it would be "kludgy" (inconsistent) to make it work like you suggest!
A good, well designed language, doesn't require you to take extra steps to "learn the language" beyond the concepts necessary to use it at a base level, Javascript does (and so do languages like PHP) and that's exactly why it's kludgy.
Here's something fun: PHP perfectly fits your criteria for a "good, well designed language" as it "doesn't require you to take extra steps to 'learn the language' beyond the concepts necessary to use it at a base level". Why, it's even a better fit than your exemplars: Java and C#.
That's embarrassing!
Here, I'll give you a chance to redeem yourself: Following your newly revealed definition for "good, well designed language" how does JavaScript fail to meet your criteria that would not also disqualify languages that you consider well-designed like Java and C#?
Good luck.
No, the constitution recognizes the need for a regulated militia and the right of the people. Otherwise:
1. It would be self contradictory, since regulating your militia is, in turn, regulating arms, which the text says shall not be infringed
2. It wouldn't be located next to the third amendment, which also puts the freedom of the people over soldiers of the union
3. It would be unique, as the fifth amendment also refer to the militia as external to the people
4. It would be misplaced, as rights specifically granted to a government entity (states) that wasn't already addressed in the articles is all the way in the back at amendment ten
5. It would be redundant, since the military is already presumed to exist as in Article 2
Anyone can argue whether they like it or not, but the fact is the second amendment, quite clearly, refers to the right of the people. Anyone claiming otherwise is mistaken at best and selectively manipulative at worst.
This is an absolutely brilliant post. Clear and concise.
1) You say stop trying to use it like an OO language yet the language supports OO features badly.
No, I said to stop treating it like a class-based OO langauge. JavaScript's objects are prototype-based. Just because you don't understand it doesn't mean it's bad. Try learning the language before you complain about it.
2) If you don't prefix a previously unused variable it goes into the global scope. What. The. Fuck.
Try learning the scoping rules. It makes perfect sense.
3 try learning the language.
4 is advice given to you by someone else who doesn't understand JavaScript, and also shows clearly that you don't understand 1.
5 Possibly your only legitimate complaint. Just use semicolons all the time, problem solved. Why you don't find similar complains about optional brackets in JS, C, etc.? All the same complaints apply.
7 is unsubstantiated nonsense.
8 Perhaps you don't know what NaN means? (Hint: NaN is a value, not a type) You'll find that in Java, Python, etc. NaN==NaN returns false as well.
Need I go on?
Please don't.
despite it's prevalence one simply cannot argue that it's a "good" language
You might want to learn the language before you make such a pronouncement.
Do you have any actual reasons or are you just parroting what you think "smart people" are supposed to believe?
JavaScript is kludgy?
Stop using jQuery and stop trying to force JavaScript to act like a class-based oo language. That should fix most of your JavaScript complaints.
It is easier to write an incorrect program than understand a correct one.
