Earlier quoted context omitted.
This. Developer happiness matters.
Not nearly so much as customer happiness does.
Decent developers don't want to work on shit code bases all day long. The application will suffer in the long run.
Taking PHP Seriously
391–400 of 673 posts
Re: Taking PHP Seriously
#392Earlier 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…
But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.
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.
Re: Taking PHP Seriously
#393Earlier quoted context omitted.
> "reasoning about" (boy do I hate that phrase...) A bit tangential, but I find myself disliking it too, for no good reason that I can think of. Perhaps it's something of a crutch in that it's really "I like it more, but 'reason' sounds better" ? Not sure that's quite it, either, as in the above case with a "new everything per request", it's certainly true that it's easier to think about what's happening.
I like the old hacker term for "reasoning about". Grok. It's much easier to grok a program when everything just runs from top to bottom and doesn't jump to a different third party library every 3 lines or have 15 layers of indirection and frameworks.
"grok" implies a deep understanding, much more so than "reason about".
Re: Taking PHP Seriously
#394I 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 can sign below your post as experience of PHP developer who "fights" each day with bad code written by PHP devs. There are a lot of frameworks like Laravel, Symfony or Zend which introduces a lot of conventions (folder structure, naming, PSR autoloading built-in functions, resources) but it is so often skipped to "get shit done". I would complain on many aspects of daily PHP-development like not using tools like th…
To be fair, as a Python dev, I have inherited some real crap in Python as well. Though recently I had to import some data from a PHP website we have - boy that was another level of crapness (though the main problem was the database design, or lack of it).
Re: Taking PHP Seriously
#395Earlier quoted context omitted.
> It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent? It is also internally inconsistent in so many ways. Half the array functions take arrays as the first arg, the other half the last. explode and implode have different argument order requirements (one is strict, the other works either way). Functions have a grab-bag of errors from returning null to false to 0 to str…
C++ is a C-like language but C++ muddies up the difference between some operators due to operator overloading. This is an inconsistency. Do you support that? No one will ever be able to convince me that " >" make sense to be read and write.
That's not the same thing and you know it. C++ didn't just randomly change the associativity of one of the operators. PHP screwed up ternery in a way that makes zero sense (ie, it's wrong in 99.99999% of use cases). It still catches me (and my colleagues) off guard even though we have years of collective PHP experience.
Re: Taking PHP Seriously
#396Earlier quoted context omitted.
I know you're making a parody, but I think I agree with your parody. I mean, essentially all you're saying is "startup success is largely uncorrelated with the programming language used to implement those startups' products". That seems like not at all an unreasonable position. (It's not, by the way, equivalent to the statement "choice of language doesn't matter".)
Luck. Timing. Culture. Team. Etc. All have a greater impact than language. Anyone who says otherwise doesn't understand history.
This needs to be said more.
Re: Taking PHP Seriously
#397Wordpress succeeded because they were using PHP, because during the 2000's it was very easy to find a cheap shared hosting solution in PHP+MySQL. There was no cheap way to host Rails applications.
And their target was people who would install Wordpress themselves on a cheap shared host.
Facebook and Wikipedia probably used PHP because many developers knew it, and the reason was... That there was many cheap shared hosting solution for their pet projects.
Not only this is no longer true (it's just as easy and cheap to host Rails, Java, Scala, or anything with cloud hosting), but the availability of cheap shared hosting is not relevant for most problems.
tl;dr:
* Wordpress couldn't have succeeded without PHP, because of a context that is no longer true today * Facebook succeeded despite using PHP, because they had the manpower to fork the language and write their own VM
Re: Taking PHP Seriously
#398Earlier quoted context omitted.
What does PHP offer, now, that a static site generator doesn't? I'm going to guess Wordpress, WYSIWYG editor, simple uploads. But if that's not it, I'm genuinely curious.
Dynamic content.
Underrated comment.
To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.
Re: Taking PHP Seriously
#399Write an API for my client app which returns user's data as JSON (or render HTML page for profile); You: { mysql_connect("host", "pass"); mysql_select_db("users"); $uid = $_GET[ "uid" ]; $res = mysql_query( "select * from users where uid = $uid" ); $ar = mysql_fetch_assoc( $res ); echo "name: " . $ar["name"] . ","; echo "location: " . $ar["location"]; ?> } Just call it http://domain.com/api.php?uid=USER_ID ( Yeah I k…
Not sure if intentional or not, but your code has an SQL injection vulnerability.
Re: Taking PHP Seriously
#400Earlier quoted context omitted.
Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system. There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.
I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class. And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fie…
> In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module.
You should try "use strict" sometime. If you write sloppy JS, you'll find out in no time.
Javascript will still have most of its warts, mind you. But some of the most obvious errors should at least be catchable.