8 ms·

A possible future for PHP

91 points by unhammer 12y ago

devicenull 12y ago
> Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper API that can be used to filter all incoming data. So, reinvent magic quotes? > kill save_mode, open_basedir and other acient concepts safe mode is already gone (removed in 5.4)
- trebor 12y ago
  I disagree with his opinion on open_basedir. When configured correctly your application never experiences a problem, and can only write to paths it is directly allowed to. This prevents a security breach from accessing the system's configuration files. Disable it when you're building a system-level configuration package, but use it for all consumer-grade web applications.
- chriswarbo 12y ago
  Nothing wrong with _GET and _POST. The problem is that their elements have type "string" instead of "unsafe_string", so PHP allows them to be used as/with regular "safe" strings. Edit: Except of course that they're mutable, which is stupid. In an ideal world they wouldn't be global either; they'd only be available at the top level, and passed into the application's initialising function/object, but that's low on the priority list.
  - yuliyp 12y ago
    what is an unsafe_string? Did you mean "non-literal string" instead?
    - chriswarbo 12y ago
      > what is an unsafe_string? A type I just made up. > Did you mean "non-literal string" instead? No. Differentiating between literal/non-literal strings would destroy our ability to abstract and perform equational reasoning (although that's already pretty limited in PHP). If I want to write: echo "Hello " . $_GET['name']; I should be prevented. However, I should be allowed to do: echo "Hello " . htmlspecialchars($_GET['name']); This is easy to do: - Make the contents of $_GET['name'] have a type that doesn't work for string operators/functions like "." or "echo". - Make the escaping functions like "htmlspecialchars" only accept "unsafe_string" arguments and produce "string" return values. This forces unsafe values to be escaped, and prevents safe values from being double-escaped. - If you like, go further with an "sql_snippet" type, a "html_snippet" type, etc. and specialise the escaping functions. However, most of those values should really be more structured (eg. HTML should be a DOM, SQL should be an AST, etc.) since performing general string operations like concatenation on these values doesn't really make sense. If we used your literal/non-literal distinction, we'd need our escaping functions to turn non-literal strings into literal strings; which doesn't make sense.
    - cygx 12y ago
      See http://en.wikipedia.org/wiki/Taint_checking http://en.wikipedia.org/wiki/Taint_checking
ownagefool 12y ago
I wonder if people really do use ownCloud on shared hosting, is it just me or does that seem slightly off? For what it's worth, I quite like PHP. Start off with something like Silex, and you have a nice little language. But, as a contractor I have to deal with people who are afraid of package managers or expections on a regular basis and that is far more grating than anything "a fractual of bad design" can throw at the language.
- UnoriginalGuy 12y ago
  > I wonder if people really do use ownCloud on shared hosting, is it just me or does that seem slightly off? Huh? Sharepoint Online (which kind of competes with OwnCloud) is massively popular and is at the heart of Office 365. So, yes, people want that kind of centralised file sharing infrastructure likely for inter-company or inter-group work. A lot of small teams and small companies will just buy a pre-built (often shared) solution (e.g. email, website, collaboration suite, etc). Since they lack the internal expertise to manage their own equipment or to rent a VPN and "do it themselves."
  - ownagefool 12y ago
    Uh, that's not really the type of shared hosting I was talking about, that's Saas. "Shared hosting" is typically referencing you sharing a server with other people and you'd typically have ftp access by default, shell access by request. Typically they don't have a lot of seperation and any user can upload a script that'll become a runaway process or allow remote execution. I'd be suprised if "teams" were doing this, as soon as you start adding in jails, process seperation, etc, you might as well be selling managed VPS and then it's no longer "shared hosting" in the traditional sense.
- jsamuel 12y ago
  > I wonder if people really do use ownCloud on shared hosting DigitalOcean and other VPS providers are popular for hosting ownCloud.
  - justincormack 12y ago
itry 12y ago
Been coding PHP for 14 years. Running several servers with PHP applications. Serving hundreds of thousands of users a month. None of the issues he wants to get "solved" have ever been an issue to me. Taking away _GET, _POST and _SERVER would introduce issues.
- rabino 12y ago
  THIS. Stop trying to fix what's not (completely) broken.
- kalleboo 12y ago
  The only item on his list I absolutely agree with is "Unicode everywhere". I don't understand why you'd want to filter the _GET/etc supervars on input, it's on output you need to filter them, depending on where they're going. The direction I want to see PHP going in is continued improvements in consistency. Stuff like turning all those fatal errors into runtime exceptions. And yes, making all string functions Unicode.
  - pilsetnieks 12y ago
    > why you'd want to filter the _GET/etc supervars on input I get that the solution he proposed is different, and also reasonably sane, but isn't this basically what magic quotes did? Now that that nightmare is finally over, I'm not too keen on reliving it again.
  - nona 12y ago
    "Unicode everywhere" is something I hear often, but don't really agree with, unless you mean "Unicode by default and preferred and easy". The real world still has and probably always will have a lot of text in other encodings - Latin-1, Shift-JIS, heck even things like GSM03.38. I like how Ruby handles it - every string has an encoding attached, and manipulations with non-compatible encodings will complain.
  - jcampbell1 12y ago
    You really don't want string functions to be unicode. Strings in php are actually byte arrays. If you take that away, you will break far more than you fix. You are basically killing the baby, so substr() works a tiny bit better. I don't want to have to flag every string as unicode. It is pointless as they already are all unicode, and it is not that bad to know the very small number times where php's binary functions don't work (e.g. substr, regex in certain cases).
72deluxe 12y ago
Isn't examining _GET, _POST and _SERVER manually a way of filtering incoming data....?
pearjuice 12y ago
Friendly reminder that a PHP thread on HN cannot be had without the following: * complaints about features it has or has not * some snarky comments on the argument orders * a reference to that "a fractal of bad design" article * how language x is better * nothing big has been built in PHP * facebook has been built in PHP * sarcastic and or ironic notes about the above
- lotsofcows 12y ago
  You missed the comparison to "better" languages.
  - lotsofcows 12y ago
    Replying to my own post with an eg: The "several reason for choosing PHP" surely apply to Python even more than they do to PHP?
    - eloisant 12y ago
      I'd say the number one reason a lot of open source projects use PHP (Wordpress, Magento, etc.) is because that's what you can run on dirt-cheap shared hosting. I'm not sure why PHP got in that situation, but I expect that to change with VM and Docker becoming pretty cheap. Now you can have a low-cost hosting of any language.
      - tegansnyder 12y ago
        Have fun running Magento on dirt-cheap shared hosting.
- imanaccount247 12y ago
  It is interesting, because as I read through the thread I see nothing but people justifying their like of/use of PHP despite nobody questioning it to begin with. The number of expert beginners (http://www.daedtech.com/tag/expert-beginner http://www.daedtech.com/tag/expert-beginner) in the PHP community seems very high, and they seem very insecure about their choice.
cdnsteve 12y ago
Consider Hack Lang http://hacklang.org/ http://hacklang.org/. Perhaps it’s PHP’s brightest light. FB has put considerable effort to fork PHP and developer their own language + interpreter for good reason. Change is likely too slow or wouldn’t be made in PHP itself. What your describing directly points to Hack Lang. Even their syntax is: <?hh We should all take a look at Hack Lang (myself included). It could be what PHP 7 will be in a few years but is ready and available to use today. I'm watching this right now as motivation! (OSCON 2014: Include Hack - HHVM - PHP) http://www.youtube.com/watch?v=JrPGa1JDX38 http://www.youtube.com/watch?v=JrPGa1JDX38
- duggan 12y ago
  Agreed, I think HACK and HHVM represent the closest and most likely future for what the author desires. HHVM is really coming along in leaps and bounds - recently with LTS commitments from the development team.
- vderas 12y ago
  I'm not sure if this was added to the article after your reply, but the author mentions Hack specifically, along with some caveats about it's adoption, namely that it is currently unkown how widespread Hack will be and how you're basically at Facebook's mercy in regards to the future of the language. As for adoption, the only stat that I could find was adoption for HHVM[1] (a virtual machine for executing Hack and PHP[2]), but since they list Wikipedia among the HHVM adopters, I'm pretty sure this does not equate to adoption of Hack itself. [1]:https://github.com/facebook/hhvm/wiki/Users https://github.com/facebook/hhvm/wiki/Users [2]:http://hhvm.com/ http://hhvm.com/
krapp 12y ago
PHP already has functions like filter_input_array[0] and array_walk_recursive[1] which get you pretty close to having an external data filtering API already, you just have to take a couple of minutes to glue the pieces together. There's nothing wrong with the arrays themselves, if you treat them the way you would treat untrusted data in any language. [0]http://php.net/manual/en/function.filter-input-array.php http://php.net/manual/en/function.filter-input-array.php [1]http://php.net/manual/en/function.array-walk-recursive.php http://php.net/manual/en/function.array-walk-recursive.php
sauere 12y ago
All the proposed changes will lead to 5 incompatible PHP versions, 20 stupid workaround hacks and it will break PHPs biggest feature: widespread implementation and compability.
prht 12y ago
Writing PHP since 2001. It gets job done & pays bills. No complaints at all. A big thank you to all whoever made it available and improved.
- jmspring 12y ago
  Seems like every couple if months there is a post justifying a future for php.yet,it seems to do just fine. It isn't the sexiest language, but a lot of people are making a decent living working with it.
  - drivingmenuts 12y ago
    The same can be said for Visual Basic and lots of other unsexy languages. Heck, someone out there is still doing COBOL and that's the unsexiest of beasts (that I can think of, ATM). The trick is this: get familiar with a language now and just hang on tooth and nail. Someone, somewhere will still be using that language when you're close to retirement. And you can either charge them a bundle converting off of it, or an even bigger bundle supporting it. And if it's the government, well, as long as you don't get too careless with the yachts, vacation homes and shady neighbors in banana republics, you can probably get away with it until you die. Especially if you own a politician or two.
    - pilsetnieks 12y ago
      There is even some overlap between COBOL programmers and the Github generation: https://github.com/search?utf8=✓&q=language%3Acobol https://github.com/search?utf8=✓&q=language%3Acobol finds 75 repos containing COBOL right now.
  - lukifer 12y ago
    In addition to the oft-cited deployment story, I think another reason for PHP's success is that it's the only major language specifically created as a DSL for rendering web pages. Once you're accustomed to having its baked-in toolset for web-related tasks, having to constantly hunt for the right third-party library in a general-purpose language like Ruby or Python becomes a major drag coefficient, even if those languages are objectively better in all other respects.
aioprisan 12y ago
Some of the largest eCommerce sites are built on PHP (Magento). OO PHP is different than scripted PHP. I can write crappy code in Java as well, but that doesn't make it a bad language.
scrollaway 12y ago
> Static typing. This is totally a question of taste but sometimes I would really love to have a bit more static typing in PHP. Guess what this following code does if you have a file named “1” in your directory This has nothing to do with static typing and everything to do with type insanity (I refuse to call it any other name). Bash and Javascript are also guilty of this BS behaviour. But Python doesn't have static typing, yet it would handle this just fine.
skrebbel 12y ago
> Static typing. This is totally a question of taste but sometimes I would really love to have a bit more static typing in PHP. Guess what this following code does if you have a file named “1” in your directory while ( ($filename = readdir($dh)) == true) $files[] = $filename; Complete nitpick, but you don't even need static typing to fix that bug, just strong typing (like Python has it, for example). If there's one breaking change that I believe a very large portion of the PHP community will appreciate, it is strong typing. In fact, it could easily be made an option, a mode in which == and === are the same and nothing automatically coerces. I bet that in many well-written projects, the amount of changes needed to be able to enable this option is pretty small.
- chriswarbo 12y ago
  Also the fact that he's basically reinventing "scandir" ;)
  - fein 12y ago
    Theres an OOP way to do this now with DirectoryIterator and RecursiveDirectoryIterator. http://php.net/manual/en/class.directoryiterator.php http://php.net/manual/en/class.directoryiterator.php One of the big problems with PHP seems to be the amount of "hidden" features that you don't generally stumble upon unless you dive through the docs, or get the right google search.
    - chriswarbo 12y ago
      > Theres an OOP way to do this now with DirectoryIterator and RecursiveDirectoryIterator. OT: Iterators aren't OO. First of all they don't work with objects/methods: we're forced to write a for/while loop, which is procedural programming. This also prevents abstraction and composition. Functions like "array_map" don't have these problems. Second, they break encapsulation since they not only expose their elements, they also expose their internal mechanisms like "next", "rewind", etc. Again, array_map and friends win here. Third, since they're a massive case of 'sequential coupling' ( http://en.wikipedia.org/wiki/Sequential_coupling http://en.wikipedia.org/wiki/Sequential_coupling ), and since objects are passed by reference, we must ensure that nothing we call in our loop body upsets the ordering (eg. by performing its own loop across the same iterator). This destroys encapsulation and modularity, and makes polymorphism and concurrency dangerous. Just because something uses the "class" keyword doesn't mean it's OO.
opendais 12y ago
> Security. PHP in itself is not insecure and it is obviously possible to write perfectly fine and secure applications with PHP. But PHP decided to implement an quite naive approach about security and doesn´t support the developer too much in writing secure code. Its the same f'n approach every other language took. "Offload it to libraries". > To be fair everybody was naive about web security in the 90s. So there are a not a lot of features available in PHP that actively support you with writing secure code. > Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper API that can be used to filter all incoming data. Actually, they tried to implement the kind of "security features" you suggest and it was a disaster because the compiler isn't aware of the context the programmer is. Things like magic quotes, etc. were tried. All failed because its a bad idea. This suggestion is horribly ignorant and misguided. > Database. PHP support a ton of different database API. Some of them are very old but they are inconsistent to use. Everything should be standardized so that only one OO interface exists. I personally would use PDO as a starting-point here. Give up MYSQL ASYNC? Fuck No. I am not re-writing entire libraries into C to regain access to something I need. There are also differences between Postgres and MySQL implementations, etc. for reasons other than "Oh we felt like it". There needs to be one, consistent driver for each database. PDO isn't the answer. The fundamental issue seems to be the author is ignorant of the fact there are reasons some of this stuff does or doesn't exist. > Remove most of the compile and runtime config options. All PHPNEXT runtime environments should be as similar and stable as possible. Fuck no. That is why Dev & Ops get together and pick "We want combination X to work with, godspeed!". > The database situation is a mess so a lot of people still don´t use prepared statement which leads to possible SQL injection. That is the carpenter failing to use the hammer correctly issue. You can't magically make people do things correctly. > And filtering incoming data for XSS and other problems has to be done relatively manually. There are extensions and libraries available to help with all this problems but they are not part of the language/runtime core or are incomplete. Of course it does. Without knowing the context (say, expecting a date vs. markdown), it would be an awful idea. Security is entirely about the context and expectations. You can't do a one-size-fits-everyone-for-all-uses approach and build into the language. That is insane and doomed to fail. PHP tried it before.
- chriswarbo 12y ago
  tl;dr Stop allowing everything to be concatenated with everything else, and just because PHP tried bad solutions to a problem doesn't mean that problem is unsolvable. > it was a disaster because the compiler isn't aware of the context the programmer is This is completely true, but the underlying cause is that everything is a string. As long as the "solution" is converting strings into strings (eg. magic quotes, escaping, etc.) they're doomed. At a previous job we modified the PHP interpreter to give user input a 'dirty bit'. Dirty bits spread to anything they touched (dirty . clean -> dirty, implode(dirty, [clean]) -> dirty, etc.). Trying to output dirty strings (to stdout, DBs, files, etc.) was a fatal error. Escaping functions unset the dirty bit. Escaping a non-dirty string was a fatal error. This worked quite well. > > introduce a proper API that can be used to filter all incoming data. > Things like magic quotes, etc. were tried. All failed because its a bad idea. Not really. Making everyone access GET/POST vars in the same way is a bad idea. Better to provide getter functions like "get_param_unsafe" and "post_param_unsafe" for this, then provide a bunch of common alternatives which provide escaping like "get_param_html", "post_param_quoted", etc. Even safety-conscious languages like Haskell know that there's no one-size-fits-all approach; but as long as you cover the basics and give scary names to your escape-hatches (eg. "unsafePerformIO", "unsafeCoerce", etc.) then it limits the damage. "unsafe" is basically a big red warning sticker, telling you to pay extra special attention to what's going on. It only ever occur in custom validation/sanitising code, eg. in the definition of "get_param_my_custom_format". If a codebase has "unsafe" all over the place, that's an alarm bell which says the code is dangerous and needs to be refactored to provide and use some safe APIs. > PDO isn't the answer. Meh, library problems. PDO shouldn't be baked into the language, but neither should anything else. > You can't magically make people do things correctly. Yes you can: you can make it impossible/very difficult to do it incorrectly. Again, stop allowing everything to be concatenated with everything else and this issue will be magically resolved. > Without knowing the context (say, expecting a date vs. markdown), it would be an awful idea. If only PHP were capable of providing some kind of "interface", which other code could "implement"...
dbasedow 12y ago
Most of my projects in the last 10 years have been PHP based. I still think it has to change. There are much nicer alternatives (like Python). The reason PHP is still so common is the low learning curve. This also attracts bad programmers who create abominations someone else has to work with. Some changes are more related to the runtime environment, like the whole configuration mess that the article mentions. I also think the PHP community lacks brilliant developers. There are many okay and even good developers. But most PHP applications nowadays look at Java and the abundance of design patterns that often don't make sense in a web environment where application lifetime is usually a few years not decades. Look at Zend Framework. It can do anything. But you need to write so much boilerplate code that all the flexibility a scripting language offers is lost. The PHP community needs to figure out what it wants to be. If I want to use something that is very verbose I will use Java. If I want to move fast I will use Ruby or Python. At the moment PHP seems to be somewhere in between. As long as nothing fundamental changes I will only use PHP when getting paid. For anything I do for fun I will use other languages.
- prht 12y ago
  PHP will get you paid always. It's like "a Lannister always pays his debts"
  - mercurial 12y ago
    You're talking about technical debt, obviously.
- aarondf 12y ago
  > I also think the PHP community lacks brilliant developers. Really? How can you say that with a straight face about a community of that size? I get that maybe you don't think PHP is brilliant, but to say that it lacks brilliant developers seems closed minded and kinda rude.
  - dbasedow 12y ago
    What I mean by brilliant developer is someone who comes up with new paradigm shifting ideas that influence not just PHP development but other languages as well. I have been part of the PHP community for a very long time and I have read a huge amount of books/articles/blogs on PHP development. And I can't recall something that really impressed me.
Mithaldu 12y ago
This blog is an astoundingly beautiful example of why this website is necessary: http://contrastrebellion.com/ http://contrastrebellion.com/
wisienkas 12y ago
How about that we just let php be as it is, it's all good now really, eventually all the "wrongs" there was pointed out, people will get used to and have workarounds in the base of their code instead of having to rewrite their core project of 1M lines of code.
skrebbel 12y ago
I'm generally very impressed by what the PHP core team is doing. The PHP ecosystem is known for its own share of flamewars and its wildly heterogeneous buildup of people (morons, geniuses, accidental programmers and great engineers). All these people want to pull PHP in a different direction. PHP6, with breaking changes, failed, and the core team learned from its failure. Instead, on version 5, the amount of improvements that have been added in the last years is frankly impressive. Supported by similar ecosystem improvements such as Composer (PHP's excellent dependency manager), it makes PHP about as awesome as I can imagine without handing in any backward compatibility. I strongly doubt PHP is going to ever make any breaking changes anymore, short of ones needed to fix Heartbleed-intensity security bugs. The core team has shown how much awesomeness can be reached without making those breaking changes. Some holes will never be plugged, but you can't have it all. It's like Guido van Rossum realizing that nobody wants to migrate to Python 3, and instead making Python 2 awesomer again. It takes courage to do that, and the PHP guys did it.
- joesmo 12y ago
  I couldn't agree more. Most of the features mentioned as possible changes like a constant DB API, removing superglobals, ignoring php.ini configuration, etc. are already possible and available in PHP right now alongside the outdated aforementioned APIs. It's all about how you decide to approach and code an application. For most applications those things are no longer issues and haven't been for many years due to libraries abstracting away and essentially "deprecating" (but without removal) such functionality. This allows old code to stay backward compatible while new code to be incredibly clean. Many of the other changes the author mentions like static typing, new tags made me believe he hasn't really looked into Hack/HHVM except that he mentions it at the end. Still, while I think that is a great product with a lot of potential, the small incompatibilities that still exist and prevent current frameworks and libraries from running on it are the main deterrent to committing and switching to it. Still, as those incompatibilities get fixed, it becomes a more attractive platform. In the rush for "cleaner" code with more "modern" APIs, a lot of programmers miss the much more important issue of backward compatibility and being able to run mature applications. I would much rather have a language and runtime that can run some of the most useful software out there (Wordpress, Drupal, Magento, Wikimedia) that may not have the cleanest looking code out there, than a pretty language that has few useful programs. This has always been PHP's strongpoint and in respect to server apps, nothing else is even in the same ballpark.
EGreg 12y ago
As someone who has been using PHP to develop complex applications for years, I have a different perspective. I realize PHP can be faster than Node in production (thanks to efforts of people at facebook etc). Its stability can be great because every request is naturally isolated. But there are a couple things that make PHP much less than ideal. First of all its latency can be legend-- wait for it-- you'll have to because it doesnt support evented programming - ary. So if you have 100 shards to query, PHP will in fact do all its I/O sequentially while Node and others can send it out in parallel and combine. PHP also can't batch requests together while Node can, so disparate pieces of code hve to know about each other's I/O requests. Caching and Batching are two separate things. Oh yeah, and forget about realtime push, websockets and long lived connections. PHP is good for quick serving of requests. It works on a preforked thread model even if your webserver doesn't. So all these thins necessitate another server to do background processing eg for sending out one-to-many notifications for people affected by an action in a social app. We at Qbix choose Node because being web devs we already have to deal with Javascript. What we mostly use PHP for are two things: 1) Generating webpages dynamically, since we believe that caching dybamic content on many levels is superior to "static sites". 2) Web services where you need to get in and out quickly. For everything else we have a Node server listening to actual HTTP or TCP based requests to Node, which coordinates the session and is protected by a shared secret, as well as communicates via the hostname localhost so an admin is not required to secure that connection via a firewall. PS: As far as security, you mainly just have to make sure to use APIs that do escaping of input for you. It is true that the presence of other APIs presents dangers and you would have to perform static analysis during code commits to make sure no one is using THOSE APIs, but nearly every language has APIs to write to standard output without escaping the html or javascript inside html etc. At the end of the day, the best you can do is static analysis and enforcing conventions.
imakesnowflakes 12y ago
Here is why I think that there is no future for php... http://www.reddit.com/r/technology/comments/2g9pux/if_programming_languages_were_vehicles/ckh70gi http://www.reddit.com/r/technology/comments/2g9pux/if_progra...
- ceejayoz 12y ago
  People are still whining about namespaces? Laravel's Translation files are namespaced Illuminate\Translation. The database stuff is Illuminate\Database with some subsections like Illuminate\Database\Query. Hardly complex.
  - krapp 12y ago
    If your namespaces are more than three segments deep then I believe you may be doing it wrong. This is nothing implicit to the way namespaces work in PHP, it's just bad design. Most Composer packages i've seen only go as deep as vendor\package\whatever anyway. That's not difficult.
- ThomPete 12y ago
  Thats an issue for a small percentage of the people who work in PHP.
exstudent 12y ago
My problem with PHP is that it's a signal of developer laziness. There are a lot of very interesting things going on with languages nowadays. If you develop in PHP because "it pays the bills" you ARE NOT the type of developer I ever want to work with. Honestly, I'm starting to see the same thing with Python/Ruby/JS devs. Stick with one language that you're comfortable with and never push yourself. PHP is an order of magnitude worse in that respect than the other scripting languages.
- ceejayoz 12y ago
  You sound like https://twitter.com/hipsterhacker https://twitter.com/hipsterhacker.
  - exstudent 12y ago
    I have been retweeted by it :P I stand by my opinion though despite the (anticipated) downvoting. Programming in PHP is anti-intellectual.
jdonaldson 12y ago
The Haxe language has a php target. Here's an intro (older, but still works): http://old.haxe.org/doc/start/php http://old.haxe.org/doc/start/php Haxe has a lot of the language features mentioned here... static typing, better namespace organization and support, etc. It's also incredibly quick to compile, and you can easily support older php libs through externs. As a side note, there's also a Haxe target for javascript, meaning you can have a super nice modern language workflow for both client and server side on legacy php/javascript infrastructure.
serve_yay 12y ago
I'm kinda sick of people self-consciously talking about how they use PHP even though it's not "hip" or whatever. It's a HUGE language, maybe the hugest, it is everywhere. And those of us who have used it and decided against using it further are not obsessed with "hipness" or anything of the sort. A lot of us think it sucks and it's broken. Feel free to disagree but please don't frame it such that people who don't use what you use are bird-brained and obsessed with being trendy.

91 points by unhammer 12y ago

> Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper API that can be used to filter all incoming data. So, reinvent magic quotes? > kill save_mode, open_basedir and other acient concepts safe mode is already gone (removed in 5.4)

trebor 12y ago
I disagree with his opinion on open_basedir. When configured correctly your application never experiences a problem, and can only write to paths it is directly allowed to. This prevents a security breach from accessing the system's configuration files. Disable it when you're building a system-level configuration package, but use it for all consumer-grade web applications.
chriswarbo 12y ago
Nothing wrong with _GET and _POST. The problem is that their elements have type "string" instead of "unsafe_string", so PHP allows them to be used as/with regular "safe" strings. Edit: Except of course that they're mutable, which is stupid. In an ideal world they wouldn't be global either; they'd only be available at the top level, and passed into the application's initialising function/object, but that's low on the priority list.
- yuliyp 12y ago
  what is an unsafe_string? Did you mean "non-literal string" instead?
  - chriswarbo 12y ago
    > what is an unsafe_string? A type I just made up. > Did you mean "non-literal string" instead? No. Differentiating between literal/non-literal strings would destroy our ability to abstract and perform equational reasoning (although that's already pretty limited in PHP). If I want to write: echo "Hello " . $_GET['name']; I should be prevented. However, I should be allowed to do: echo "Hello " . htmlspecialchars($_GET['name']); This is easy to do: - Make the contents of $_GET['name'] have a type that doesn't work for string operators/functions like "." or "echo". - Make the escaping functions like "htmlspecialchars" only accept "unsafe_string" arguments and produce "string" return values. This forces unsafe values to be escaped, and prevents safe values from being double-escaped. - If you like, go further with an "sql_snippet" type, a "html_snippet" type, etc. and specialise the escaping functions. However, most of those values should really be more structured (eg. HTML should be a DOM, SQL should be an AST, etc.) since performing general string operations like concatenation on these values doesn't really make sense. If we used your literal/non-literal distinction, we'd need our escaping functions to turn non-literal strings into literal strings; which doesn't make sense.
  - cygx 12y ago
    See http://en.wikipedia.org/wiki/Taint_checking http://en.wikipedia.org/wiki/Taint_checking

ownagefool 12y ago

I wonder if people really do use ownCloud on shared hosting, is it just me or does that seem slightly off? For what it's worth, I quite like PHP. Start off with something like Silex, and you have a nice little language. But, as a contractor I have to deal with people who are afraid of package managers or expections on a regular basis and that is far more grating than anything "a fractual of bad design" can throw at the language.

UnoriginalGuy 12y ago
> I wonder if people really do use ownCloud on shared hosting, is it just me or does that seem slightly off? Huh? Sharepoint Online (which kind of competes with OwnCloud) is massively popular and is at the heart of Office 365. So, yes, people want that kind of centralised file sharing infrastructure likely for inter-company or inter-group work. A lot of small teams and small companies will just buy a pre-built (often shared) solution (e.g. email, website, collaboration suite, etc). Since they lack the internal expertise to manage their own equipment or to rent a VPN and "do it themselves."
- ownagefool 12y ago
  Uh, that's not really the type of shared hosting I was talking about, that's Saas. "Shared hosting" is typically referencing you sharing a server with other people and you'd typically have ftp access by default, shell access by request. Typically they don't have a lot of seperation and any user can upload a script that'll become a runaway process or allow remote execution. I'd be suprised if "teams" were doing this, as soon as you start adding in jails, process seperation, etc, you might as well be selling managed VPS and then it's no longer "shared hosting" in the traditional sense.
jsamuel 12y ago
> I wonder if people really do use ownCloud on shared hosting DigitalOcean and other VPS providers are popular for hosting ownCloud.
- justincormack 12y ago

itry 12y ago

Been coding PHP for 14 years. Running several servers with PHP applications. Serving hundreds of thousands of users a month. None of the issues he wants to get "solved" have ever been an issue to me. Taking away _GET, _POST and _SERVER would introduce issues.

rabino 12y ago
THIS. Stop trying to fix what's not (completely) broken.
kalleboo 12y ago
The only item on his list I absolutely agree with is "Unicode everywhere". I don't understand why you'd want to filter the _GET/etc supervars on input, it's on output you need to filter them, depending on where they're going. The direction I want to see PHP going in is continued improvements in consistency. Stuff like turning all those fatal errors into runtime exceptions. And yes, making all string functions Unicode.
- pilsetnieks 12y ago
  > why you'd want to filter the _GET/etc supervars on input I get that the solution he proposed is different, and also reasonably sane, but isn't this basically what magic quotes did? Now that that nightmare is finally over, I'm not too keen on reliving it again.
- nona 12y ago
  "Unicode everywhere" is something I hear often, but don't really agree with, unless you mean "Unicode by default and preferred and easy". The real world still has and probably always will have a lot of text in other encodings - Latin-1, Shift-JIS, heck even things like GSM03.38. I like how Ruby handles it - every string has an encoding attached, and manipulations with non-compatible encodings will complain.
- jcampbell1 12y ago
  You really don't want string functions to be unicode. Strings in php are actually byte arrays. If you take that away, you will break far more than you fix. You are basically killing the baby, so substr() works a tiny bit better. I don't want to have to flag every string as unicode. It is pointless as they already are all unicode, and it is not that bad to know the very small number times where php's binary functions don't work (e.g. substr, regex in certain cases).

72deluxe 12y ago

Isn't examining _GET, _POST and _SERVER manually a way of filtering incoming data....?

pearjuice 12y ago

Friendly reminder that a PHP thread on HN cannot be had without the following: * complaints about features it has or has not * some snarky comments on the argument orders * a reference to that "a fractal of bad design" article * how language x is better * nothing big has been built in PHP * facebook has been built in PHP * sarcastic and or ironic notes about the above

lotsofcows 12y ago
You missed the comparison to "better" languages.
- lotsofcows 12y ago
  Replying to my own post with an eg: The "several reason for choosing PHP" surely apply to Python even more than they do to PHP?
  - eloisant 12y ago
    I'd say the number one reason a lot of open source projects use PHP (Wordpress, Magento, etc.) is because that's what you can run on dirt-cheap shared hosting. I'm not sure why PHP got in that situation, but I expect that to change with VM and Docker becoming pretty cheap. Now you can have a low-cost hosting of any language.
    - tegansnyder 12y ago
      Have fun running Magento on dirt-cheap shared hosting.
imanaccount247 12y ago
It is interesting, because as I read through the thread I see nothing but people justifying their like of/use of PHP despite nobody questioning it to begin with. The number of expert beginners (http://www.daedtech.com/tag/expert-beginner http://www.daedtech.com/tag/expert-beginner) in the PHP community seems very high, and they seem very insecure about their choice.

cdnsteve 12y ago

Consider Hack Lang http://hacklang.org/ http://hacklang.org/. Perhaps it’s PHP’s brightest light. FB has put considerable effort to fork PHP and developer their own language + interpreter for good reason. Change is likely too slow or wouldn’t be made in PHP itself. What your describing directly points to Hack Lang. Even their syntax is: <?hh We should all take a look at Hack Lang (myself included). It could be what PHP 7 will be in a few years but is ready and available to use today. I'm watching this right now as motivation! (OSCON 2014: Include Hack - HHVM - PHP) http://www.youtube.com/watch?v=JrPGa1JDX38 http://www.youtube.com/watch?v=JrPGa1JDX38

duggan 12y ago
Agreed, I think HACK and HHVM represent the closest and most likely future for what the author desires. HHVM is really coming along in leaps and bounds - recently with LTS commitments from the development team.
vderas 12y ago
I'm not sure if this was added to the article after your reply, but the author mentions Hack specifically, along with some caveats about it's adoption, namely that it is currently unkown how widespread Hack will be and how you're basically at Facebook's mercy in regards to the future of the language. As for adoption, the only stat that I could find was adoption for HHVM[1] (a virtual machine for executing Hack and PHP[2]), but since they list Wikipedia among the HHVM adopters, I'm pretty sure this does not equate to adoption of Hack itself. [1]:https://github.com/facebook/hhvm/wiki/Users https://github.com/facebook/hhvm/wiki/Users [2]:http://hhvm.com/ http://hhvm.com/

krapp 12y ago

PHP already has functions like filter_input_array[0] and array_walk_recursive[1] which get you pretty close to having an external data filtering API already, you just have to take a couple of minutes to glue the pieces together. There's nothing wrong with the arrays themselves, if you treat them the way you would treat untrusted data in any language. [0]http://php.net/manual/en/function.filter-input-array.php http://php.net/manual/en/function.filter-input-array.php [1]http://php.net/manual/en/function.array-walk-recursive.php http://php.net/manual/en/function.array-walk-recursive.php

sauere 12y ago

All the proposed changes will lead to 5 incompatible PHP versions, 20 stupid workaround hacks and it will break PHPs biggest feature: widespread implementation and compability.

prht 12y ago

Writing PHP since 2001. It gets job done & pays bills. No complaints at all. A big thank you to all whoever made it available and improved.

jmspring 12y ago
Seems like every couple if months there is a post justifying a future for php.yet,it seems to do just fine. It isn't the sexiest language, but a lot of people are making a decent living working with it.
- drivingmenuts 12y ago
  The same can be said for Visual Basic and lots of other unsexy languages. Heck, someone out there is still doing COBOL and that's the unsexiest of beasts (that I can think of, ATM). The trick is this: get familiar with a language now and just hang on tooth and nail. Someone, somewhere will still be using that language when you're close to retirement. And you can either charge them a bundle converting off of it, or an even bigger bundle supporting it. And if it's the government, well, as long as you don't get too careless with the yachts, vacation homes and shady neighbors in banana republics, you can probably get away with it until you die. Especially if you own a politician or two.
  - pilsetnieks 12y ago
    There is even some overlap between COBOL programmers and the Github generation: https://github.com/search?utf8=✓&q=language%3Acobol https://github.com/search?utf8=✓&q=language%3Acobol finds 75 repos containing COBOL right now.
- lukifer 12y ago
  In addition to the oft-cited deployment story, I think another reason for PHP's success is that it's the only major language specifically created as a DSL for rendering web pages. Once you're accustomed to having its baked-in toolset for web-related tasks, having to constantly hunt for the right third-party library in a general-purpose language like Ruby or Python becomes a major drag coefficient, even if those languages are objectively better in all other respects.

aioprisan 12y ago

Some of the largest eCommerce sites are built on PHP (Magento). OO PHP is different than scripted PHP. I can write crappy code in Java as well, but that doesn't make it a bad language.

scrollaway 12y ago

> Static typing. This is totally a question of taste but sometimes I would really love to have a bit more static typing in PHP. Guess what this following code does if you have a file named “1” in your directory This has nothing to do with static typing and everything to do with type insanity (I refuse to call it any other name). Bash and Javascript are also guilty of this BS behaviour. But Python doesn't have static typing, yet it would handle this just fine.

skrebbel 12y ago

> Static typing. This is totally a question of taste but sometimes I would really love to have a bit more static typing in PHP. Guess what this following code does if you have a file named “1” in your directory while ( ($filename = readdir($dh)) == true) $files[] = $filename; Complete nitpick, but you don't even need static typing to fix that bug, just strong typing (like Python has it, for example). If there's one breaking change that I believe a very large portion of the PHP community will appreciate, it is strong typing. In fact, it could easily be made an option, a mode in which == and === are the same and nothing automatically coerces. I bet that in many well-written projects, the amount of changes needed to be able to enable this option is pretty small.

chriswarbo 12y ago
Also the fact that he's basically reinventing "scandir" ;)
- fein 12y ago
  Theres an OOP way to do this now with DirectoryIterator and RecursiveDirectoryIterator. http://php.net/manual/en/class.directoryiterator.php http://php.net/manual/en/class.directoryiterator.php One of the big problems with PHP seems to be the amount of "hidden" features that you don't generally stumble upon unless you dive through the docs, or get the right google search.
  - chriswarbo 12y ago
    > Theres an OOP way to do this now with DirectoryIterator and RecursiveDirectoryIterator. OT: Iterators aren't OO. First of all they don't work with objects/methods: we're forced to write a for/while loop, which is procedural programming. This also prevents abstraction and composition. Functions like "array_map" don't have these problems. Second, they break encapsulation since they not only expose their elements, they also expose their internal mechanisms like "next", "rewind", etc. Again, array_map and friends win here. Third, since they're a massive case of 'sequential coupling' ( http://en.wikipedia.org/wiki/Sequential_coupling http://en.wikipedia.org/wiki/Sequential_coupling ), and since objects are passed by reference, we must ensure that nothing we call in our loop body upsets the ordering (eg. by performing its own loop across the same iterator). This destroys encapsulation and modularity, and makes polymorphism and concurrency dangerous. Just because something uses the "class" keyword doesn't mean it's OO.

opendais 12y ago

> Security. PHP in itself is not insecure and it is obviously possible to write perfectly fine and secure applications with PHP. But PHP decided to implement an quite naive approach about security and doesn´t support the developer too much in writing secure code. Its the same f'n approach every other language took. "Offload it to libraries". > To be fair everybody was naive about web security in the 90s. So there are a not a lot of features available in PHP that actively support you with writing secure code. > Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper API that can be used to filter all incoming data. Actually, they tried to implement the kind of "security features" you suggest and it was a disaster because the compiler isn't aware of the context the programmer is. Things like magic quotes, etc. were tried. All failed because its a bad idea. This suggestion is horribly ignorant and misguided. > Database. PHP support a ton of different database API. Some of them are very old but they are inconsistent to use. Everything should be standardized so that only one OO interface exists. I personally would use PDO as a starting-point here. Give up MYSQL ASYNC? Fuck No. I am not re-writing entire libraries into C to regain access to something I need. There are also differences between Postgres and MySQL implementations, etc. for reasons other than "Oh we felt like it". There needs to be one, consistent driver for each database. PDO isn't the answer. The fundamental issue seems to be the author is ignorant of the fact there are reasons some of this stuff does or doesn't exist. > Remove most of the compile and runtime config options. All PHPNEXT runtime environments should be as similar and stable as possible. Fuck no. That is why Dev & Ops get together and pick "We want combination X to work with, godspeed!". > The database situation is a mess so a lot of people still don´t use prepared statement which leads to possible SQL injection. That is the carpenter failing to use the hammer correctly issue. You can't magically make people do things correctly. > And filtering incoming data for XSS and other problems has to be done relatively manually. There are extensions and libraries available to help with all this problems but they are not part of the language/runtime core or are incomplete. Of course it does. Without knowing the context (say, expecting a date vs. markdown), it would be an awful idea. Security is entirely about the context and expectations. You can't do a one-size-fits-everyone-for-all-uses approach and build into the language. That is insane and doomed to fail. PHP tried it before.

chriswarbo 12y ago
tl;dr Stop allowing everything to be concatenated with everything else, and just because PHP tried bad solutions to a problem doesn't mean that problem is unsolvable. > it was a disaster because the compiler isn't aware of the context the programmer is This is completely true, but the underlying cause is that everything is a string. As long as the "solution" is converting strings into strings (eg. magic quotes, escaping, etc.) they're doomed. At a previous job we modified the PHP interpreter to give user input a 'dirty bit'. Dirty bits spread to anything they touched (dirty . clean -> dirty, implode(dirty, [clean]) -> dirty, etc.). Trying to output dirty strings (to stdout, DBs, files, etc.) was a fatal error. Escaping functions unset the dirty bit. Escaping a non-dirty string was a fatal error. This worked quite well. > > introduce a proper API that can be used to filter all incoming data. > Things like magic quotes, etc. were tried. All failed because its a bad idea. Not really. Making everyone access GET/POST vars in the same way is a bad idea. Better to provide getter functions like "get_param_unsafe" and "post_param_unsafe" for this, then provide a bunch of common alternatives which provide escaping like "get_param_html", "post_param_quoted", etc. Even safety-conscious languages like Haskell know that there's no one-size-fits-all approach; but as long as you cover the basics and give scary names to your escape-hatches (eg. "unsafePerformIO", "unsafeCoerce", etc.) then it limits the damage. "unsafe" is basically a big red warning sticker, telling you to pay extra special attention to what's going on. It only ever occur in custom validation/sanitising code, eg. in the definition of "get_param_my_custom_format". If a codebase has "unsafe" all over the place, that's an alarm bell which says the code is dangerous and needs to be refactored to provide and use some safe APIs. > PDO isn't the answer. Meh, library problems. PDO shouldn't be baked into the language, but neither should anything else. > You can't magically make people do things correctly. Yes you can: you can make it impossible/very difficult to do it incorrectly. Again, stop allowing everything to be concatenated with everything else and this issue will be magically resolved. > Without knowing the context (say, expecting a date vs. markdown), it would be an awful idea. If only PHP were capable of providing some kind of "interface", which other code could "implement"...

dbasedow 12y ago

Most of my projects in the last 10 years have been PHP based. I still think it has to change. There are much nicer alternatives (like Python). The reason PHP is still so common is the low learning curve. This also attracts bad programmers who create abominations someone else has to work with. Some changes are more related to the runtime environment, like the whole configuration mess that the article mentions. I also think the PHP community lacks brilliant developers. There are many okay and even good developers. But most PHP applications nowadays look at Java and the abundance of design patterns that often don't make sense in a web environment where application lifetime is usually a few years not decades. Look at Zend Framework. It can do anything. But you need to write so much boilerplate code that all the flexibility a scripting language offers is lost. The PHP community needs to figure out what it wants to be. If I want to use something that is very verbose I will use Java. If I want to move fast I will use Ruby or Python. At the moment PHP seems to be somewhere in between. As long as nothing fundamental changes I will only use PHP when getting paid. For anything I do for fun I will use other languages.

prht 12y ago
PHP will get you paid always. It's like "a Lannister always pays his debts"
- mercurial 12y ago
  You're talking about technical debt, obviously.
aarondf 12y ago
> I also think the PHP community lacks brilliant developers. Really? How can you say that with a straight face about a community of that size? I get that maybe you don't think PHP is brilliant, but to say that it lacks brilliant developers seems closed minded and kinda rude.
- dbasedow 12y ago
  What I mean by brilliant developer is someone who comes up with new paradigm shifting ideas that influence not just PHP development but other languages as well. I have been part of the PHP community for a very long time and I have read a huge amount of books/articles/blogs on PHP development. And I can't recall something that really impressed me.

Mithaldu 12y ago

This blog is an astoundingly beautiful example of why this website is necessary: http://contrastrebellion.com/ http://contrastrebellion.com/

wisienkas 12y ago

How about that we just let php be as it is, it's all good now really, eventually all the "wrongs" there was pointed out, people will get used to and have workarounds in the base of their code instead of having to rewrite their core project of 1M lines of code.

skrebbel 12y ago

I'm generally very impressed by what the PHP core team is doing. The PHP ecosystem is known for its own share of flamewars and its wildly heterogeneous buildup of people (morons, geniuses, accidental programmers and great engineers). All these people want to pull PHP in a different direction. PHP6, with breaking changes, failed, and the core team learned from its failure. Instead, on version 5, the amount of improvements that have been added in the last years is frankly impressive. Supported by similar ecosystem improvements such as Composer (PHP's excellent dependency manager), it makes PHP about as awesome as I can imagine without handing in any backward compatibility. I strongly doubt PHP is going to ever make any breaking changes anymore, short of ones needed to fix Heartbleed-intensity security bugs. The core team has shown how much awesomeness can be reached without making those breaking changes. Some holes will never be plugged, but you can't have it all. It's like Guido van Rossum realizing that nobody wants to migrate to Python 3, and instead making Python 2 awesomer again. It takes courage to do that, and the PHP guys did it.

joesmo 12y ago
I couldn't agree more. Most of the features mentioned as possible changes like a constant DB API, removing superglobals, ignoring php.ini configuration, etc. are already possible and available in PHP right now alongside the outdated aforementioned APIs. It's all about how you decide to approach and code an application. For most applications those things are no longer issues and haven't been for many years due to libraries abstracting away and essentially "deprecating" (but without removal) such functionality. This allows old code to stay backward compatible while new code to be incredibly clean. Many of the other changes the author mentions like static typing, new tags made me believe he hasn't really looked into Hack/HHVM except that he mentions it at the end. Still, while I think that is a great product with a lot of potential, the small incompatibilities that still exist and prevent current frameworks and libraries from running on it are the main deterrent to committing and switching to it. Still, as those incompatibilities get fixed, it becomes a more attractive platform. In the rush for "cleaner" code with more "modern" APIs, a lot of programmers miss the much more important issue of backward compatibility and being able to run mature applications. I would much rather have a language and runtime that can run some of the most useful software out there (Wordpress, Drupal, Magento, Wikimedia) that may not have the cleanest looking code out there, than a pretty language that has few useful programs. This has always been PHP's strongpoint and in respect to server apps, nothing else is even in the same ballpark.

EGreg 12y ago

As someone who has been using PHP to develop complex applications for years, I have a different perspective. I realize PHP can be faster than Node in production (thanks to efforts of people at facebook etc). Its stability can be great because every request is naturally isolated. But there are a couple things that make PHP much less than ideal. First of all its latency can be legend-- wait for it-- you'll have to because it doesnt support evented programming - ary. So if you have 100 shards to query, PHP will in fact do all its I/O sequentially while Node and others can send it out in parallel and combine. PHP also can't batch requests together while Node can, so disparate pieces of code hve to know about each other's I/O requests. Caching and Batching are two separate things. Oh yeah, and forget about realtime push, websockets and long lived connections. PHP is good for quick serving of requests. It works on a preforked thread model even if your webserver doesn't. So all these thins necessitate another server to do background processing eg for sending out one-to-many notifications for people affected by an action in a social app. We at Qbix choose Node because being web devs we already have to deal with Javascript. What we mostly use PHP for are two things: 1) Generating webpages dynamically, since we believe that caching dybamic content on many levels is superior to "static sites". 2) Web services where you need to get in and out quickly. For everything else we have a Node server listening to actual HTTP or TCP based requests to Node, which coordinates the session and is protected by a shared secret, as well as communicates via the hostname localhost so an admin is not required to secure that connection via a firewall. PS: As far as security, you mainly just have to make sure to use APIs that do escaping of input for you. It is true that the presence of other APIs presents dangers and you would have to perform static analysis during code commits to make sure no one is using THOSE APIs, but nearly every language has APIs to write to standard output without escaping the html or javascript inside html etc. At the end of the day, the best you can do is static analysis and enforcing conventions.

imakesnowflakes 12y ago

Here is why I think that there is no future for php... http://www.reddit.com/r/technology/comments/2g9pux/if_programming_languages_were_vehicles/ckh70gi http://www.reddit.com/r/technology/comments/2g9pux/if_progra...

ceejayoz 12y ago
People are still whining about namespaces? Laravel's Translation files are namespaced Illuminate\Translation. The database stuff is Illuminate\Database with some subsections like Illuminate\Database\Query. Hardly complex.
- krapp 12y ago
  If your namespaces are more than three segments deep then I believe you may be doing it wrong. This is nothing implicit to the way namespaces work in PHP, it's just bad design. Most Composer packages i've seen only go as deep as vendor\package\whatever anyway. That's not difficult.
ThomPete 12y ago
Thats an issue for a small percentage of the people who work in PHP.

exstudent 12y ago

My problem with PHP is that it's a signal of developer laziness. There are a lot of very interesting things going on with languages nowadays. If you develop in PHP because "it pays the bills" you ARE NOT the type of developer I ever want to work with. Honestly, I'm starting to see the same thing with Python/Ruby/JS devs. Stick with one language that you're comfortable with and never push yourself. PHP is an order of magnitude worse in that respect than the other scripting languages.

ceejayoz 12y ago
You sound like https://twitter.com/hipsterhacker https://twitter.com/hipsterhacker.
- exstudent 12y ago
  I have been retweeted by it :P I stand by my opinion though despite the (anticipated) downvoting. Programming in PHP is anti-intellectual.

jdonaldson 12y ago

The Haxe language has a php target. Here's an intro (older, but still works): http://old.haxe.org/doc/start/php http://old.haxe.org/doc/start/php Haxe has a lot of the language features mentioned here... static typing, better namespace organization and support, etc. It's also incredibly quick to compile, and you can easily support older php libs through externs. As a side note, there's also a Haxe target for javascript, meaning you can have a super nice modern language workflow for both client and server side on legacy php/javascript infrastructure.

serve_yay 12y ago

I'm kinda sick of people self-consciously talking about how they use PHP even though it's not "hip" or whatever. It's a HUGE language, maybe the hugest, it is everywhere. And those of us who have used it and decided against using it further are not obsessed with "hipness" or anything of the sort. A lot of us think it sucks and it's broken. Feel free to disagree but please don't frame it such that people who don't use what you use are bird-brained and obsessed with being trendy.