I don't know really java, but in Python I just assign that object to a new variable and use that

e.g.

sd,

it sounds like you are coming from a personal perspective in which you write good php code, which i'm sure you do based on your javascript.

the other guys are coming from the perspective of hiring other developers or outsourcing. not sure what your experience is in this arena, but i think it's safe to say they have a point based on my own experience. you won't find, eg, hordes of offshore indian companies with monumentally incompetent programmers who work in ruby. at least i have not. you will certainly find them in php. i don't know if that makes it "fair" to blame the language or not, but i think that's where they're coming from.

It's not a matter of fair. But if you're going to have some weird prejudice against anyone who's used a highly popular language, just because it's so popular and widely deployed that every bad coder starts with it, then you're probably making mistakes.

FWIW, when I was in my epic search of a dev house here in LA, one company I spoke with told me they switched to Django from RoR because it got too difficult to find good RoR programmers because it got too popular and unless there was gem install, most of them were lost.

Can't people say this stuff about any language?

I blame the dev house there. Ruby is moving everything to gems, including the former core library.

You're right, I understand how that would be frustrating.

My personal experience with developers is limited, and I've never outsourced a coding job. But I have hired people for other things, and it's annoying to get bad work, especially since I often become fixated on reaching perfection (exhibit A: full re-write of the spell checker last 48hrs. It's far better now.)

Consider this -- If a group of plumbers using the same wrench produce terrible work, you wouldn't blame the wrench if it's proper function had been proven with insurmountable evidence.

My point is that assigning blame to a tool, when the creator's fault is objectively verifiable, wholly insusceptible to dispute, is a terrible and dangerous culture to develop within a community.

What strikes me as so odd is that in an industry where logic is king, a logical fallacy has taken hold with such effect that market shifts have resulted. Perhaps there's a lesson here. Never underestimate the power of a new trend, regardless of its merit.

Well PHP *is* undesigned. I don't say poorly designed; that would imply there was forethought. There wasn't. It's just thrown together.

But it's insanely popular. I don't know how it got so popular (PHPNuke?) but it is. And that's life. Some people are stuck coding in Windows-land, some people are stuck coding in PHP-land.

No one's saying that it's flawless. All languages have design flaws. It's also worth noting that design flaws are often a subjective matter.

What people are saying is that when bad code gets written, fault lies with the language, not the developer. That's silly.

Even more puzzling is the argument that coding PHP somehow forces developers to pick up bad habits, as if PHP has some sort of mystical power giving it mind control over programmers.

I mean, my God man, clowntable knows people whose careers were ruined because they made the mistake of learning PHP! It exercised its mind control powers, and sure enough, they turned out to be awful. Shame too, otherwise they would've turned out to be decent programmers:

it sounds like you arguing that just because a tool can be used well, it's a good tool. but an equally important question is: how do people naturally use the tool?

the people that read the whole manual could program their old VCRs too. but the process was often unintuitive. isn't it fair to blame the VCR makers, since it was possible to have made something better and more intuitive that even peopel who hadn't read the manual could figure out?

i'm not totally sure what the argument is anymore? are you making the case that php is in fact a better designed language than python or ruby?

I don't blame the dev house. I never saw anything like what they had in their showcase.

Do you think going all gem-install is a good or bad thing? Sounds great if they want to push RoR as a blogging platform. I know my shared host provider has RoR built-in.

Serious question, sdturner: Do you think PHP is a tad over-kill on all of the built-in functions?

http://php.net/quickref.php

It also has 73 reserved words, including "goto" which was introduced in PHP 5.3:

http://www.php.net/manual/en/reserved.keywords.php

I can't help but think there is something amiss here. It's advertised as an easy language, but I can most certainly see where an inexperienced programmer would get lost and create bad code very quickly.

i loved using GOTO in qbasic

i'm glad they brought it back

huh? dave what does "going all gem install" mean?

this is a consequence of the language's procedural beginnings

ruby has tons of "built in" functions too, but they're not free floating... they are the APIs of all the built in Objects like String, Array, Hash, etc, each of which have many many methods. So it's all organized in nice OO fashion, which avoids a polluted global namespace and also makes calling the methods more concise, and generally makes their meaning more intuitive and easier to recall

Probably got confused with this:

I thought that meant everything would be gem install. Maybe it's more like instead of installs, they are going more toward installing dependencies / modules or something of that order? This would be a pretty good thing if that makes you pick and choose and only have what you need. Sort of custom building.

I see....

http://www.tutorialspoint.com/ruby/r..._functions.htm

Most of them are pretty intuitive. But what is the significance of the bang?

chomp([ rs=$/])
Returns the value of variable $_ with the ending newline removed, assigning the result back to $_. The value of the newline string can be specified with rs.

chomp!([ rs=$/])
Removes newline from $_, modifying the string in place.

It seems like the bang mutates the variable, while the regular chomp creates a new variable? Is that about right?

The point is you can't do ruby dev without being able to install gems.

If the developers were coming in and expecting to be able to install gems, and their bosses were having a problem with that, then there was an impedance mismatch there.

bang means the original object will be mutated.

so arr.reverse would return a new array with elms in reversed order
while arr.reverse! would mutate the array pointed to by the variable arr

He was talking about the brogrammers.

Oh no, I'm not to comparing PHP to anything. My argument is entirely unrelated to other programming languages or their merits.

Actually, I'm arguing that only because a tool can be used well, it's a good tool. A tool's effectiveness, when correctly used, is not diminished merely because there exists a possibility that the user may misuse the tool. And thank goodness for that.

For example, I have no idea how to drive a bulldozer. If I jump in one right now, everyone would laugh if I declared the bulldozer to be faulty after accidentally taking out my neighbor's porch. They would laugh because the bulldozer was operating exactly as it should, and because my blame is proved by the fact that a competent operator would have not made that mistake.

Yet somehow, this is precisely the logic being followed when people see bad PHP code and conclude that fault lies with the language and not the developer. I have yet to see a case where someone wrote a correct PHP function, and yet the interpreter just said "Meh, I think I'll just do something else." (Even when it may feel that way)

We may part ways on this point because I don't know if I can agree that your example is analogous.

A consumer is correct to blame the manufacturer for their bad products. But consumer goods are not programming languages. Setting a VCR is an activity susceptible to objective measurement -- it was either done correctly, or it wasn't.

Programming languages are distinguishable in that there are varying degrees of skill involved in the activity. Because there often are many ways of achieving an identical result, and because optimal use is often dependent on particular circumstances, I submit that considering natural use of the language is by and large a fruitless endeavor.

But, I digress, because that really isn't a component of my argument. And even if true, it doesn't negate my argument that incompetent coders are to blame for bad code, not the language they used.

As I alluded to earlier, my interest in the debate arises from my opinion that negative views of PHP exist largely as the offspring of a suddenly popular to repeat logical fallacy (that I'll reiterate: blaming the programming language for the errors of the programmer). I think it's alarming that a community built on logic and reasoning, and so heavily relied upon by the public, could experience such a dramatic shift rooted in an error of reasoning.

by your argument, i could invent some incredibly arcane language that only PhD's with lots of training and practice could use, but, because this language *could* be used well, we can't criticize it?

whether or not the criticism of php is deserved is a separate issue, but you seem to be arguing on principle alone, and the principle seems plainly incorrect to me.

It might be, I honestly don't know. That is a rather common complaint about it, though.

I suppose the answer lies in balancing the utility of the many functions against the performance and usability penalties incurred by their presence.

I'd be less inclined to give weight to factors considering confusion for new programmers unless there were an equal risk of confusing users with an average experience level.

The performance is generally abstracted away, right? And then how do you determine the utility of which function to use? Do you generally chose to only deal with 10 functions and then maybe look up the rest as you need them?

I'm just thinking about the effect this would happen on someone that focuses on "learning languages."

I'd be massively confused and I stare a parenthesis all day.

Ah, I believe I see where our disconnect is.

Actually, I am arguing that this is the sole issue.

To be clear, my purpose is not to white knight for PHP because I think people are picking on it. I don't care anything about that. My purpose is pointing out that the most common criticism of PHP is based on a logical fallacy, and that this is indicative of an alarming trend in the development community.

That PHP happens to be the subject matter and also my language of preference is nothing more than a convenience for me (familiarity) and a distraction for others.

Of course it should be criticized.

Such an endeavor with almost zero utility certainly deserves harsh criticism. But the criticism is only valid and worthwhile if it's based on reasonable inferences drawn from facts. Criticism rooted in false equivalence, however, has no place in debate.

Which principle does it appear that I'm arguing for?

In the context of evaluating the quantity of functions in a language, if the mere presence of a function in the interperter is neither neither good or bad, all else equal, it seems that only a small amount of value would be needed to justify its continued presence.

As far as determining which function to use, from the perspective of a PHP guy, my opinion is that it's a complete non-issue. That argument seems to only come up when someone is offering evidence of how terrible PHP is.

I actually cannot recall a single instance of having to decide between two competing functions because they both had tradeoffs, or something. To be honest, the conclusion I've come to is that "too many functions" is a made up gripe someone once offered to support an argument.

I know there are people here with PHP experience, anyone ever actually run into this in real life? I'd personally be interested to learn something new.

My reason for that is a simple balancing test. The value of an experienced programmer to a language community far exceeds the prospective value of a potential member. Thus, the interests of prospective users should usually only weigh heavily in cases where experienced users would be similarly impacted.