http://news.netcraft.com/archives/2005/07/04/php_blogging_apps_vulnerable_to_xmlrpc_exploits.html
single quotes? whodathunkit?
>>110
most unix users do, and since unix was written for unix users, it's entirely appropriate that it be case sensitive, as unix users expect. thanks.
> normal
yeah we're freaks, ok so what. welcome to /code/.
This is a list of words that have several unrelated meanings, where one of the meanings happens to traditionally have different casing than the others. These are two different issues that happen to coincide, neither of which implies that the English language itself is case sensitive.
Just because you've gotten used to something, does not mean that that is a good state of affairs. One of Unix' biggest HCI shortcomings is its case sensitivity. I'll also note that Mac OS X has wisely removed this limitation.
>>113
gotten used to it? how, exactly, do you determine from your end of the interweb that i, personally, have "gotten used to it", as distinct from having "found that the way unix does things fits my brain well"?
remember, once upon a time, someone sat down and decided that unix was gonna be case sensitive; to that person, the most natural interface was one in which case distinctions were important. it's awfully patronising of you to suppose that that person didn't know wtf they wanted or needed.
but your original point was that "normal" people don't think this way. i'm refuting your misconceived idea that everyone who touches a computer fits your norm.
Unix was designed when processing power was really, really scarce. Case-sensitive matching is cheaper than case-insensitive matching, both in terms of time and code size. For a primitive system, case sensitive is the default choice. Doesn't mean it's the right choice on a more capable system, though.
PS: How are you refuting my argument? Did you quote any statistics or other facts that show that most people think case sensitivity makes sense?
> Did you quote any statistics or other facts that show that most people think case sensitivity makes sense?
Did you quote any statistics or other facts that show that most people don't think case sensitivity makes sense?
I, for one, think that case insensitivity is quite hard to get one hundred percent right even/especially nowadays.
"Because of IRC's scandanavian origin, the characters {}| are
considered to be the lower case equivalents of the characters []\,
respectively. This is a critical issue when determining the
equivalence of two nicknames."
As for personal preference, I pretty much don't care either way. I haven't ever had any problems with case-sensitive systems (I kind of mostly use the right case anyways, might have something to do with my first language beeing German), some slight problems on case-insensitive ones (When copying files over from a case-sensitive one). For me, case sensitivity doesn't really change usability, and I would suspect it's the same for most users.
Case closed.
Regrettably, this doesn't extend to the applications.
>>118
Um... yeah... what?
I used case-sensitive CLI's and case-insensitive CLI's, and I prefer neither.
Personally I use uppercase to distinguish some files/directories from others (I tend to work in a *nix CLI), mainly so the uppercase show up higher in listings. I like the side benefit that if I type "C<tab>" the shell knows to expand "Cool/" instead of "code/", if I type "r<tab>" it knows to expand "random.c" instead of "README", and so on. I'm not dogmatic on the matter but I find case-sensitive names slightly more useful for my purposes, because of this.
> but your original point was that "normal" people don't think this way. i'm refuting your misconceived idea that everyone who touches a computer fits your norm.
> PS: How are you refuting my argument? Did you quote any statistics or other facts that show that most people think case sensitivity makes sense?
I don't think any "statistics" or "other facts" about "most people" are at all relevant here. please actually read, understand, and think about what i'm saying here, instead of merely assuming that i'm arguing the point you seem to think i'm arguing (hint: i'm not). thanks.
Why don't you just spell out what you're trying to say? Because it is anything but clear.
I've already explained it two or three times. If you can't put down your preconceptions and actually read what I've previously said, me saying it again is hardly going to help any.
$age = stripslashes($age);
mysql_query("UPDATE foo SET age='".mysql_escape_string($age)."' WHERE id='$id'");
huh?
$age = round($age);
$id = round($id);
mysql_query("UPDATE foo SET age='$age' WHERE id='$id'");
Because obviously all data ever sent over the net is integers. Thanks for clearing that up for us.
>>124 Yeah I get it, but your wrong. Actually nether one is right because you're not doing any validation.
if(is_numeric($age) && is_numeric($id)){
if(!mysql_query("UPDATE foo SET age='$age' WHERE id='$id'"))
die ("Error: ".mysql_error());}
else
die ("Age and id must be numbers.");
And even then you're still wrong because who is going to let the user enter any ID number and change the value?
WHERE id='$id' and memberid='".$_COOKIE['memberid']."'
And even then you're STILL wrong because $_COOKIE isn't safe.
But, if done right php can be safe and secure. And if done wrong perl or python or anything else can be insecure.
Yahoo, YouTube, Digg, FaceBook, Wikipedia, Friendster, Photobucket and TONS of other high profile sites use PHP as either there main programming tool or use it extensively. I mean come on... Yahoo uses it and they are #1...
I do believe that PHP-coders are dumb, not all of them of course but simple abstract languages like PHP are creating dumb programmers.
They don't understand the basics of programming and never will if they continue to use only abstract languages.
They need to understand that abstract programming is more like scripting, because you're actually telling an interpreter someone else wrote how to produce bytecode or direct native code.
Until they learn how to write an interpreter of their own, they will never truly understand programming.
> simple abstract languages like PHP are creating dumb programmers.
I don't consider PHP a particularly abstract language. Ignoring that though, do higher-level languages make a person more stupid, or free them from silly minutiae to consider even higher-level concepts? Listen to Lisp or Haskell programmers some time.
> Until they learn how to write an interpreter of their own, they will never truly understand programming.
Absolutely, but you know, the same could be said for assembly programmers too.
> do higher-level languages make a person more stupid, or free them from silly minutiae to consider even higher-level concepts?
higher-level languages don't make them stupid. not learning lower-level langauges does.
it's also true if you swap "higher" and "lower".
>>129
Yeah well i'm not all up on the terms used today, i didn't even know what an abstract language was until last week when a java programmer explained it to me.
Of course abstract programming gives you more time for other things but you have to take the good with the bad and you have to recognize the bad.
Basically you give up control in return for speed and usability. You might call me an old fart but it's my opinion that usability is not something you should buy for the price of control over your programs execution, not as a true programmer.
That's the main thing there, to differ between scripters and programmers. To me a scripter gives up control to another persons program while a programmer tells the system he's programming what to do and how to do it.
It all boils down to this, lazy programmers. We're all getting lazier by the generation and why should IT be any different? It's not, lazy programmers are what started some of our biggest break throughs but they are not so fun if their abstract languages create generation after generation of programmer that doesn't understand what she's doing.
It all depends on what you want to do in your life, if you want to create webpages and software in java while saving a ton of time then be my guest. But what if you want to be the one creating an abstract language, an interpreter or maybe a compiler. You need a language that would be beyond you. So basically, PHP is a tool with it's own purpose that it might do very well but you will never build a house with one tool.
I'm pretty sure that "abstract language" doesn't mean anything.
http://www.dangermouse.net/esoteric/piet.html is an abstract language.
> it's my opinion that usability is not something you should buy for the price of control over your programs execution
I disagree. Languages are just another user interface, and should be made as easy as possible. More done in less time, with fewer bugs, higher maintainability and less aggravation.
Why should I spend all my time worrying about low-level issues when it's only something to be concerned about a small minority of the time? For that small minority of time there's usually a hatch (C API or FFI) I can use.
Some domains require the degree of control C offers all the time. That's okay too.
> It all boils down to this, lazy programmers
Laziness is a virtue, &c.
More seriously, why would you use a low-level language when a high-level language could get it done in a quarter the time or less?
> But what if you want to be the one creating an abstract language, an interpreter or maybe a compiler. You need a language that would be beyond you.
You don't need a low-level language to write an interpreter. You don't need to know a low-level language to write a compiler either. It just helps if you want it to go faster or not use some intermediary language on the way to native.
>>127
That's still crappy.
You should use "UPDATE foo SET age=? WHERE id=?" and then set the parameters.
Two reasons:
> I disagree. Languages are just another user interface, and should be made as easy as possible. More done in less time, with fewer bugs, higher maintainability and less aggravation.
Using an "easy" language doesn't automatically make your code have fewer bugs. It makes the bugs harder to notice, which will probably make your code have more bugs.
Not if that "easy" language is CL.
>>136
I find that reasoning suspect. If it were true, we should have never left entering machine code with switches.
Using functions is easier than manually constructing stack frames. Using automatic memory management is easier than manual. Using Pascal-style strings is easier than C-style. Using built-in associative arrays is easier than rolling your own. Using polymorphism is easier than tables of function pointers. Using closures is easier than writing classes with single methods. Using coroutines is easier than allocating your own stacks and longjmp()ing. Using messages is easier than juggling locks. You get the idea.
Every abstraction removes some cruft that you used to worry about. What was once complicated becomes easy. Imagine writing Prolog-style backtracking or cooperative multitasking in C; in some higher languages it's close to "Hello World".
That being said, removing cruft you need to worry about doesn't remove the need for someone to worry about it.
The use of many higher level languages ultimately becomes an exercise in working around bugs in the runtime which you can't easily fix yourself.
>>139
It's not too bad if you choose a nice, fresh language like Python or Ruby. Java is shit, .Net is less so when it comes to bugs.
I have heard more than one LISP advocate state such subjective comments as, "LISP is the most powerful and elegant programming language in the world" and expect such comments to be taken as objective truth. I have never heard a Java, C++, C, Perl, or Python advocate make the same claim about their own language of choice.
> That being said, removing cruft you need to worry about doesn't remove the need for someone to worry about it.
Exactly. It's better that the wheel be only written once. It's for a similar reason we have libraries.
> The use of many higher level languages ultimately becomes an exercise in working around bugs in the runtime which you can't easily fix yourself.
Except that you're not alone. If you start implementing all this on your own, you are. There is power in numbers.
That's true too, but it doesn't make Sun fix bugs in Java any faster. :-)
Perhaps you should not be judging the entirety of the world of programming based on Java.
I ought to add that I cannot take seriously languages -- or libraries -- that do not have a de facto implementation which is OSS.
Well-known languages that fail this criteria: Java, C#, VB, the Lisps (although SBCL looks like it'll fix that), PL/SQL, ABAP.
If a business wants to tie their infrastructure to something over which they have no control, the managers are incompetent. It amazes me how many large corporations are more than happy to hand over the keys to their kingdom, so to speak.
OpenJDK and Mono. VB does blow chunks, though; and companies who would gladly give M$ all of their revenue in exchange for empty promises of security rather than taking matters into their own hands are not worth my time.
A lot of programming security depends on skill; a top-notch PHP hacker can block anything from a simple single-quotes exploit to a full-blown MySQL injection. Of course, a top-notch hacker can also circumvent them as easily as he can block them, but a novice trying and failing to implement security is worse than an intermediate programmer not bothering to try to implement security. And depending on who you're up against, there are some cases where you're boned anyway, but those are rare.
> OpenJDK and Mono.
Mono is not the de facto implementation.
OpenJDK has promise if they can wrestle control of the libraries and language from Sun. Does Sun work on the same repository as everyone else?
OpenJDK development is still managed by Sun. All they've done is moved all the code to a place where more people can play with it, and changed the licence to GPL.
There are other open source Java runtimes though. GCJ / GNU Classpath comes to mind (GCJ can compile Java to native code too!) And there was an Apache implementation which I have forgotten since OpenJDK would more or less obsolete it.
> A lot of programming security depends on skill
But a beginner writing in PHP has a much larger probability of coding up an SQL exploit than a beginner writing in Perl or Python. That is the real issue. It's not about what you can do, it's about what happens in practice.
Why is that? Is it because SQL is more accessible to the PHP programmer? Or is it because Perl and Python are harder to use?
A lot of programming security depends on solid engineering and well-thought out designs. The best PHP programmers think that they just need to be more careful, but even if the PHP programmer writes perfect code, the people who write PHP itself are incapable of writing perfect code- look at the last few releases of PHP, the same security bug being "fixed" over and over again.
Almost all of these bugs are from extensions- things that are for some reason, better to write in any language but PHP than to write them in PHP itself. Why is that? Why is the bulk of any PHP application written in any language but PHP? What is it about PHP that makes it so difficult to express things like money_format() or glob() in PHP? Why do PHP programmers need to resort to such an ugly language as C in order to get any real work done?
>>150
Because, it's damn easy to forget to mysql_real_escape, but it's damn hard to get "SELECT foo FROM table WHERE bar = ?" or something similiar wrong. PHPs standard way of accessing databases is just plain shitty.
I'd like to here more about PHP please.
Why is it so awesome?
>hear
Those are the reasons one might consider it to be “awesome”. We all know and are bored of hearing why one might also consider it “fucking horrible”. The above reasons also make it similar to C and C++.
Hay, I resent the implication that C is somehow similar to PHP! (,ﾟДﾟ)
>Applications : New
>There are not any applications in this category.
>
>Maybe you'd like to add one?
lol not really