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

651–660 of 673 posts

Re: Taking PHP Seriously

#651

Post by spronkey »

guitarbill wrote: post #647
nucleardog wrote: post #638

Earlier quoted context omitted.

All of the languages you listed have a way steeper learning curve than PHP. PHP creates a lot of really small steps you can take getting from "I roughly understand HTML" to "I can build a full 3-tier MVC buzzword-of-the-day app.". For anyone not intending to become a full-fledged programmer, but instead just to add a little bit of interactivity/dynamism to their website, it's still the path of least resistance.

I'd argue that Javascript (sans all the frameworks and bullshit) will also get you there quicker, because of the intrinsic DOM connection. But yes, backend JS sucks. I also made a start with PHP. Still, PHP has been slow to learn from other languages and frustratingly refused to change established behaviour. I found PHP to be far more "dangerous" for the amateur programmer than other languages. Finally, I switched an…

echo "hello" vs... damn, how do you even print a line in Javascript (Node, to be fair)? console.log()? Wait no, that prints to a terminal. Response.write? Oh, wait, I have to implement the http.createServer callback? Yeah ok, oh and it's ... response.print? No, no it's response.write. Oh what it's not working? Oh I need response.end() as well.

Hopefully you get the point.

(I do agree that PHP without something like Symfony, Yii, ... Laravel, even Cake could be very dangerous, or at least, counter-productive for amateurs trying to learn though)

Re: Taking PHP Seriously

#652

Post by spronkey »

dyjakan wrote: post #408
chiefalchemist wrote: post #256

Earlier quoted context omitted.

Luck. Timing. Culture. Team. Etc. All have a greater impact than language. Anyone who says otherwise doesn't understand history.

Culture is correlated with technology, i.e. certain technologies appeal to certain kinds of people. You can go to any Ruby meetup and you will see it's different than PHP meetup which both are quite different from Functional Programming meetups. Thus I would say that it's not about the technology but about people whom you attract (i.e. culture). I skip luck & timing, these are mostly random and one has very little po…

All three of the above communities (PHP, Ruby, and FnProg) are diverse enough that a PHP meetup in location A could be culturally similar to an FnProg meetup in location B, and so on.

Re: Taking PHP Seriously

#653

Post by spronkey »

apotheon wrote: post #482
justinhj wrote: post #371

Earlier quoted context omitted.

Disclaimer I worked on a large php app server that ran on about 50 servers and I miss it. The documentation is really good. A model for programming language documentation. Process per request is really simple to understand and scale. Your servers almost never crash completely, you don't get threads silently dying or run out of memory or thrash the CPU doing garbage collection. It runs like a tank. It will, for better…

Can you describe for me how the tooling, framework(s), and libraries are so advanced and excellent? How easy is it to train a programmer to use PHP in a way that results in fairly secure, reliable, bug-free code? (Note my use of the word "fairly", knowing that there's no such thing as perfect security, reliability, or freedom from bugs.) I do know that, for instance, TDD is possible with PHP. In my experience and obs…

PHP is about 1/3rd of my day job. Java 1/3rd, and support languages for ops (mainly Python and shell scripting) 1/3rd. Find myself commenting a lot on PHP threads in the last few days...

In my earlier days I did quite a bit of developer tutoring, and I have trained developers in PHP codebases on quite a few occasions, so I can speak to the training aspect first hand. I actually find PHP is fine to train developers in - certainly to produce simple code that is reasonably bug free, if not particularly high performance. The 'everyday' use of the language is usually quite straightforward - most projects don't deal with concurrency primitives, long running code, or low level interop. Scoping is quite straightforward. The only real gotchas are type coersion (use === for primitives or write comparator functions) and superglobals (use a library).

To be honest, JavaScript causes just as much confusion in my experience with scoping. Heck, a scarily high number of developers I know would struggle to implement a bug-free equals() method in Java.

As for tooling - here are some examples of good tooling in PHP:

- Dependency management - Composer and it's centralised library, Packagist (npm/rubygems/maven analogue)

- TDD and testing: - PHPUnit (ubiquitous, fairly well featured - built in fakes, code coverage) - Behat (BDD-style testing a la Cucumber) - Codeception (DSL-based) - All three tools have decent integrations with IDEs, can be run easily through Composer's CLI, can be combined with stuff like Grunt/gulp easily for file watchers. - I haven't needed the really esoteric features in my Ruby projects so I'm probably not the best to judge, but I can't say that I find PHP testing tools all that lacking compared to rspec, cucumber etc. I don't feel like you need complex tools for good testing... - Frameworks such as Laravel provide bootstrapping on top of e.g. PHPUnit that provide integration test componentry

- PHPDoc - ubiquitous, well documented, well supported by IDEs, linters, docgens

- PhpStorm (on par with the best IDEs out there), Zend Studio (very good IDE in its own right, eclipse-based), and Eclipse PDT are definitely servicable IDEs with good integration, good code inspections, good support for refactoring (especially now with PHP7 and it's further push into gradual typing).

- PDO - something most other languages have to be fair, but a language-supported SQL database engine abstraction layer is a must for working with SQL databases these days

- Gearman for task queues

Libraries and frameworks available in PHP are much the same as other languages in my experience, when it comes to stuff for the web. Not really much point going through them, suffice to say that there are some poor choices (Wordpress), and some good choices (Flysystem).

Re: Taking PHP Seriously

#654

Post by vancouverwill »

continuational wrote: post #507
increment_i wrote: post #336

Earlier quoted context omitted.

It would be an outlier company indeed who held an 'all hands on deck' meeting and said, "We're succeeding in spite of PHP everyone!" Only engineers care about programming languages. Seriously. That's it. No one else cares about them. I work in a large public university alongside a revolving door of student interns who are always 19. In 10+ years of work, I've still yet to meet the person who talked about their favour…

Only farmers care about tractors. That's not a reason to use horses instead.

exactly.

Re: Taking PHP Seriously

#655

Post by vancouverwill »

dyjakan wrote: post #408
chiefalchemist wrote: post #256

Earlier quoted context omitted.

Luck. Timing. Culture. Team. Etc. All have a greater impact than language. Anyone who says otherwise doesn't understand history.

Culture is correlated with technology, i.e. certain technologies appeal to certain kinds of people. You can go to any Ruby meetup and you will see it's different than PHP meetup which both are quite different from Functional Programming meetups. Thus I would say that it's not about the technology but about people whom you attract (i.e. culture). I skip luck & timing, these are mostly random and one has very little po…

you could definitely argue that a company using PHP nowadays would find it harder to find good engineers because the best ones who care about quality, performance etc don't want to work on a PHP app

Re: Taking PHP Seriously

#656

Post by weberc2 »

codedokode wrote: post #574
weberc2 wrote: post #552

Earlier quoted context omitted.

Programming 101: scope your objects appropriately. If you have an object whose state is bound to the scope of the request handler, initialize it in that context ("don't use global vars" is just a special case of this rule). In other words, everything initialized outside your request handler's scope should have its state reused across requests. The PHP community never entirely learned this, so you guys are building wo…

I do not see how scopes are related to a problem of memory leak. Let's say you have a Django middleware that is initialized outside the scope of a request. Let's say you decided to add some stats counter in that middleware and wrote a code like this: def __call__(self, request): client_ip = request.META['REMOTE_ADDR'] self.last_visitors.append(client_ip) ... This code follows your scoping rules but still leaks memory…

You're conflating application state with request state. Updating application state based on a request is a perfectly reasonable thing to do, but it necessarily invites the possibility of a memory (or database, file, etc) leak. Either PHP can't update application state at all or it can and necessarily suffers from the same potential to leak memory (I suspect the latter, since an application without side-effects would be worthless).

Re: Taking PHP Seriously

#657

Post by sqeaky »

novaleaf wrote: post #477
yxhuvud wrote: post #392

Earlier quoted context omitted.

Managers caring about technical debt? You must live in a parallel universe. They may care about maintenance costs, but that is not really the same thing.

the end result of technical debt ==> maintenance costs makes it same enough.

This is entirely true, but I have never worked with someone beyond the leader of my immediate who though the same. Most managers don't care what cruft is in there when it ships.

Re: Taking PHP Seriously

#658

Post by throwaway729 »

badminton1 wrote: post #326
throwaway729 wrote: post #155

Earlier quoted context omitted.

> Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY. Yes, I agree with you, and I work at places where the label "engineer" reflects this sort of individual responsibility... BUT: > because you know it is wrong and not in the best interest of your employer Look, the way you even phrased that statement is exactly the problem. A US software engineer's primary legal duty is to his employe…

Do your job in the interest of your employer, to the best of your ability, without ripping off your customer. That's the meaning of professionalism. That's the meaning of living in a society. If you need to say no, then do it. Your job is not to say yes to everything. What if everyone ripped off everyone all the time? It would be a world of shit. Ripping off the customer is not in the best interest of the employer, a…

Your responses seem to boil down to "but I believe everyone has a moral responsibility to act like an engineer."

When is perfectly fine, and I agree with you. As I've said multiple times.

But realize that, in the US, programmers have no such legal obligation. They also have no formally codified and enforced professional ethical obligation.

Any such obligation is purely within the realm of personal ethics. Particularly obligations to the customer which go beyond or contradict with obligations to management (the latter are at least captured in the form of a contract).

So your moral stance, while admirable, isn't representative of actual enforced social norms among programmers.

Re: Taking PHP Seriously

#659

Post by vancouverwill »

tigershark wrote: post #585
ransom1538 wrote: post #496

Earlier quoted context omitted.

Performance? You need to update your act. PHP7 is 3x faster than python and now faster than Java 8 . The only people that can call php slow are masochistic c++ web hacks. https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...

I don't care about performance. Unless we are speaking about orders of magnitude and my use case has an absolute need for performance. If I only cared about performance I would write everything in assembly optimised for every specific architecture. But strangely I'm much, much, much more productive writing in c#, Java, groovy, f#, ruby and whatever language is appropriate for what I need to do at a certain time. For…

Performance is directly related to profit on consumer apps. See http://glinden.blogspot.co.uk/2006/11/marissa-mayer-at-web-2...

plus like you say PHP might be faster to get started with but becomes much slower on larger projects due to inconsistent error handling and language design.

Re: Taking PHP Seriously

#660

Post by vancouverwill »

oblio wrote: post #506
collyw wrote: post #391

Earlier quoted context omitted.

Decent developers don't want to work on shit code bases all day long. The application will suffer in the long run.

This looks like a lie. For the right amount of money, people will work for long periods of time on crap code bases.

Not sure about that. Most companies biggest problem is finding talent employees and most experienced engineers will not want to work on a Php codebase especially one full of technical debt due to the variety of other options in languages which compile and miss out on a huge percentage of php problems before you even run basic tests.
Post reply on HN