Hacker News Reader

Comment by david | Hacker News Reader

What does "sane" mean in this thread? I can't figure it out other than "something that makes sense to the poster".

>> Need to find a PHP developer? No problem.

Not being able to hire just anyone to code for you is a good thing just as much as it is bad. It means you're going to have some pretty bright people working for you, which apparently is something Fog Creek values and can afford to do.

> Want a PHP IDE? No problem.

Most hackers have their own preferred editors anyways, and Emacs/vi/etc work well with any language if that's the editor you're experienced with.

>> A large community to handle bugs and any future development? Yes.

Again, that's a hindrance just as much as it is a benefit. If you need to make a change or fix a bug in the language, you're going to have much better luck if you know a bunch of people who are intimately familiar with how that language works, especially if their right down the hall from you.

View on HN

In response to your first comment I think the idea that developers that don't use PHP are better or brighter is absurd.

Not that it matters anyhow for most roles you neither need nor can afford to hire the best and brightest away from their current role which they probably love a lot(being the best gives you the ability to choose great places to work). So unless you're looking for a tech lead you're going to be looking for great, much better than average but not specifically the best and for those conditions PHP will give you a much larger developer base to choose from every day of the week.

As for the last point I think you're really reaching here to find a negative. A large community to handle bugs a hindrance? Seriously? And your alternative ideal solution is some people down the hall in your office that know how to use the language well?

Uhm, if the guy down the hall WROTE the language, that's gonna be a hell of a lot more useful than posting to a mailing list. Especially if you can't post your secret source code, so instead you have to spend a lot of time coming up with a simple test case you can post which demonstrates the problem -- whereas with the guy down the hall, he's allowed to see the code.

That's great if you work down the hall from the guy that wrote the language but unless you're talking about a niche in house language when it comes to web development you're talking about what half a dozen people that you can claim that against? And how many of those work at Google and the like?

The vast majority of people will never have the opportunity to be down the hall from that guy and for the vast majority of people a large helpful community will be infinitely more valuable.

>> The vast majority of people will never have the opportunity to be down the hall from that guy and for the vast majority of people a large helpful community will be infinitely more valuable.

Which means what to Fog Creek?

And what happens when the guy down the hall leaves the company?

Ah, well, then you're fucked. My point is not that you should consider it a good idea to make your own proprietary language, just that that situation can sometimes be a really good, productive one.

(I'm dealing with this in my work -- we use a proprietary internal scripting language, and the guy who wrote it is not around. I'm slowly becoming the local expert on the language -- very slowly, though, because opportunities to work on it don't come up too often.)

I think I introduced the word. I used it to describe the perceived relative merit of PHP vs. Wasabi/C++, where, in the example at hand, the sanity of PHP exceeds that of the alternatives for the given situation.

Reply on news.ycombinator.com