http://news.netcraft.com/archives/2005/07/04/php_blogging_apps_vulnerable_to_xmlrpc_exploits.html
single quotes? whodathunkit?
>>56-57
i would tell them about it, but...
http://www.64bit-world.com/modules.php?modid=4
and i was also unable to figure out how to post on their forum... kept giving me some nonsense about "You are not logged in" and "The administrator may have required you to register before you can view this page."
Send it to webmaster@64bit-world.com and maybe a few made-up names @64bit-world.com (since IPS often redirect it)? Use a throwaway mail account if you do, though, people who keep such pages live may not understand you're doing them a service by notifying them.
Thanks all
>>62
You're welcome :)
> vBulletin Message
> No Thread specified. If you followed a valid link, please notify the administrator
lol, how nice of them.
>>61
lol, they fixed dis, but forgot about www
http://tinyurl.com/75k8f
In response to topic. Duh.
When following design patterns like Model-View-Controller (MVC) in PHP, it is important that the the HTML View code is well separated from control code. I see most people doing this using a template system like smarty. But can template systems become bloated and effect performance?
I like to use the PEAR libraries (http://pear.php.net/) as much as posable for their stability and easy to use APIs. However, PEAR does not seem to have a fully featured template system that works well with other PEAR components like HTML_QuickForm and DB_DataObject.
Can anyone suggest the best template system to use with PEAR for building web apps?
PHP is the best templating language you could use with PHP. Bad template systems make it harder to get stuff done, and great ones merely make it more complicated, error-prone, and require to learn yet another language.
Well, one of the many advantages of using a templating system is that it makes it easy to tweak the template without worrying about possibly mangling the PHP code itself. So if you want to make it easy for others to design templates for your system, Smarty is the way to go.
Also, Smarty has a resource-saving caching system, which is way better than "live"-rendering everything as you would have to do just using raw PHP -- unless you were to write your own caching system.
> So if you want to make it easy for others to design templates for your system, Smarty is the way to go.
what
For a non-programmer, Smarty would be as difficult to learn as some simple php. It'd be hard to beat PHP at being a simple straightforward template language.
PEAR already provides a decent cache, you don't need to depend on Smarty's one.
Choosing a templating system because of a minor feature like a cache doesn't sound very wise, consider what will happen if using this template system is a maintenance nightmare (but hell, what isn't one in PHP).
I'm pretty sure the idea of managing to separate program logic and presentation for something that needs to output HTML is largely a myth. I've tried, again and again, to do this, but no matter what, you end up with HTML in your program code or program code in the HTML (even if the program code is some templating language, it's still code).
For a really simple app, maybe you could pull it off in some meaningful manner, but for anything even a little bit complex, there's just too many cross-dependencies between presentation and logic.
> I'm pretty sure the idea of managing to separate program logic and presentation for something that needs to output HTML is largely a myth. I've tried, again and again, to do this, but no matter what, you end up with HTML in your program code or program code in the HTML (even if the program code is some templating language, it's still code).
That doesn't mean you shouldn't make an honest attempt.
I like the way Wordpress or Ruby on Rails apps do it:
The first uses PHP files as the templating language. You use well-documented functions to fetch data, so the templates are really flexible, yet free enough from business logic, especially since plugins are quite easy to write.
In Ruby on Rails, the views are .rhtml templates which work a lot like PHP, which look like this:
<% @things.each |thing| %>
<div class="thing">
<%= link_to thing.name, :action = 'show', :id = thing %>
</div>
<% end %>But you'll still often code methods that spit out some HTML snippets outside of the views.
If you want to suceed at web applications, you certainly need a lot of discipline and to never allow a prototype to grow into a module without some serious clean-up, but you shouldn't follow the MVC approach all the way: the end users don't want to interact with applications, but with websites, and most web apps (especially PHP ones) feel way too stiff because coders are too disciplined to know when to blur the line between code and data.
The key to keep the website agile and the app seamless is to know the rules, to apply them religiously, and to break them all the time. That's really hard.
Well, sorry for going way off-topic.
>>71
I'd settle for the code in the HTML being side-effect-free and just evaluating simple expressions, perhaps based on cookies for instance.
>>74
It was a response to >>71. "Code" in the HTML is okay by me, provided it only consists of expressions to be evaluated and spliced into the output, and it doesn't change any data on the server, i.e. no side effects. In an imperative language, that really means just write code that gets some data and prints it, nothing more.
>For a non-programmer, Smarty would be as difficult to learn as some simple php. It'd be hard to beat PHP at being a simple straightforward template language.
Yes, if the non-programmer is trying to do programming-type stuff with the templates. But if they're just trying to make simple changes to the appearance of the rendered page, then it's best to keep them separated from the actual code which they could accidentally mess up, and they'll feel much less uncomfortable looking at it. A page marked up with Smarty still looks mostly like a normal HTML page, whereas if you've combined and interweaved the two, it can get very confusing.
For non-programmers who just want to change the appearance a bit, HTML with bits of non-vital code in it is better than vital code with bits of HTML in it.
>a minor feature like a cache
I would hardly call it a minor feature...
> I would hardly call it a minor feature...
It shouldn't be considered when choosing a templating though. Features like that should be regarded as marketing when deciding wether to use a system, then just as a bonus afterwards.
And it IS a minor feature because any decent templating system should make caching trivial. The hard part is making sure the cache never goes stale, and no template system will do that for you.
Well, that's a good example of what I was talking about. That Ruby -in-HTML code is pretty much incomprehensible to anyone but a Ruby programmer, and thus, the only person who can safely work with the HTML templates is still the programmer.
>>78
Yeah, this is why the code in the HTML should just be expressions to evaluate (i.e., math, basically).
>>78,79
I still don't think it's good enough a reason to use 'dumb' templates. They cause inflexible apps, where the designer is only allowed to write HTML loops in a well-defined zone of the page and just insert placeholders. Sites made this way often look like data dumps straight from the DB, with a lot of needless metadata around, and a lot of opportunities to make the user's life easier lost.
I think that the designer must be able to do very basic programming (loops, conditional logic), and the coder must understand design (but doesn't have to be talented). Ideally, they should be the same person, but that isn't often possible. The coder should be able to do most of the HTML the designer requires, so that the designer should only need to work with CSS.
As I see it, the choice is wether to have a programming language, or just having placeholders. In-between options are also possible, but they tend to be the worse of both worlds. I will always go for the first option, because it allows me to do a better work in less time - maybe that's just because I'm lucky enough to be able to do both the app and the design myself, but when I see the limitations and missed opportunities caused by using non-coder-friendly templates, I just think there's no place in web apps for people who aren't versatile enough.
>>80
News flash: You don't need loops to program. Look at any functional or array language.
I am not at all saying the code in the HTML shouldn't be powerful, but writing it in an imperative style would be distracting and easy to mess up.
> News flash: You don't need loops to program. Look at any functional or array language.
Thank you so much for the information! As a designer, I struggled a lot to understand looping over some content for my website, so I hit wikipedia:
> Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions. Functional programming emphasizes the definition of functions rather than the implementation of state machines, in contrast to procedural programming, which emphasizes the execution of sequential commands. A purely functional program does not use mutation: rather than modifying state to produce values (as is done in imperative programming), it constructs new values from (but does not overwrite) existing values.
This is definitely what I needed for my templates! Oh boy, my websight's gonna be great.
From a webmasters perspective, PHP is a fucking security nightmare. There are about a hundred thousand different ways to execute arbitrary code on a webserver using PHP just by uploading a simple script. Using mod_security on Apache takes some of those out, but even then a badly designed PHP script can open up your server to everyone and everything. This is probably same for other languages, but never has such a bad language existed which allows for such... originality when writing bad code that works yet doesn't.
All in all I've sworn on PHP for being so shitty. Either you castrate it with mod_security (twenty pages of rulesets) so that only dynamic rendering works, or you enable extensions and run the risk of getting your server fucked over in five minutes. And PHP is especially fun because it doesn't support modern threading techniques like Perl or Ruby-On-Rails. No no no, it has to fork off the httpd into a separate process with a separate memory allocation every time a single .php script is run. Thanks guys.
ADMIT THAT RUBY IS AWESOME.
SWITCH FROM PHP TO RUBY.
> ADMIT THAT RUBY IS AWESOME.
> SWITCH FROM PHP TO RUBY.
NEVER.
Or at least not until I ship, I really need the competitive advantage so I'd appreciate it if Ruby kept its 'lol jap crap' reputation for a few additional months.
Ok, this has sat here for days now, and I still don't understand a word of it. What the hell are you talking about?
I think he's working on a commercial product coded in PHP.
Good luck with that.
I think he's a convict and is going to get shipped to Australia.
He's making a product in Ruby, and considers it a competitive advantage. He wants the competition to remain using PHP so he'll have the leg up.
>>88
So he wants to ship something that he hopes remains considered "jap crap"? How does that make sense?
Heh.
Most users (probably) don't care about the underlying language, so long as the software works well.
I still say he stole a loaf of bread and is getting shipped to Australia.
>>91
We don't want him.
>but even then a badly designed PHP script can open up your server to everyone and everything.
That's why if you code a WELL DESIGNED PHP script, PHP doesn't suck and isn't unsecure. Amazing! As posters in the beginning of the thread have stated, learn it before you hate it. It's very possible to code a PHP script which can't simply be altered by outside means.
Of course, I'm going to admit right now though that NO CODE is ever 100% secure. There's always another way in EVERY language where the server can be broken into.
>>93
That's fine in theory. But in practice, I need to use other people's libraries, because re-implementing things would often take more time. And a significant amount of open-source PHP libraries are done by stereotypical dumb php users. Even if you are very security-conscious, there's nothing you can do about it.
And most quality PHP code available will assume you are using a shared hosting environment, aiming for the lowest common denominator in terms of features used.
It is in large part a hobbyist language. You can use it to make secure scripts and quality code, but you just can't rely on the community.
Because of this, I only use PHP for small independant web scripts that won't do anything more complicated than accessing a Sqlite database.
In a way, PHP is a victim of its own success and simplicity, which attracted the attention of crap-writing, copypasta, trial and error n00bs, but this doesn't mean you can't come up with high quality code in a highly productive manner with it, and some libraries are like this. This comes from an expreienced PHP developer who has had to deal with both good and terrible PHP code.
well!! sory about that!!
every code have weakness.. but the person try to find weakness is not bad person..
PHP are dumb.. that shock me up.. but i realise it..
btw... the source php are from perl.
>>96
Thanks for bumping
>>98
lurk more
>>100
I tried hard, but I just can't guess what the hell this is about (and I used to be a big KDE nerd and PHP user)
>>101
it was written by a PHP user.
see thread title.
Related news: http://www.informit.com/articles/article.asp?p=603037&seqNum=1&rl=1
Seriously, I understand that you can forget one form field now and then, shit happens, but not escaping any user input in the whole app? Where did those people learn programming? Even a "PHP for Dummies" book most probably has a chapter about the basics of securing your application now.
//Function: mysql_queryf($query, ...)
//Description: A MySQL query command in the similar format as printf, sprintf, etc. The parameters are automatically escaped to prevent injection.
//Only accepts codes %s (for strings) and %n for number values.
//Usage Example: mysql_queryf("SELECT * FROM table WHERE id=%n AND name=%s", $id, $name);
function mysql_queryf($query)
{
$finalstring = "";
$numargs = func_num_args() - 1;
$stringpos = 0;
$retstring = "";
for ($argnum = 0; $argnum < $numargs; $argnum++)
{
if (($stringpos = capture_till($query, $stringpos, "%", $retstring)) !== false)
{
$finalstring .= $retstring;
switch (substr($query, $stringpos, 1))
{
case "s":
$str = func_get_arg($argnum + 1);
if (get_magic_quotes_gpc())
{
$str = stripslashes($str);
}
$finalstring .= "'".mysql_real_escape_string($str)."'";
break;
case "n":
$finalstring .= "'".intval(func_get_arg($argnum + 1))."'";
break;
}
$stringpos++;
}
else
{
$finalstring .= $retstring;
break;
}
}
if ($stringpos !== false)
$finalstring .= substr($query, $stringpos, strlen($query) - $stringpos);
echo $finalstring;
}
function capture_till($string, $offset, $criteria, &$retstring) //returns a string starting at $offset of all content until it reaches the $criteria string
{
if (($pos = strpos($string, $criteria, $offset)) !== false)
{
$retstring = substr($string, $offset, $pos - $offset);
return $pos + strlen($criteria);
}
else
{
$retstring = substr($string, $offset, strlen($string) - $offset);
return false; //criteria never met
}}
sorry, posted old test version of the code by mistake.
Replace the line:
echo $finalstring;
with:
return mysql_query($finalstring);
They say there's no simple way to fix this. That can't be true. How would you fix it?
>>106
I guess their system is written in a way so that there is no easy way to fix this. That's most probably not PHP's fault, but poor design, it probably seemed like a good idea at the time mediawiki was originally written but doesn't seem like such a good idea now, but when you already have a huge, complex system running, even minimal changes are pretty hard to do.
As I posted in the other thread >>106 started (which apparently was deleted): [[The]] problem is in making both of these links lead to [[the]] same page, it seems.
Notably, Wiktionary works just fine with both:
http://en.wiktionary.org/wiki/Britain
http://en.wiktionary.org/wiki/duck
I really wish they'd find some way to get it working on Wikipedia too, though, so we no longer have to deal with things like http://en.wikipedia.org/wiki/IPod . Perhaps just have MediaWiki try shifting the case on the first character if the article isn't found with the original casing or something.
But yeah, it's definitely not a PHP thing.
It may not be a PHP thing, but it is the Unix disease of case-sensitivity. No interface that is exposed to users should ever be case-sensitive. Normal people do not differentiate between words written in different case.
>>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! (,ﾟДﾟ)