Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

121–130 of 673 posts

Re: Taking PHP Seriously

#121

Post by bbcbasic »

hueving wrote: post #96
swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

This sounds like to me you are mistaking the popularity of PHP with the proficiency of the developers. PHP has been around a long time and is used by lots of people. Even if PHP projects only have a 1% success rate and haskell projects have a 20% success rate, guess which one will have more "successful projects".

I think the point is that for most "tech startups" they are marketing-first and tech-second.

If PHP gets you to first base (MVP) in 10% of the time than NiceLangX then you get 10 X more chances to throw shit at the wall and see what sticks.

Re: Taking PHP Seriously

#122

Post by badminton1 »

throwaway729 wrote: post #101
badminton1 wrote: post #79

Earlier quoted context omitted.

> "The next guy to join the company will clean up your shit" Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter. Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately. The world of difference between balancing trade-offs in…

> But suddenly because you are an "engineer" this is acceptable? No, it's acceptable precisely because you aren't an engineer. We software engineers in the US are not bound by a formal code of ethics like more traditional engineering disciplines. We're not required to invest a certain amount of effort in the security or accessibility or maintainability implications of our work. And, most importantly, we are not legal…

No.

And software engineers in the US, are actively losing their jobs to H-1Bs precisely due to this reason. Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY.

Say that aloud in an interview or in a 1:1 with your manager and let's see how quickly they make you a job offer or get you promoted.

You don't, because you have you keep this to yourself because you know it is wrong and not in the best interest of your employer... Who is wrong now?

Re: Taking PHP Seriously

#123

Post by OhHeyItsE »

Much of this is valid in spirit. But to me, is irrelevant with the advent of Node. Node does all the good things the author describes. It does some terrible things too, but generally does them much less terribly than PHP.

Re: Taking PHP Seriously

#124

Post by JED3 »

TLDR; Because Cal Henderson made the initial commit.

He's obviously a big fan of the language, and surely had a big hand in influencing what technology would be chosen very early on.

PHP can be like playing with dynamite. If you have an explosives expert on site (or Cal Henderson), you can get a helluva lot done with PHP in a very short amount of time.

Re: Taking PHP Seriously

#125

Post by swalsh »

badminton1 wrote: post #79
swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

> "The next guy to join the company will clean up your shit" Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter. Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately. The world of difference between balancing trade-offs in…

The next sentence tells you where I'm coming from, but to expand a bit... here's my theory of software development in the point of view of a new company. If you have an existing product, you're already in phase 3...and sometimes phase 3 rebuilds the product. This does not apply... you already know what the software is.

There are 3 phases:

Phase 1: Initial development - Your goal here is to find the value to your user. Any code you write here should be considered disposable. If it's not valuable to your customer, it's not worth building right... if it takes time before you know it's valuable to your customer, it's not worth your time. If you're writing it to support millions of users, and you only have 100, you're wasting your time. In phase 1 you're concerned about creating revenue, and nothing else matters. Wasting time on worrying about what is going to happen in Phase 2 might take time away from you before you reach it.

Phase 2: surge development - This happens after you've discovered some value for your user. Now the code you write is worth something. You should consider making phase 3's job easier. Proper design patterns etc. But your main concern is replacing the shitty parts from phase 1 with better code (if it's something you touch a lot) and getting it to scale for your now growing user base. You have to make strategic investments here. If you're spending your time making an ugly file that never gets touched better, you're wasting your time. If you're worried about making your code more efficient so you can support more users when another $100/month server would solve the problem, you're probably wasting your time. In phase 2 the company is still mostly worried about revenue, but you have a decent chance of making it into phase 3, so it makes sense to think about it.

Phase 3: maintenance. - In this phase, you're no longer searching for the value for the customer, but rather searching how to shore it up, how to be the best at providing it. Now tech debt is less okay. Crap quality software will lose money, so you should spend time making it bullet proof. Your revenue isn't growing like it used to, so you have to extract as much from it as you can.

Re: Taking PHP Seriously

#126

Post by orf »

rrdharan wrote: post #7
justinlardinois wrote: post #5

PHP was the first programming language I ever used, so it holds a special place in my heart. And I use it daily at my current job. I have to disagree with this article. PHP is a heavily flawed language. It's very easy to get started with PHP, but there are too many pitfalls that are too easy to fall into. Most of the "Virtues of PHP" are available in other web languages if you use the right framework. And if you use…

Zero startup time and a serious JIT aren't actually available in Python or Ruby even after all these years. I would be hesitant to dismiss the significance of those - although I'm admittedly biased, having worked with Keith previously as well as on an erstwhile "competitor" to HHVM (talariatech.com).

> Zero startup time

My pretty heavy Django app takes about half a second for Gunicorn to boot 6 workers then it's off to the races. That might as well be zero startup time.

Re: Taking PHP Seriously

#127

Post by jamroom »

brian-armstrong wrote: post #98
swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

I'll offer an alternate hypothesis. Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum. It's easy to cherry-pick the winners and miss all of the t…

I've gone one step further and created a template:

Some companies are succeeding in spite of [insert language]. There are many, many users of [insert language], and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum.

It's easy to cherry-pick the winners and miss all of the tremendous losers who picked [insert language] and got nothing for it.

Re: Taking PHP Seriously

#128

Post by d0mine »

swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

Accumulating bad code is like pushing your company from a plane without a parachute and hoping that the next guy creates enough cushion in time before the landing destroys the company (not the fall that kills you)--you survive because you are likely moved on and are busy pushing some other company to its doom.

It is probably ok if you work for a startup that does not survive long enough for the quality of your code to matter anyway. But in a regular company, your attitude creates a time bomb when eventually any apparently simple change may destroy the codebase (and at best, it just takes too long to make any change).

Bad code isn't Technical Debt, it's an unhedged Call Option http://higherorderlogic.com/2010/07/bad-code-isnt-technical-...

Re: Taking PHP Seriously

#129

Post by tracker1 »

rpeden wrote: post #9
overcast wrote: post #3

Earlier quoted context omitted.

As long as you don't mind working on "boring" projects, there is TONS of small businesses in need of custom work to be done. It's very lucrative, because most people like you said, turn their noses up at the thought of it.

Boring isn't always bad. Last time I tried to create an interesting project, I ended up with a couple hundred MB of node modules before I'd even done much. :)

That's a fair criticism in node... I wouldn't want to work on it without an SSD (deployment is a different story)... the spinup and even npm install time on an HDD is dramatically slower than SSD.

It's also not that hard to roll your own system and avoid many of the modules and frameworks in the space. The first API I wrote using node wasn't bad at all, and in the end actually simpler than the rewrite using express... And by the time you get to Hapi with a few addon modules for your needs, it'll get pretty big.

All of that said, I still prefer it to just about everything else I've worked in... though I haven't done anything on Go or rust, but would like to.

Re: Taking PHP Seriously

#130

Post by badminton1 »

swalsh wrote: post #125
badminton1 wrote: post #79

Earlier quoted context omitted.

> "The next guy to join the company will clean up your shit" Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter. Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately. The world of difference between balancing trade-offs in…

The next sentence tells you where I'm coming from, but to expand a bit... here's my theory of software development in the point of view of a new company. If you have an existing product, you're already in phase 3...and sometimes phase 3 rebuilds the product. This does not apply... you already know what the software is. There are 3 phases: Phase 1: Initial development - Your goal here is to find the value to your user…

That's what I said: there's a difference between calculated trade-offs between short term and long term and "I got no time for that, let the next guy clean it up, haha!!".

If you are rational you will understand that technical debt is a cost, and unless you are sabotaging the project you won't add cost without a good reason.

Prototyping and iteration is fine. Throwing away prototypes might be fine. But selling a functional prototype as a finished product IS NOT FINE. It's morally wrong. And unless you want to be lynched like the Theranos people you better not get caught doing this.

Post reply on HN