Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PHP 5.2.0 Released

CowboyNeal posted more than 7 years ago | from the new-and-improved dept.


ShaunC writes "The PHP Group and Zend have released PHP 5.2.0, and upgrades are encouraged. The 5.2.0 update offers several security fixes, including patches for a couple recently announced buffer overflows in input parsing. This release also includes a number of library upgrades, bug fixes, and default bundling of the popular JSON extension to help with AJAX development. See the full changelog for more details."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


That's nice but... (1)

Ant P. (974313) | more than 7 years ago | (#16700443)

When are they going to fix the insanity of all the string function names?

Re:That's nice but... (0)

Anonymous Coward | more than 7 years ago | (#16700561)

They're going to be fixed whenever you manage to convince everybody to change their scripts accordingly. Ofcourse, it would be very nice if they were changed but it isn't going to buy the current users anything - except from more headaches when they are upgrading to a new version.

Re:That's nice but... (1)

Ant P. (974313) | more than 7 years ago | (#16705427)

They didn't delete mysql when mysqli was released, so I see no reason why they can't do the same here.

Insanity? Fix? (1)

smitty_one_each (243267) | more than 7 years ago | (#16701267)

One man's insanity is another man's business opportunity.
Verily, it is far better to maintain the insanity, at a reasonable price, than to set about fixing it.

Re:Insanity? Fix? (1)

mattwarden (699984) | more than 7 years ago | (#16703973)

Attitudes like yours are why people end up bitching about outsourcing/offshoring. If you're going to try to make money of poorly designed products, then you're going to end up whining that your job got shipped off to India.

Oh look... (1)

urbanradar (1001140) | more than 7 years ago | (#16700495)

...a PHP story!

"PHP is a toy language" trolls in 3... 2... 1...

Re:Oh look... (1)

phase_9 (909592) | more than 7 years ago | (#16700517)

Toy language it may well be in your opinion, but it helps put food on my table!

Re:Oh look... (1)

urbanradar (1001140) | more than 7 years ago | (#16700575)

Toy language it may well be in your opinion, but it helps put food on my table!

I'm not sure whether you're replying to my post seriously or in jest, but just to make it clear: I don't consider PHP to be a toy language either.

It's not the most beautiful of languages, it's often inconsistent, and it's very very easy to do very very stupid things in PHP. Also, there are a lot of very bad programming practices that are so frequent among the majority of PHP coders that you'll even find them in most tutorials and PHP books.
However, PHP is great for getting simple things done quickly. And a good coder who knows what he is doing can create very solid products in PHP very quickly, even for larger projects.
The sad fact is, IMHO, that most of the bad PHP code out there isn't bad due to the language, it's bad due to the programmers behind it.

Re:Oh look... (1)

OakDragon (885217) | more than 7 years ago | (#16702135)

One of the reasons it has such a bad reputation is that is installed on 99% of those $5.00/month hosts. Well, that's the reason I know PHP. :)

Re:Oh look... (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#16704139)

It's not the most beautiful of languages, it's often inconsistent, and it's very very easy to do very very stupid things in PHP. Also, there are a lot of very bad programming practices that are so frequent among the majority of PHP coders that you'll even find them in most tutorials and PHP books.

I take it you think you're proficient... I'll bet many Slashdotters could pull your code apart and show you what a piece of shit it is. I've been coding in PHP on and off for about six years and I have no doubt that there are things that I do that are questionable, and I've got years of experience in low level languages on projects well into the tens of millions of lines of code.

Look, PHP is fine for small projects, but grownups use J2EE and .Net for mission critical scalable apps. I use all of the above. The proper tool for the job is key.

But it *is* a toy language (0)

Anonymous Coward | more than 7 years ago | (#16700571)

I'm waiting for PHP to have uniform exception handling (like, EVERY error raises an exception), and to have an "ensure" mechanism so that code always runs even after an exception is raised (maybe I'm dense, but what is the purpose of exception handling without this basic feature?)

Some other things that would be nice would include the ability to create and pass anonymous functions in an easy way (i.e., not as strings, dammit), with closures, so that I can pass blocks to functions like, I dunno, almost every other dynamic language? So I can sort by a user-defined function in 1-2 lines, instead of 5-10?

CAN SOMEONE PLEASE FIX THE VARIABLE REFERENCE NONSENSE? I saw some code that began "foreach ($foo as &$bar)" and it somehow managed to replace every element of $foo with $foo[0], even though it never assigned anything.. which I simply can't comprehend.

How about making the PHP display tag automatically HTML-escape it's contents?? Use a longer opening tag for non-escaped content. This would make things SO much easier for the programmer and would pretty much eliminate great swaths of XSS.

Can we make it possible so that any two random PHP installations have the same language features?? The php.ini file is the WORK OF SATAN HIMSELF. Every PHP app I've shipped has to come with a detailed list of which php.ini flags have to be on or off. Feh.

I better stop now, or my HEAD WILL POP OFF.

Well, I'll say something nice about PHP too, how about these:

1) the completely flat function namespace means the documentation at php.net is fairly easy to use.

2) the phenomenal amount of crappy PHP code out there makes my mediocre programming skills look positively GOD-LIKE, so if I ever think I'll go hungry, I can just get a job as a PHP programmer (preferably, the ONLY PHP programmer in the org, otherwise I'll have to deal with the unwashed masses who wrote the stuff in the first place, and will be forced to slit my wrists [or his]).

See Mom, I can end with something nice, even about a crappy language like PHP!


Re:Oh look... (2, Insightful)

mrjb (547783) | more than 7 years ago | (#16700591)

In my not so humble opinion, PHP does not deserve the reputation of being a toy language- I've found it stable and functional enough for very serious stuff (here in Holland, the eBay company "Marktplaats.nl" runs on PHP).

Yes, it has backwards compatibility issues. Most any upgrade path does. I personally deal with this by wrapping core functionality into a library. I've written sites that are insensitive to PHP versioning- they work equally well on PHP 3, 4 and 5. Programmers that require a specific PHP version 4.4.something should be ashamed of themselves.

There are a lot of good reasons to use PHP:
- PHP is very accessible, it is very easy to start working with
- Very stable
- it offers a ton of functionality right out of the box
- No need to buy extra components for trivial functionality such as reading binary files
- It's free (as in beer/speech), just like perl
- ...but it doesn't "feel" quite as complex as perl, partially because of
- the excellent documentation- which blows the competition out of the water.

Most likely, being this accessible causes it to attract quite a lot of not-so-experienced programmers. Which is probably the *real* problem. The main complaint I hear people make about PHP is that invariably, the sites built with it are a huge mess. Don't blame the language for that- blame its users.

Re:Oh look... (1)

Builder (103701) | more than 7 years ago | (#16700625)

There's one very good reason to NOT offer PHP as a hosting company though.

Far too often you are forced to upgrade because of security issues, but that upgrade breaks functionality. So as a hosting provider, you either have to have insecure servers or angry customers, and dealing with those angry customers takes time and costs money.

Re:Oh look... (1)

AndroidCat (229562) | more than 7 years ago | (#16701271)

A toy language? Excellent! I just got a small Linux board with limited* resources and I wasn't sure if PHP would fit. Are there many commercial toys programmed with PHP? :)

* Mind you, "limited" is relative. A 200MHz ARM9 chip with 32M ram [photobucket.com], 4GB flash drive, 2.4 kernel and Busybox beats the 486/25, 16M ram, 200M hard drive with Slackware 2.1 that I used to run my multi-user BBS on, while playing nethack, quite nicely. (Kids these days...)

Re:Oh look... (1)

JabberWokky (19442) | more than 7 years ago | (#16701629)

Or my 1Mhz 6502 with two 100K floppy drives that I used to run my BBS on. Yes, toy is relative. Later I upgraded to 8086 Corona luggables for each node. Nice and speedy.


Argh. (5, Insightful)

Balinares (316703) | more than 7 years ago | (#16701433)


Your comment pisses me off, but there's something I want to say all the same: I think you are, essentially, right. Whatever one's woes with PHP might be, they don't justify trolling and unsubstantiated mouthing off. Besides, "toy language" is a purely inflammatory statement that doesn't even have any factual content.


However, the implicit underlying assumption I think I perceive in your comment -- that PHP criticism must be trolling -- annoys me a lot. Please allow me to expand on this.

You see, one constant characteristic of the Internet in general is the noise. Look here on Slashdot: do you read all the comments on any given story?

The noise is a bigger problem than you'd think. The noise means that it's hard to get heard. It means that to be heard, unless you're a remarkable writer (which I, and most people, aren't), you have to exaggerate your message. "PHP is a toy language" is one such exaggeration; and perhaps even actually worthy of being modded up if followed with factual information to support it. And much likelier to catch a moderator's attention with its use of strong language.

Which you would, undoubtedly, consider a troll all the same, wouldn't you?

As you can probably guess by now, I have crates of such information against PHP. (In my defense, I do try hard to gather evidence against my own tools of choice as well, for two reasons. One, being aware of their own idiosyncrasies allows me to work better with them. Two, it's a simple matter of intellectual honesty.)

The vagaries of life have landed me into a managerial-ish position in a small company that develops and hosts large-scale PHP websites. My responsibility here is twofold: ensuring that the sites work, and ensuring that they keep working.

I didn't know PHP before joining this company; I had a generally positive opinion of it beforehand, from reading Slashdot. So I got to discover it through that new role.

Let us just say, to put it mildly, that my opinion of PHP has quickly become very poor.

I think that managing a language's design and development is one of those jobs that's freaking damn hard. It takes a LOT of experience, critical thinking, introspection, knowing to prioritize issues, knowing to tap into the decades of experience in language design to understand what works and what doesn't, why, and in what context. And different people with different backgrounds and objectives are more or less successful with it.

And I don't feel the people behind PHP -- I'm sorry, guys, I don't know how to put it nicely... -- are doing the best possible job of it.

More precisely, my primary issue with PHP is its culture as a project. Cultures are inherently difficult to describe, but if I had to put it in a few words, I'd call it the "Works for me" culture.

Simply put, the sort of attitude that PHP seems to encourage -- by which I mean, the shortest-path-to-arrival approach to doing most things in PHP -- work fine for the developper producing the code, but are formally broken in a way that WILL come back to bite the ass of whomever poor dude is in charge of keeping the thing working.

For instance: I understand PHP uses a function based on the tolower() C call to make method calls case insensitive, and leaves it at it. It works for them, doesn't it? Except that in the real world, it breaks. Deploying PHP sites on servers that use a Turkish locale yields blank pages. The workaround is to never use that particular locale. Easy, isn't it? No, it isn't: PHP's gettext functions for dynamic translation require the locale to be set appropriately (unlike that of other languages). And I have my Turkish clients on the phone a lot.

Until recently, before the introduction of PDO, the canonical native way of addressing databases was to use PHP functions named after the database itself (mysql_*, etc, making the process of migrating databases, or creating a site that may have to be deployed client-side on varying database backends, an utter pain. The current canonical way still doesn't proactively encourage the use of prepared statements, that would yield better performance and forbid entirely SQL injection attacks. (But the current way "works for me", doesn't it?)

PHP STILL doesn't have namespaces. Why does this matter? Well, for instance, had PHP put the HTTP request data into its own namespace, the whole register_globals debacle wouldn't even have been possible. Good engineering practices are no silver bullet, but they do ensure that whole classes of problems simply can't happen. I think this is why the "Works for me" culture tends to fosters projects (and I don't mean only PHP, here, mind) with recurrent security issues.

Unicode support has been problematic; and by this I mean I have two major problems with it. Firstly, the lack of a native Unicode type means you can't carry around a known-good string that you can pass around or retrieve from an third-party, and only convert back to the requested encoding. Why does this matter? Well, most PHP functions break hard on UTF-16 encoded byte arrays, which contain zeros. Secondly, whenever you raise this issue, the common answer is, "What's wrong with the mbstrings functions?" And THIS is what I mean by a cultural issue: the assumption that because mbstrings "work for me", they're a suitable solution. This is not a technical problem at heart, folks.

And there's the problem of backward compatibility, which is never a granted, and makes the job of keeping production servers up to date a nightmare. There's thread safety, there's syntax bone-headedness that probably stems from PHP's lack of a grammar, there's the inconsistent behavior depending on server-side settings that you may have no control on, etc, etc, etc.

All of those make the management of large-scale PHP projects an incredible pain, and it's all the more embittering that a large chunk of it could be abated by good freaking engineering practices.

I think this is what people mean when they call the management and design of the PHP language 'amateurish'. Blatant lack of good engineering practice. I do disagree with the word amateurish itself, though: the fine guys over at Zend are professionals, and making good money off their language, which is one of the most widely deployed on Web servers. They're without contest professionals. Just, professionals with poor engineering practices.

The thing I can't forgive PHP, however, is that due to the way it encourages and rewards (at first) shortest-path-to-arrival approaches, it teaches beginning programmers everywhere that it's okay so long as it "works for me". That it's okay not to care about good practices so long as it works. That it's okay to embed SQL requests right in the HTML templates. And, due to PHP's lack of introspection and metaprogramming, that other approaches are a lot more work and not worth it.

And THIS is what people mean when they unleash Dijkstra's ghost onto PHP.

Granted, designing a language where the easiest way to do anything is correct and robust one, while keeping the flexibility and development speed of an interpreted and dynamically typed language, is extremely difficult. Is that any reason not to try, though?

So, yes, after more hours of nightly overtime than I care to count, after salvaging several expensive PHP projects for large companies that where unmanageable messes, I've come to hate PHP, which I consider a character flaw in me. PHP is just a language; that should warrant an informed opinion -- which I like to think I have -- but not an emotional reaction.

And this, in the end, is why I wanted to post this: your comment annoys me a lot, but I think its sentiment is, at heart, correct: emotional reactions to technical issues shouldn't supplant informed discussion.

And this goes both for the PHP-hater and the PHP-lover side.


Mod Parent Up! (2, Insightful)

Builder (103701) | more than 7 years ago | (#16701807)

This post explains most of my issues with PHP far more eloquently than I ever could.

Re:Argh. (1)

Directrix1 (157787) | more than 7 years ago | (#16702099)

So what software do you think actually meets your criteria (preferably FLOSS).

Re:Argh. (2, Insightful)

Balinares (316703) | more than 7 years ago | (#16702697)

All of my criteria? None. That's my point. There is no technology that doesn't deserve its share of criticism.

(Actually, asking people what their preferred tools' most important drawbacks are is generally a good litmus test for their competence. If they can't tell you what the pitfalls are and how to work around them, or why they don't affect the task at hand, watch out.)

Simply, some tools are a better match than others for any given task.

For instance, I think that PHP makes for a good, simple and effective templating language.

But of course, there's a world of difference between 'HTML templating' and 'development, deployment and ongoing maintenance of a Web site or set of sites.'

And no, I'm not going to tell you what I personally favor for the tasks in question in this thread. That's not the point. What matters is not the tools I favor, but WHY I favor them. It is important that you figure out for yourself what makes for a suitable tool, from your own experience, because that's how you'll know how to make the best use of that tool, and what to watch for.

The next, much trickier step, is to figure out where your own blind spots are, and learn to take them into account when making your choices. (Mine, for instance, tend to involve underestimating the importance of community support -- a point where PHP, incidentally, scores high.)

I hope I'm not sounding too patronizing here (I'm not very good at finding the right tone in online forums). I'm no better than any other computer dude who's had to deal with a wide set of technologies and their respective fans. But I learnt what I did thanks to other people sharing their experience, and I can only hope that, by sharing my views on what I think really matters at heart, I can help others broaden their own experience. The first step toward learning, after all, is recognizing that there's stuff you need to learn.

Re:Argh. (1)

itsari (703841) | more than 7 years ago | (#16718155)


It has deep-rooted support for meta-programming and introspection. Namespaces are simple and straight forward. The re-occurring interfaces in Python shave down development time and encorage uniformity.

Using Python is actually a pleasure. Mind, it does have its flaws: Performance (which is about on par with PHP), populatity (not deployed as much as PHP), and some OOP querks (but still better than PHP's).

Arghmen (4, Interesting)

Bogtha (906264) | more than 7 years ago | (#16702347)

I think this is what people mean when they call the management and design of the PHP language 'amateurish'. Blatant lack of good engineering practice.

Totally agree 100%. Another example: did you ever use nl2br() [php.net] to convert newlines into <br> elements? It's an extremely common thing to do. In a minor patch release, they changed the function to generate XHTML instead of HTML. In one stroke, everybody who thought they were generating valid HTML had errors in their code. This might not sound that bad, until you realise that nl2br() can appear a lot in large projects, there's no way to get the old behaviour of nl2br() back, and if you have a decent QA process in place, you'd be being notified of the errors across all the websites you maintain. You end up having to go back and change all your code to use generic string replacement functions.

Now, maybe you might say that it's a sensible thing to change (I disagree, there should be different functions for HTML and XHTML), but at the very least, they should have put a change in semantics in a major version update, not sneaked it in between 4.0.4 and 4.0.5.

It's not really the design of the language that's the real problem (although it's not pretty), it's the cavalier attitude from people who don't seem to take a professional attitude to their work that really grates.

Re:Arghmen (4, Interesting)

nuzak (959558) | more than 7 years ago | (#16703529)

Amen to the cavalier attitude. You know about PHP's Javascript-esque === operator? (that's the one with three equals signs). That got designed on the spot in an IRC session with Zeev and some other devs. Because I actually had to explain to these folks what the concept of "object identity" was, i.e. what lisp does with 'eq', python does with 'is', and Javascript does with ===. Yes, because PHP's is different. Not only does === fail to do object identity testing, it's simply '==', does all the "deep comparison" of ==, but also bothers to compare the type.

In other words, I was unsuccessful in explaining this rather basic concept. They got it blisteringly wrong, and hacked this wrongness into the language for all time. I attempted to explain (much more patiently than here) that no, this is not what === is supposed to do, but I wasn't heard. Not by Zeev, not by anyone else on channel. No one got it at all.

I passionately hated PHP for a long time after that, but it's just not relevant enough to my work anymore to hate. I have choices, I don't have outside clients demanding I use PHP anymore, and my choice of languages is respected where I work. I've chosen python for some projects, perl for another, C++ for another (the C++ one was of course not web). I could probably write my next project in Haskell and no one would bat an eye (though I will be stuck with maintaining it for all eternity). I'm even eying Prado -- a PHP library -- for an upcoming project, though I've still no desire whatsoever to write actual business logic in PHP, so it'll have to be solely at the view end of things.

Re:Arghmen (1)

merreborn (853723) | more than 7 years ago | (#16706507)

In PHP's defense, it is desperately in need of the current functionality of ===, because 0 == false, and there are core PHP functions that return *both* 0 and false (which mean entirely different things, in context). As such, you're left in a situation where you must use PHP's === to tell which one exactly the function gave you.

An object identity comperator is all good and fine, but PHP needed this functionality much more desperately.

At any rate, I can't disagree with the perception of ineptitude on the part of the PHP team. I've spent the last two years working in PHP exclusively, and I finally got sick of it when I came across this bug: http://bugs.php.net/bug.php?id=33487 [php.net]

Long story short, PHP doesn't totally release memory used by objects until your PHP process exits. The response from the PHP developers is "It cleans up on shutdown, so who cares?". God forbid anyone ever write an object-based command-line PHP script that runs for more than a few minutes...

We're transitioning to perl as rapidly as possible.

Re:Arghmen (1)

nuzak (959558) | more than 7 years ago | (#16708775)

I looked at the bug, and it appears that it's gc'ing as expected, but doesn't let the OS reclaim the extra heap. This is pretty much to be expected, almost all language runtimes behave this way. Heck, most virtual machines like Java or Smalltalk allocate a fixed heap right off the bat.

Perl also has the batty notion of "scalars" and as a result believes that a zero in a string is false, and makes string comparisons really hell with its own insanity around 'eq' ... though Perl's also not in the habit of passing everything by value, so plain old == compares identities unless you go overloading it (and most people don't overload operators in perl). I also don't know of any core functions that might return either 0 or undef, but I suppose some libraries might.

Python and Ruby have much more sane reference semantics. Actually one might say Haskell has the sanest (referential transparency), but we live in a world that still demands a bit of insanity :) The reference semantics thing was the last straw, but the crummy database support (lack of prepared queries) was most of the reason. PEAR didn't exist back then (and still won't magically add prepared queries regardless) and I felt like I was the only person around in 1998 trying to avoid SQL injection attacks in PHP apps.

Re:Arghmen (1)

TheLink (130905) | more than 7 years ago | (#16730981)

Question: what's wrong with string comparisons and eq in perl? Examples please if possible.

Re:Arghmen (1)

nuzak (959558) | more than 7 years ago | (#16736121)

Strings are only comparable for string equality with 'eq'. The == operator compares only numeric equality, and the numeric value of any string that doesn't look like a number is, in fact, zero.

$ perl -le 'print "matches" if "foo" == "bar"'

If you use -w or "use warnings", which any sane person should do, you get a warning about it. That perl's scalar type lets you play fast and loose with strings and ints with is fine for one-offs, but there's no flag or pragma that actually separates strings and ints as separate types (scalars are deeply ingrained into the language core) so you learn to treat some mere warnings as probable errors, and "argument xxx isn't numeric" is definitely one of them.

PHP incidentally has almost exactly the same brain damage, but doesn't warn or provide an infix comparison operator. Python and Ruby both get types right the first time.

Re:Arghmen (1)

TheLink (130905) | more than 7 years ago | (#16746237)

But that's not a problem, that is a correct way to do things. Perl is intentionally weakly typed.

If you want to have weak typing and compare stuff then when you want to compare different types of stuff with each other, you need different operators/functions depending on what sort of comparisons you want to do. The alternative is to be verbose and convert stuff before comparing.

Maybe not the only correct way, but definitely better than PHP's way - where they didn't seem to think about the implications of weak typing, and slapped on === later on as a kneejerk reaction.

PHP really shows a severe lack of good design. PHP too often makes doing the wrong things easy, and the right things difficult.

Re:Arghmen (0)

Anonymous Coward | more than 7 years ago | (#16711875)

I guess it's time to introduce the operator ====!

Re:Arghmen (1)

HaydnH (877214) | more than 7 years ago | (#16704137)

"This might not sound that bad, until you realise that nl2br() can appear a lot in large projects, there's no way to get the old behaviour of nl2br() back, and if you have a decent QA process in place, you'd be being notified of the errors across all the websites you maintain."

If you had a decent QA process in place you wouldn't upgrade all of your prod servers in one go without testing the upgrade in dev first.

Re:Arghmen (1)

Balinares (316703) | more than 7 years ago | (#16704573)


I must ask, do you have any experience of managing PHP production servers? It is frequent that minor patch versions of PHP are mandatory upgrades due to critical bugfixes. Slipping something that breaks code in a bugfix version is NOT acceptable by any sense of the term. It means that, if you have good QA and intercept the issue on your test servers, then you must still scramble and allocate ressources to have the code audited and updated on ALL the sites of your production platform, remaining vulnerable to the bugs of the previous release until you're done; or you don't intercept it, and have your production sites break in various ways.

(I am not going to go into why the very concept of a nl2br() function is fundamentally broken; that's matter for another time.)

It may be that you like PHP for your own reasons, and that's all good and fair, but please, please don't try to brush this kind of serious issues under the carpet. Doing so is doing a disservice to your language. It's only by expecting its developpers to do things right that you'll incite them to move away from the bad practice that are giving a language you may be fond of such a bad reputation.

Re:Arghmen (1)

Abcd1234 (188840) | more than 7 years ago | (#16704753)

Wow, it's amazing how easily you missed the point. Let me rephrase:

In a minor release, they significantly changed the semantics of a commonly-used function. And they did so with little warning. This is unacceptable. Period.

Re:Arghmen (0)

Anonymous Coward | more than 7 years ago | (#16704717)

That's because nl2br() is an idiotic function. No one in their right mind would use it.

Re:Arghmen (1)

larry bagina (561269) | more than 7 years ago | (#16708407)

A lot of php functions are idiotic/redundant. nl2br -- because it's so hard to use str_replace?

One of my complaints is that they add these half-assed functions and then add new parameters, change the semantics, etc. etc.

Consider http_build_query -- a useful function (but it would only take 3-5 lines of php code to write it yourself). Only available in php 5+. Except they added a new parameter in PHP 5.1.2 (making it actually useful), so you'll probably have to rewrite the function yourself.

It would be nice if you could replace built-in php functions (like perl does).

Re:Arghmen (0)

Anonymous Coward | more than 7 years ago | (#16716213)

Python's "import from future" is a good approach here, IMO. Language features can get kicked around, have the bugs shaken out of them, without becoming part of The Official Language. If they pass the test, they make it in. In the mean-time, it's pretty clear you shouldn't be relying on them.

Of course, mentioning Python brings us on to namespaces. Oh, how I loathe thee, PHP.

Re:Arghmen (1)

masklinn (823351) | more than 7 years ago | (#16741355)

Python's "import from future" is a good approach here, IMO. Language features can get kicked around, have the bugs shaken out of them, without becoming part of The Official Language. If they pass the test, they make it in. In the mean-time, it's pretty clear you shouldn't be relying on them.

Actually, "from __future__" is more about letting users get a feel of the soon-to-come core changes of the language (also called "incompatible language changes" in __future__'s DOCSTRING). And about rooting bugs out indeed (which is why __future__ features have a RELEASE_LEVEL attribute associated to them).

__future__ features may change, but it's pretty sure that they'll make it to the core language sooner or later, because by the time they've reached __future__ they:

  • Have gone through the main Python mailing-list unless the proposal was done by a core Python dev, and even then...
  • Has gone through hundreds of posts on python-dev, debating it's usefulness, it's impact on the language, it's exact semantics, ...
  • Has probably gone through either a proof of concept or a direct patch by the submitter, because that gives him a much better chance that people will be interested in his idea
  • Has gone through a PEP, whether the idea was accepted or refused, if the idea was any good (a refused idea can be very good or interesting and yet be refused) a PEP will be asked.
  • Has gone through the acceptance or refusal of the BDFL.

If you never have, do subscribe to python-dev, you'll realize that most issues and ideas get beaten to death and then some more, the few ideas that make it through python-dev are pretty much guaranteed to see the end of the tunnel.

Re:Arghmen (1)

odujosh (967823) | more than 7 years ago | (#16708681)

Umm PHP does not make good egineering practice. You hit walls as you code. Naming conventions are not standardized throughout the frame work. Modulazation in PHP is what duct tape is to home repair.

Biggest hit:
PHP is interpretted not compiled and there is no other option besides third party wrapping of compiled code.

In ASP.NET for example I can precompile my site in DLLs to whatever degree I am comfortable with. So if I want my Data Access layer locked down after a certain phase I can keep my junior developers out of the code. Not to mention the speed difference. Even at a surfacy judgement precompiled has to be faster than interpretted language. ASP.NET is also a more mature product in features it offers. What I can't believe is that you need a function to turn a carraige return into a <br> and it is <br /> by the way :P

In C# I could do this with the string libary:
string mystr = "Some string with breaks";
//just to give reference for people that have never seen C#
mystring = mystring.Replace("\r\n", "<br />");

Notice also C# does not have a silly function name like nl2br(). I avoid any language that does not have a professional standardized naming convention. It points to bigger problems with the language. If they can't be professional about naming what else do they mess up?

Re:Arghmen (0)

Anonymous Coward | more than 7 years ago | (#16743101)

Using Built-In Libraries is probably smarter than your example. Nevermind that it doesn't, for example, convert some other newlines (from a UNIX file, for example.)

And since a function like that is likely to be very common in Data Modification on the web, it should at least be abstracted away so you won't need to do a lot of manual changes later... what you're saying is exactly the bad engineering practice that the parent disagree with..

Re:Argh. (0)

Anonymous Coward | more than 7 years ago | (#16704695)

Kudos to you for posting one of the most insightful and well thought-out replies I've ever read on /. This particular part of it was just brilliant:

So, yes, after more hours of nightly overtime than I care to count, after salvaging several expensive PHP projects for large companies that where unmanageable messes, I've come to hate PHP, which I consider a character flaw in me. PHP is just a language; that should warrant an informed opinion -- which I like to think I have -- but not an emotional reaction.

It's when you can admit things like that about yourself that people take you seriously. For the record, I feel the same way about PHP.

Re:Argh. (1)

abradsn (542213) | more than 7 years ago | (#16709993)

I've noticed that most open source projects are the way that you describe, with the culture you describe.

If I were you I would stick with big companies that produce commercial software. They tend to be motivated by cash, and hire real engineers to make sure things get done correctly as much of the time as is possible.

While Microsoft has its flaws and might be deteriorating in their practice of engineering as of late, they still outshine everyone in the areas that you are complaining about.

Maybe you used to work there, and just miss that goodness in those areas?

Re:Argh. (0)

Anonymous Coward | more than 7 years ago | (#16741499)

There are some OSS Languages that actually care for backwards compatibility and stability..., one example (although not very popular because it doesn't run after each new buzzword and breaks everyones code all the time) is Tcl.

You can load a seven year old binary extension into a new, current interpreter and it just works. You can code things on Linux, it runs on Windows without changes and mostly without bad surprises. You can run ten year old code without changes and it does not break everywhere. And its faster than PHP too...

And it has won a ACM Award for its Engineering AFAIK...

Re:Argh. (0)

Anonymous Coward | more than 7 years ago | (#16744627)

That's funny, I've noticed that people who think only expensive things from large companies have quality tend to be idiots.

Ever used the old (pre-.NET) Visual Basic? It had problems similar to PHP's, and with a similar cause. Microsoft's language engineering has gotten better lately, not worse, starting when they discontinued that steaming pile.

What backwards compatibility has it broken? (4, Interesting)

melonman (608440) | more than 7 years ago | (#16700523)

Our company does web hosting, and every single time we get an enquiry involving PHP it comes with a caveat along the lines of "but I need version 4.x.y with version z of the q module and safe mode turned off". The best one yet was someone who wanted us to promise never to upgrade PHP because his XSLT module needs pre-version 4.4 - a bit of googling revealed that there's a whole section of the PHP community hunting for servers that will never upgrade for that reason. We never ever get this with perl, because backwards compatibility works over decades.

Re:What backwards compatibility has it broken? (1)

TrueKonrads (580974) | more than 7 years ago | (#16700539)

Amen brother! Cue the differences between behavoir for PHP on windows and PHP on Linux. The ocasional memory corruption (I've expirienced it myself), the no namespaces, the.... Whatever, as long as people don't kill each other.

Re:What backwards compatibility has it broken? (1)

NoMaster (142776) | more than 7 years ago | (#16700621)

To be fair, this is primarily because PHP allows any clothead to write some POS code without respect for logic, security, or sanity - at which point it suddenly becomes the most popular module / mailing script / CMS / message board ever.

I happen to like PHP, but I can also appreciate what a fecked-up language it is. Anybody who isn't coding with safe mode on and register_globals off in this day and age should be taken out and shot - it's been recommended practice since 4.1, and I wished 5.0 had bitten the bullet, said "screw backwards compatibility" and just removed those options altogether. Not to mention the hundreds of other cock-ups and inconsistencies in the language - there's at least two functions for any one thing you want to do, with varying syntax and behaviour, not to mention all the other deprecated functions that are still active. Granted, PHP5 is slightly better in this regard, but it still needs a damned good cleanout.

And don't even get me started on the half-broken collection of crud that is most of PEAR. You mean there's an actual working XSLT engine in there?

Re:What backwards compatibility has it broken? (1)

suv4x4 (956391) | more than 7 years ago | (#16700907)

Anybody who isn't coding with safe mode on...should be taken out and shot

Are you sure this is what you wanted to say? Safe mode was a terrible hack since day one, and it's considered to be removed from future editions of PHP

Re:What backwards compatibility has it broken? (1)

melonman (608440) | more than 7 years ago | (#16700975)

Anybody who isn't coding with safe mode on and register_globals off in this day and age should be taken out and shot

Yes, but

  1. A lot of webmasters using PHP grab the nearest free PHP library that claims to do what they want, and then shop around for someone mad enough to host it. The worst one we've seen was a "manage your mailing list via your webserver" system (why?!) which, by default, tried to open 65k local SMTP connections at once. I was quite impressed that our server didn't just roll over and die at this point...
  2. The whole reason you need safe mode in the first place is because the first design constraint of PHP (originally called Personal Home Page) was to neuter the user/permissions-based Unix security model, so that users could do superuser-type things without talking to their sys admin (this from Rasmus Lerdorf's first Usenet announcement, as reported on p2 of his O'Reilly book on PHP). Having got every web script on a shared server running as the same user with the same privileges, you have effectively imposed a W98 security model on Apache, where every script can write any file that can be written by any other script, which is why Lerdorf says in the aforementioned book that there is no safe way to use files with PHP. Yes, that's right, it's a programming language that can't use files! And then you need safe mode to try (only partially successfully) to reinvent another security model, having neutered the one that works perfectly well for CGI/suEXEC. Of course you can avoid these problems by running PHP as CGI, but that means learning to program, rather than pasting other people's code into HTML, so it's completely uninteresting for most PHP users
  3. Safe mode does nothing to avoid the other problem we keep hitting, ie that nobody involved in PHP at any level seems to have heard of parameter checking. We are forever shutting down PHP mailer scripts that happily pass data straight from the POST request to MySQL and/or sendmail. Most of this could be avoided if the webmasters did some basic checking (how hard is it to count the number of @ in what is supposed to be an email address, for example), but, also, some of the PHP mailer functions seem to grab whatever email addresses they find wherever they appear in the function arguments and send a copy of the mail just in case.

I know people who write very neat code in PHP, but I can't help thinking that it's in spite of, rather than because of, the language. The basic problem is that "You can become a web programmer without knowing anything about programming or security" is always going to be an accident waiting to happen. Web applications are the most exposed programs around. That's why the "PHP is the new BASIC" thing doesn't hold: I learned to program in BBC BASIC, but I didn't let the entire world look for flaws in my BASIC programs...

Re:What backwards compatibility has it broken? (0)

Anonymous Coward | more than 7 years ago | (#16701825)

Basically, the problem is that PHP is easy enough for people who have no idea how to write secure software to use.

If you know what you're doing, you can build robust, secure, fast web applications in PHP without the language getting in the way at all. You just have to resist the temptation to use the features that make PHP attractive to newbies, like being able to stick database access code in the middle of an HTML page.

Re:What backwards compatibility has it broken? (0)

Anonymous Coward | more than 7 years ago | (#16702853)

Basically, the problem is that PHP is easy enough for people who have no idea how to write secure software to use.


If you know what you're doing, you can build robust, secure, fast web applications in PHP without the language getting in the way at all. You just have to resist the temptation to use the features that make PHP attractive to newbies, like being able to stick database access code in the middle of an HTML page.

I disagree, PHP was designed to munge everything into a single file and this is where it excels. Building larger, real-world web apps in PHP is the very definition of pain.

Re:What backwards compatibility has it broken? (1)

Hynee (774168) | more than 7 years ago | (#16710821)

To be fair, this is primarily because PHP allows any clothead to write some POS code without respect for logic, security, or sanity - at which point it suddenly becomes the most popular module / mailing script / CMS / message board ever.

I see you've modded PHP-Nuke before!

As for register_globals, I don't feel it is a problem, if you allow variables to be injected into your code from outside then you haven't programmed properly. I always initalize them first, at the very least to NULL, to make it a kind of variable declaration. I never write:

if ($something) {

if ($a) {
//do something abusable
I would always initialize $a at the if ($a) level before the if ($something) block. That said, it's good practice to use $_GET[], $_POST[], etc.

And safe mode? Isn't this just a unix permissions precaution, usually used by restrictive (free) PHP webhosts? I never even look at it.

Easy solution: use PHP as a FastCGI daemon (1)

Aethedor (973725) | more than 7 years ago | (#16700735)

It's easy to solve that problem. Start multiple PHP FastCGI daemons. Everyone of a different version/configuration. A customer wants some other PHP version/config? Just connect to another PHP FastCGI daemon for their virtual host.

Re:What backwards compatibility has it broken? (1)

tehshen (794722) | more than 7 years ago | (#16701597)

Naah, we never get this with Perl because PHP has a brilliant php.ini, which means that scripts aren't guaranteed to run on any two different hosts, depending on the options set.

Re:What backwards compatibility has it broken? (1)

a.d.trick (894813) | more than 7 years ago | (#16702491)

I'm not so bothered by the fact that they break backwards compatibility, but that they are rather inconsistent about when they do it. In a perfect world, they would change their majorversion number whenever they did it. Of course we would probably have php 30.something if they followed that standard, but at least people would know when to watch out. As for XSLT and the XML stuff in general, the break was inevitable. The old iterfaces were pretty bad. I wish they would have saved their changes to version 5.0 though.

Re:What backwards compatibility has it broken? (1)

foniksonik (573572) | more than 7 years ago | (#16703167)

Those people need to get a dedicated server.... if it's so important to them they won't mind paying a little extra to get what they require.

Re:What backwards compatibility has it broken? (0)

Anonymous Coward | more than 7 years ago | (#16703231)

We never ever get this with perl, because backwards compatibility works over decades.

I'm not sure this is completely accurate. I've seen some Perl 4 code get broken by Perl 5. And Larry Wall himself has stated that Perl 6 will break lots of Perl 5 code.

Re:What backwards compatibility has it broken? (1)

mattwarden (699984) | more than 7 years ago | (#16703571)

Amen. PHP is notorious for breaking crap with little point releases. Remember when they just turned off register_globals and broke 90% of PHP applications? Was this a major release? Was it highlighted in huge blinking bold red text with scary background music on the download page? No. It was one small note in the changelog of a minor point release. I love PHP, but the maintainers are idiots when it comes to this stuff. They don't understand their users at all.

Re:What backwards compatibility has it broken? (2, Informative)

CopaceticOpus (965603) | more than 7 years ago | (#16703753)

First of all, it's trivial to run two versions of PHP on the same server, and to use one version or the other on a per-directory or per-file basis. So there's no reason old code needs to stop being run if it's still useful.

Secondofly, the changes from back around 4.0 to where we are now with 5.2 are fundamentally huge, and they move PHP to a much more serious, professional class. Breaking backwards compatibility was worth it. It's sad that there has been so much resistance to change. Personally, these changes are the reason I now favor PHP as my language of choice for web development.

Re:What backwards compatibility has it broken? (1)

edxwelch (600979) | more than 7 years ago | (#16716147)

That buffer overflow error would be another reason why you would want an older version, becuase it didn't exist in PHP4

Perl vs PHP (0)

Anonymous Coward | more than 7 years ago | (#16700529)

I'm sure this will be modded as flamebait, but I'm going to ask it anyway. Which is better Perl or PHP? What are the pros and cons of each?

Re:Perl vs PHP (2, Interesting)

ImustDIE (689509) | more than 7 years ago | (#16700657)

Perl is stable -- Perl 5 has been out what... 10 years now? CPAN is also an amazing module repository and makes installing modules a breeze. Perl is also more powerful than php, and the syntax allows for certain things to be done more succinctly.

The best thing about PHP is that it's easy. The syntax is simpler than Perl, so it is easier to pick up. It also has a ton of built-in functionality so you don't have to go looking for modules as often, but that mass of bundled functionality combined with the fact that PHP doesn't have namespaces makes for a mess, compounded by the fact that the included functions are often named inconsistently.

Having done hundreds of thousands of lines of code in both languages, I favor perl; but don't hate PHP either. Both have tons of documentation (PHP's being more newbie friendly, but Perl's being more extensive). Both are very fast when coded properly.

Re:Perl vs PHP (1)

DarthChris (960471) | more than 7 years ago | (#16701095)

when coded properly
This is an absolute key point that the 'toy language' crowd often miss out on. PHP is a good language, when used correctly, and when coded properly - i.e. the same as any other language/tool/whatever.

I do have a couple of gripes with PHP however. Firstly, as the parent (and a myriad and one other people) pointed out, inconsistent function names. Secondly, the presence of objects in the language - IMHO OOP is a bit overrated - and if you try to take PHP V4 objects to PHP V5 objects you have to use an instantiation hack.

But then, I could go on about my gripes with C++, Java, SQL, HTML/CSS, and pretty much every language I've ever coded in.

Re:Perl vs PHP (1)

mrjb (547783) | more than 7 years ago | (#16700665)

If you want to be fair, you should compare modperl with the modular version of php.

Syntactically, they're relatively similar. Obviously the PHP/Zend folks knew perl before they started on PHP.

Perl was originally intended for string handling, but is also quite suitable for general-purpose programming. Perl has CPAN- almost any module you'll ever need is probably already there.

PHP was originally intended as HTML Preprocessor - so it is specifically targeted at web programming. Which of the two is "better"? Maybe we'll let the statistics speak for themselves.

Any HTML page is a valid PHP page. You can sprinkle some PHP in an existing HTML page for some automation (which can end up in a big mess if you're not careful). As such, if you have an existing website in which you want to add a little bit of automation, PHP is most likely the 'best' option.

In perl it's the other way around- you start out with code and put bits of web page generation in there. As such, if you have an existing program that you want to port to be web-enabled, perl may be a better choice.

Ever heard of Mason, etc, etc (1)

BerntB (584621) | more than 7 years ago | (#16700917)

Any HTML page is a valid PHP page. You can sprinkle some PHP in an existing HTML page for some automation

Well... there are multiple engines for including Perl in a web page like Mason [masonhq.com] and Apache::ASP [apache-asp.org].

But the Perl world is moving away from code-in-html. Generally, it is considered a better idea to isolate UI and logic from each other. The web frameworks for Perl, like e.g. Catalyst and Jifty, generally use Template engines like HTML::Template and Template Toolkit (Google/cpan yourself.)

Re:Perl vs PHP (1)

budgenator (254554) | more than 7 years ago | (#16703185)

I'm been using Smarty [php.net] templateing engine recently and I have to say that the break even point for using templates Vs. "sprinkling some PHP in HTML" has almost hit bottom! Getting the code out of the page lets the programmer actually see what he's doing and think more about doing things the right way.

Re:Perl vs PHP (0)

Anonymous Coward | more than 7 years ago | (#16703541)

I don't understand smarty, PHP has always been a templating language. Any half decent PHP coder always used str_replace() templating for small sites over and above a 2 hour hack job. For more serious projects where you can't avoid PHP, employ an MVC architecture.

Smarty makes for a rediculous and bloated, PEBKAC solution!

Re:Perl vs PHP (1)

Sepodati (746220) | more than 7 years ago | (#16705203)

Smarty is pretty useful, imo. I'll agree that it's bloated a little and I'd love to see a "Smarty-Lite" version that gets rid of the fat, though.

No matter what, you have to come up with a templating solution. You can use PHP, of course. Regardless of project size, it's useful, but you end up with raw PHP code in the template. If you're the programmer for each, that's fine, but you don't want to be handing over templates to your designers where they can enter any PHP code and have it executed (or error out your script if they hack something up incorrectly).

Or you can roll-your-own. It's a solution, but now you're screwing the guy that comes in behind you and has to figure out what you did. If you designed it well and commented / documented it, then perhaps whoever's next is set... but how many people can you rely on to do that?

Smarty gives you a decent solution compared to each of the others. You don't have raw HTML in the templates. Designers can have pretty much free reign of the templates and you don't have to worry about them much (it's on them to make them work, right!?). You've also got a documented third-party system that's fairly well known. I guess we could argue over whether it's well documented or not, but it suits my needs (the documentation, I mean).

I'm in no way involved with the development of Smarty, btw. Just a happy user.

---John Holmes...

Re:Perl vs PHP (2, Insightful)

Qbertino (265505) | more than 7 years ago | (#16708969)

PHP is a descendent of Perl - it was originally programmed in Perl to extend Perl with templating functionality. That's long ago, but it still shows in the overall quirkyness of PHP wich is of a simular 'flavour'.

That been said, PHP has by far the largest set of available tools to help you do big projects of any web-oriented PL. Tons of commercial and/or OSS IDEs (PHPEclipse - especially the easyeclipse distribution - is awesome for a free tool), Debuggers, etc. It's pratically maried to MySQL (tons of tools aswell) and half of googles database is filled with PHP tutorials and forum threads on common PHP/MySQL gotchas.

If you want to do web stuff and unless you're in on some super complex parsing and data migration problem I'd strongly recommend PHP. If you're doing serial data-migration and plan on heavy use of Regular Expressions to solve your problem or have some other exotic procedural problem to solve that doesn't involve building a webapp, I'd suggest Perl over PHP. ... I'd actually recommend looking at Python aswell (my personal favourite), but that's not what you asked for. ;-)

Lemme guess: (1)

tonigonenstein (912347) | more than 7 years ago | (#16700607)

char buf[1024];
scanf("%s", buf); /* oups */
When you could do
std::string buf;
cin >> buf;
This is 2006 people, buffer overflows are so 1970.

Re:Lemme guess: (1)

LizardKing (5245) | more than 7 years ago | (#16701083)

Or even:

BufferedReader in = new BufferedReader(new FileReader("foo.in"));
for (String s = in.readLine(); s != null; s = in.readLine()) {
// do stuff ...

Re:Lemme guess: (1)

everphilski (877346) | more than 7 years ago | (#16701787)

Because I'm lazy and that is way too much typing. C++ FTW.

Re:Lemme guess: (0)

Anonymous Coward | more than 7 years ago | (#16707097)

What about Perl?
open(FILE, "foo.in") or die "can't open foo.in";
while(<FILE>) {
    do stuff...

Re:Lemme guess: (1)

elFarto the 2nd (709099) | more than 7 years ago | (#16701283)

char buf[1024];
scanf("%1024s", buf);


Re:Lemme guess: (1)

LizardKing (5245) | more than 7 years ago | (#16701887)

Nope, the string format field width should be at least one byte less than the array to allow for a null. See the description of the 's' format in the scanf(3) manpage [openbsd.org].

Re:Lemme guess: (0)

Anonymous Coward | more than 7 years ago | (#16703031)

Thank you, that was the joke

Re:Lemme guess: (0)

Anonymous Coward | more than 7 years ago | (#16702149)

So are you saying that switching from c to c++ will fix it?

iostream bloats your binary (1)

tepples (727027) | more than 7 years ago | (#16722457)

Thing is, familiar implementations of C++ (including GCC on Windows) will bloat your executable by 200 KB if you use std::cin and std::cout of <iostream>, even if you strip it (gcc -s). It's especially a problem when trying to make a web server on a custom embedded OS that runs on a machine with 4 MB of RAM. Is this a problem peculiar to GNU C++?

Re:iostream bloats your binary (1)

TheSunborn (68004) | more than 7 years ago | (#16723835)

I tried to compile the following program, on my fedora core 5 using
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
Generating 64bit code.
#include <iostream>
#include <string>
using namespace std;

int main() {
std::string buf;
cin >> buf;
cout << buf;
return 0;
And the size of a.out after strip vas 7016 bytes. That is using dynamic linking. If I static link it insted, it grow to 1 MB.

Re:iostream bloats your binary (1)

tepples (727027) | more than 7 years ago | (#16725881)

And the size of a.out after strip vas 7016 bytes. That is using dynamic linking. If I static link it insted, it grow to 1 MB.

On Windows, using latest stable MinGW package (they're stuck at gcc 3.4.2), I do

g++ -Wall -O -s bighello.cpp -o bighello.exe

and get 275,456 bytes for the same program. I guess it's static linking at least part of the C++ standard library. Most notably on embedded systems, you have to either static link or load the C++ library into RAM.

Re:iostream bloats your binary (1)

gbjbaanb (229885) | more than 7 years ago | (#16740189)

and, for those interested, using MS Visual C++ v8 with all the default options it comes out as 6656 bytes. Obviously, statically linked it'll grow somewhat (to 114k strangely enough. I was expecting more)

Alternatives (0)

Anonymous Coward | more than 7 years ago | (#16701131)

In light of the recent MS/Zend announcement and because I've been suffering PHP for too long, it's time for me to start recoding all my sites. I've been looking for a replacement and I narrowed it down to these contenders:

  • Erlang [erlang.org] - Do I really want to recode all my apps using tail recursive functions?
  • lua [lua.org] - Love the language but there's breakage between versions and poorly maintained libs.
  • Haxe [haxe.org] - New, I don't do flash. I'm only interested in server side code.
  • Pike [ida.liu.se] - Much cleaner and faster than PHP.

What language/runtime combination are other PHP users looking to switch to?

Perl, Python and Ruby zealots need not respond!

Re:Alternatives (1)

Bogtha (906264) | more than 7 years ago | (#16702467)

Perl, Python and Ruby zealots need not respond!

Good thing, I'm only pro-Python, not a zealot then. I switched a while back, and got a big productivity boost. mod_python+PostgreSQL+Kid for templating works nicely. Just moving over to Apache 2.2 now, and considering replacing Kid with Genshi [edgewall.org]. Currently hosting legacy PHP apps on a separate proxied Apache instance, but looking at running them as Python WSGI layers with WPHP [pythonpaste.org].

There's a lot of movement in the Python web development space right now - Turbogears, Django, web.py, Pylons, WSGI... it's unlikely that there's nothing that would appeal to you.

Re:Alternatives (1)

DragonWriter (970822) | more than 7 years ago | (#16705623)

What language/runtime combination are other PHP users looking to switch to?

I'm not really much of a PHP user, though I've toyed with it, and I'm not really looking to switch, but you may want to look at REBOL [rebol.com], though its not F/OSS (there are "free-as-in-beer" versions, and the commercial versions are rather inexpensive.)

Already switched to. (1)

Generic Player (1014797) | more than 7 years ago | (#16706671)

I'm using pike right now. I actually started writing a web framework for pike. If you don't mind having to write statically typed code, but getting run time type errors anyways, then pike is a good choice. If you need strong typing though, then keep looking. Ocaml is nice if you can tolerate its syntax, but I personally find:
function arg1 arg2 arg3;
to be a terrible mistake, as
function(arg1, arg2, arg3);
is much clearer.

You don't know OCaml. (0)

Anonymous Coward | more than 7 years ago | (#16709785)

You can use your bracketed arguments syntax very easily with OCaml. What you're effectively doing is passing your function a tuple. See this code, for instance:

let sum_curried a b c =
    a + b + c

let sum_tuple (a, b, c) =
    a + b + c

let _ =
    Printf.printf "%d\n" (sum_curried 1 2 3);
    Printf.printf "%d\n" (sum_tuple(1, 2, 3))

Notice that the last line employs your syntax, and works the same as the curried function call in the line immediately above it.

Of course, curried functions are often very useful. Anyone who did actually know OCaml would clearly understand the power of partial function application, and thus would find your idea completely lacking.

Are you on drugs? (1)

Generic Player (1014797) | more than 7 years ago | (#16711621)

Your post is complete and utter nonsense. Did you even bother to read my post? Yes, I do know ocaml. No, you cannot use a C style syntax for function calls (unless you work some camlp4 magic). Passing a single argument that happens to be a tuple is not the same as passing 3 args. You even pointed out how dumb your response is in your response! If you define all your functions to take tuples, currying is gone.

I don't want to pass my functions tuples, I want to pass it the seperate args. I just wish ocaml used a readable syntax, like I said. Trying to use C style function call syntax in ocaml gives you ENTIRELY different behaviour, and its not in any way the equivilent of calling the function with seperate args. My complaint is that the syntax for calling functions:
func arg arg arg
is much less readable than the tried and true C style:
func(arg, arg, arg)

Wishing the syntax was nicer is not the same as not knowing the language, next time try using your brain before you use your keyboard. How can you write a reply that actually points out how stupid the reply you're writing is, and yet still click the submit button anyways?

You moronic pile of dogshit. (0)

Anonymous Coward | more than 7 years ago | (#16712401)

You've convinced me even further that you know next to nothing about OCaml, and just as little about C.

First of all, the semantics of C functions does not include support for currying. So if you want C-style functions in OCaml, accepting your parameters as a tuple in OCaml offers the exact same semantics as a C function call.

Second of all, the C-style function syntax is far more verbose. At the very lease, one more character is needed. In your example, three further characters are needed. It gets worse as the number of arguments that are passed increases. That's just not an efficient thing to be doing.

If you can't adapt to such a minor syntax variation, then you just plain shouldn't be a software developer. You remind me of an old Pascal hack programmer I worked with on an Objective-C project at one firm. The stupid fucker couldn't handle using Objective-C's = operator for assignment, so he'd use a preprocessor macro to define := to be =. I'll give you credit, you're not as much of a jackass as he is. Long story short, the rest of us developers shunned his sorry ass, and threw out his code. He was gone after the next code review.

Ok, you got me on the first one. (1)

Generic Player (1014797) | more than 7 years ago | (#16713151)

I try to give ACs the benefit of the doubt, and the first reply was just barely sane enough to get me to bite, well done. But you can't just go jumping way overboard like that, its WAY too obvious you are trolling now. Try to stay subtle, or at least turn up the crazy a little more gradually.

Yeah, run you little whiney bitch. (0)

Anonymous Coward | more than 7 years ago | (#16715059)

That's just the thing a sissy like yourself would do: run away. The facts smacked your sorry ass down to the ground, brother. You don't know OCaml. You don't know C. And since you can't face those truths, you just have to cry "OmG!!!#!!@! Tr0LL!!!@!" and scurry away.

Stay away from OCaml. We don't need idiots like you making stupid technical suggestions, especially when you don't have any idea as to how infeasible and just plain fucking stupid your proposals are. Go back to fingerpainting, you dumb little twit. That is, if you can handle it.

Re:Yeah, run you little whiney bitch. (0)

Anonymous Coward | more than 7 years ago | (#16726985)

learn from your mistakes and move on once you expose yourself its over you cant bait them back. the c doesnt support currying thing was too much nobody is stupid enough to think your for real after that. you should have played up the far more verbose angle and gone on about how many man hours and millions of dollars those parens would cost the economy and shit. thats just crazy enough that its still funny if they buy it but still beliefable enough they might actually fall for it

Re:You moronic pile of dogshit. (0)

Anonymous Coward | more than 7 years ago | (#16727049)

He may be right and you are a troll. But I think you could just be really, really stupid. He said syntax. Like everyone who's used ocaml and has two brain cells, he wishes the syntax didn't suck. Do you seriously not understand the difference between "syntax" and "semantics", or are you really a troll?

Let me guess, you love the +. bullshit too right, because if you used + for both ints and floats, then it would suddenly get magical C semantics and start doing implicit casts right? But +. is "far more verbose", lets fork ocaml together, and redefine the syntax so everything takes as few keystrokes as possible. Why use "let", that's way too verbose. How about "l". And "lr" instead of "let rec". Oh man, this new, even less readable ocaml is going to be great! You're a genious!

Which is it? (0)

Anonymous Coward | more than 7 years ago | (#16701437)

Fixed a possible buffer overflow in the underlying code responsible for htmlspecialchars() and htmlentities() functions.

Easier for some to rewrite htmlentities() as html_entities() in PHP than deal with buildconf fuckage!

Re:Which is it? (0)

Anonymous Coward | more than 7 years ago | (#16701695)

Cheaper than rebuilding PHP & extensions when charging clients by the hour.
function html_entities($str){
  return strtr($str, get_html_translation_table(HTML_ENTITIES));
Use recursive grep to get a list of files, sed to replace func names and then manually include_once() or require_once() above code where it is needed.

PHP (1)

CopaceticOpus (965603) | more than 7 years ago | (#16703583)

I agree that PHP can encourage a quick-and-dirty approach, and that the language is not perfect. The function naming and lack of namespaces are poor, and internationalization has a long way to go.

That being said, I believe it is possible to create high quality, professional, maintainable code with PHP. If it wasn't the case, large companies such as Yahoo wouldn't be adopting it. PHP has an emphasis on productivity, and it doesn't attempt to enforce good practices in the language structure itself. But it also doesn't prevent a skilled programmer from using good practices. If you are having so many difficulties with your projects, you may want to take a look at who is writing the code.

I'm not discounting that you have some valid points, but I also think your view is overly harsh. I've worked in many different languages, and they all have their faults. I find myself favoring PHP because it allows me to get good work done efficiently.

My wish (1)

Espectr0 (577637) | more than 7 years ago | (#16739991)

Since every version of php breaks compatibility somewhere, how hard would it be to rename all functions to maintain consistency in php6 or 7?

PHP has got to be the most inconsistent language out there. Check out this list [tnx.nl]

        * Arguments and return values are extremely inconsistent
        * PHP has separate functions for case insensitive operations
        * PHP has inconsistent function naming
        * PHP has no lexical scope
        * PHP has too many functions in the core
        * PHP lacks abstraction and takes TIMTOWTDI to bad extremes

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account