Hacker News Reader

Comment by staunch | Hacker News Reader

Why not transition to a different language over time? One that more great programmers want to use?

There's no reason they couldn't (over the course of years) move to another language. I'm not suggesting a total rewrite, but they could start writing entirely new subsystems in a new language. It's very rare to have 100% of your code in one language anyway.

Recruiting great programmers is one of the most important things in a software startup. Why stick with PHP if it makes that far more difficult?

View on HN

Probably because you overestimate the added value of Python and Ruby over PHP and underestimate the cost of language migration.

Language is not that important. Your engineers are. They will easily compensate for suboptimal tools.

The best hint for this is that most (>70%) of the money goes into salaries. Not software. Not hardware. Not office space. Salaries.

> Language is not that important. Your engineers are. They will easily compensate for suboptimal tools.

That's exactly his point: it's much harder to find great engineers who want to use PHP.

Disclosure: I'm a PHP developer who has had to hire PHP developers in the past.

I disagree with this. It shows a lack of maturity to reject a job over a specific tool.

Why take a job where you would be working with a language that makes you miserable? It would be bad for both you and the company when you leave in several weeks.

I've turned down a job before specifically because I didn't want n years using MUMPS on my CV.

(Okay, they didn't actually offer me the job, but I would have turned it down anyway.)

What? Lack of maturity? You only live once. I'm not going to spend my formidable years toiling away with tools that make my miserable any more than I would work for a manager who thought yelling/bullying was a valid management technique.

If you think it is difficult recruiting good PHP developers in your area you will have almost no hope getting good Ruby or Python developers.

At my office we use a mix of languages. PHP for the services, Ruby for one set of management panels and Python for one of our other systems.

So during interviews we're happy with anyone that knows any of these with the intention of cross training when needed. During times when there is a shortage of good PHP developers to be found there is usually a shortage of good developers period.

I would understand why a great engineer might get annoyed by having to use PHP, but I think that the larger quantity of people that do know PHP would probably make it easier to find a great engineer in a pool of people that know PHP.

"The best hint for this is that most (>70%) of the money goes into salaries. Not software."

I'm not sure what that proves, considering all the languages we're talking about are free, and the largest price you have to pay is probably for the IDE (which also tends to be free).

Well, the post does imply that they've had problems recruiting exactly because they're using PHP. It's no mystery to me either, I imagine it must be hard to find great engineers willing to spend all their days dealing with the idiosyncrasies of PHP.

Great salaries is a great thing, but what if your competition offers great salaries and a less obnoxious programming environment than PHP (and better hardware, and better office space, for that matter)?

> most of the money goes into salaries.

And, therefore, anything that makes your engineers more or less efficient goes directly to your bottom line.

(I agree that the comment you're replying to underestimates the cost of migration. But the problem isn't a failure to understand that salaries are the main cost; that's exactly the thing that makes moving to a better langage attractive.)

and if an engineer moans and moans about his tools, and refuses to work in anything but his favorite language, I would say he's an absolutely terrible engineer.

Great programmers can make great stuff using anything.

Then hand out the ed editor to all your engineers who should be programming in assembly. If they're great they'll be just as good with all that, right?

Or maybe they'll bitch up to high heaven because doing that makes them slower. Engineers don't bitch about using shitty languages to be whiny Prima Donnas. They bitch because using shitty languages makes them slower.

People like to feel like they're getting things done. If they're using a language that looks like it was put together from newspaper clippings every step takes much longer than it does with proper tools. And that makes people mad. In fact, I would go so far as to say the ones who don't bitch are the absolutely terrible engineers because they must be doing it just for the billable hours.

Go find the most genius engineer you can in any other field and make him work with the crappiest tools you can find that he can still eventually get his work done with and see how well your assertion holds.

Yes but good coders figure a way around it.

Forced to use PHP? And it's crappy and slow to build stuff in? So write some tools that compile to PHP.

What I'm saying is that great programmers work with the limitations and build the tools they need to make the limitations moot.

PHP isn't even a good compilation target. There's no native FFI (you can't write pure PHP code that makes arbitrary syscalls), the extension interface exposes extremely brittle guts of the interpreter, it performs very poorly (compared to, e.g., JVM bytecode), and calling user-defined functions to work around the stupid misbehavior of the builtins (e.g., == which isn't even an equivalence relation) is only going to make its performance worse.

Presuming you're a great engineer that dislikes PHP, you'd take a crappy language and build hacks on top of it? Your great engineers would probably have better things to do with their time. Artificial constraints are great for creativity; for engineering, they're just time-wasting and your good engineers will go elsewhere.

(unless you're the single exception where your business is just that compelling...)

Great programmers can make great stuff using anything.

Just because I _can_ doesn't mean that I _want to_.

I'm willing to work in lots of environments. In the last 2 years I have done projects for pay in Perl, PHP, Java, C++, Python and various in house languages you probably haven't heard of. However I have to be paid a healthy premium for the displeasure of working with PHP. And if I was asked to do it all the time, eventually I'd leave and find a better job working in something else.

I thought the actual programming problems also mattered to great programmers.

Would you rather do something boring in a beautiful language vs. something interesting in an ugly language?

That's a false dichotomy. There are plenty of interesting problems to be solved out there offering the use of better tools than PHP.

Only if they're greenfield projects. But if you're a job hunter, and there's a really interesting project using legacy code in a language you don't like, are you going to turn down a job offer because of that?

Ah, finally.

"if an engineer moans and moans about his tools, and refuses to work in anything but his favorite language, I would say he's an absolutely terrible engineer."

Let's say he's great enough to get lots of job offers. And let's say that among those, the ones in his favorite language - the one he actually enjoys using - also tend to pay more, and his average coworker in them is more proficient.

Is he terrible to start filtering his job searches by that language?

Why not transition to a different language over time? One that more great programmers want to use? There's no reason they couldn't (over the course of years) move to another language

Probably because by the time they've transitioned to the more popular language, an entirely new programming language will be the one more great programmers want to use.

This. Why chase the latest fad while you can spend that time on working on the product? The workarounds for the issues that the proven solution has are well-known, and learning them is a sunk cost. The issues of the new platforms are yet to be found, maybe you need to fix them yourself, maybe the issues are different and you can fix it with different architecture.

Reply on news.ycombinator.com