Those pages were written prior to 2006*. Got anything recent?

* PHPv3 did indeed suck by current standards, but it did what it was designed to do. V4 was like a teenager learning to drive.

Lots of functions are not a bad thing and minor inconsistencies like hyphens and underscores in function names are typical of community-developed anything.

Yes, and to add to that, what's wrong with a little variety? Does everything have to be homogenized? Do we all have to live in tract housing? Honestly, I couldn't give a rats butt that some function use underscores and some don't.

oh, this is just the old 'Esperanto' debate applied to computer languages. sure, southern European languages are a mess of corruptions of Latin, with idiosyncratic usages and forms, strange illogical aberrations, odd pronunciations, and the like. Esperanto is a nice, neat, clean, organized, logical, well-designed substitute that's much more efficient to use and easy for everyone to learn. Esperanto is better than French, Italian, Spanish, and etc in every way possible except that no one uses it.

PHP is perfectly fine once you get used to its oddities, and in some ways its easier to use than a more sophisticated language like Ruby or Perl (both of which are brilliant at making clean, concise code, but which require a lot more mental effort to create or understand).

Which is why I'm a little surprised that it goes on with such ferocity. They're just languages! None of them do exactly what I want, when I want it. They all require me to do things their way when I want to do them mine!
Here's a Ruby snippet I took from another site:
and it's php equivalent (not tested, so I've probably made a mistake or two):
I think it's the similarity that irks purists more than the differences, although I'm sure the differences act as speed bumps when moving from one to the other.

That's a peculiarity of human nature. Big differences are just differences, because there's no meaningful comparison; small differences have a meaningful comparison, and so they have to be right or wrong, which makes people argumentative. Christians have never had more than passing difficulties with Buddhism or Hinduism as faiths, but have slaughtered other Christians in droves over minor doctrinal issues. Human=Weird. :)

sorry, that should be Human==Weird. logical equivalence, not assignment... :D

Minor/big problem: :D
Human === Weird
Logical equivalence, both value AND type. :p

Well, OK, if you write a program in C, and then massage the syntax as little as possible to shoehorn it into two other languages, both translations are still going to look pretty much like the C version, and therefore like each other.

For the Ruby version, how about:
That's not only more in keeping with the style of Ruby, it's also more efficient and (with experience) more readable. In the C-style version, your mind is being distracted by having to figure out the significance of all those extraneous variables (degree, value) and making sure they're initialized correctly. (degree = coefficient.length - 1? Why -1? My OBOB detector goes off on that line, and I have to take a mental side trip to satisfy myself that it's correct. And x**degree? Why is there an exponentiation operator in this at all? You can evaluate a polynomial using only add and multiply.)

well, the PHP version could be reduced to
and this is pretty much what I meant: the Ruby version is way cooler (from the code-geek perspective), but you can understand the PHP version without a magic wand and decoder ring. :eek:

It wasn't my intention to optimize anything, but it seems to me the "optimized" versions look like each other too. ;)

Actually I do find this annoying - have to keep checking the references for the proper syntax. And there's the odd haystack/needle vs. needle/haystack order issues.

But it's not bad enough to make me want to learn Perl :rolleyes:

It's not a matter of optimization, so much as reducing the mental load. The "optimized" PHP introduces an extraneous loop variable (i) and a bug (it applies the coefficients in the wrong order). It still uses exponentiation instead of multiplication, but that's merely optimization. It also still looks like C, which I guess makes it "more readable" if you already know C (and of course everyone should), but you can hardly hold up C's bizarre for loop construct as a paragon of clarity to anyone who doesn't already sport that decoder ring.

You're also using indexing in the PHP version (as you did in the C version), so the coefficients have to be an array. The Ruby version only requires the coefficients to be enumerable. (In C++ terminology, you're requiring a random access iterator where an input iterator would have sufficed.)

This example is so tiny that it's hard to appreciate the significance of these distinctions. The thing is, the C/PHP version is constructed from smaller mental "chunks" than the Ruby version, so you need more of them. That means it takes more mental effort when reading the program to figure out what it does.

It's like the difference between a 1000-piece jigsaw puzzle and a 500-piece jigsaw puzzle. The number of pieces makes a huge difference in the time it takes to assemble the puzzle.

that's backwards, I think. the Ruby version may have fewer conceptual chunks, but the chunks it uses are more complex and abstract, and so more difficult to work with. when it comes right down to it, the logical task is the same in both cases; what differs is the shorthand we use for writing that task down. it's like different compression formats for an image. bitmaps take up more space but are very easy to process computationally. jpegs take up less space, but need more computational power to decode. same picture though.

Or in other words: yes, you can evaluate a polynomial with only addition/multiplication, but exponents are faster, even if the code looks slicker without them.

Ugh, Perl... if the world was about to be destroyed by a giant bomb and I had to learn Perl to disable the computerized fuse, I'm not at all certain it would be worth it. :D

On the positive side the giant perl-coded bomb would destroy perl too.

But is it the language, or the people who code in it? There seem to be two types of programmers: those who look for the best way to obfuscate their code, and those who plan on being able to make changes in the future. Maybe Perl attracts more of the former.

so what you're saying is that it's like throwing Perl before swines? :p

I was trying not to. :D

In the interest of accuracy, I need to correct myself and point out that php doesn't do exponents as:

$a^$b

It does them this way:

pow($a,$b);

One more thing for its detractors to gripe about. :eek:

Not at all. The ruby code uses only one conceptual chunk: if you have a sequence of values, you can form an expression by "injecting" a binary operator between them.

If you have the sequence a, b, c, d,

you can form the sum by injecting addition: a + b + c + d
you can form the product by injecting multiplication: a * b * c * d
you can form the longitudinal checksum by injecting xor: a ^ b ^ c ^ d
or in general, inject an arbitrary binary operator op to get a op b op c op d

In each case, these operators associate left-to-right, so the expressions are really evaluated as
(((a + b) + c) + d)
(((a * b) * c) * d)
(((a | b) | c) | d)
(((a op b) op c) op d)


All you have to do in ruby is tell it which binary operation to inject.
The polynomial ax^3+bx^2+cx+d can be more efficiently written as
(((ax + b)x + c)x + d)
which we get by injecting the operator op defined by v op c == v*x+c.

And that's exactly how it's written in ruby:
coefficients.inject {|v,c| v*x+c}

or in words "given the sequence of coefficients, inject the operator which, on arguments v and c, computes v*x+c. Return the value of that expression."

Notice that there's no need to create a loop. We're just building an expression. (Sure, there's a loop going on under the hood, but we don't need to think about that, any more than we need to think about all the dictionary lookups and memory management and subroutine calls that are also going on under the hood, in both languages.)

Since we don't introduce a loop, we don't need to grok C's baroque for loop syntax, nor do we need to introduce the auxiliary variable $i whose sole purpose is to keep track of our progress through the loop. No need to count how many coefficients there are. No need to treat the coefficients as an indexable array (as in the expression $coefficient[$i]).

In ruby, it's just a sequence, and we're just injecting an operator into it to form an expression. One simple (albeit powerful) concept.

Well, OK, two concepts. We're using the fact that lambda expressions are easy to write and easy to use. In ruby they're called blocks; {|v,c| v*x+c} is an example of one. You don't write much ruby without using lots of blocks.

Oh, and BTW, multiplication is a LOT faster than exponentiation.

Sure, one multiplication is faster than exponentiation, but that's not what you have:

a0 + a1x + a2x^2 + a3x^3 + ... + anx^n

can be written in your (((ax + b)x + c)x + d) form, but only by using a loop, which is exactly what inject does. The result is many multiplications and many additions. Remember, we don't know how many items exist in the array: coefficient.