Hacker Newsnew | comments | show | ask | jobs | submit | overshard's comments login

Most of my hate is not directed at PHP but rather the code of the projects I run across written in PHP. It's not uncommon for there to be random whitespace and code thrown everywhere with no heed to a sensible MVC or other software architectural pattern.

I do occasionally run into well written and maintained software written in PHP and, while it's not my prefered language, it's quite readable and I can work with it.

PHP does have it's issues but they are exacerbated by the general community that uses it.

-----


> Most of my hate is not directed at PHP but rather the code of the projects I run across written in PHP.

This is pure selection bias. There's great PHP code and there's horrible $YOUR_FAVOURITE_LANGUAGE code.

If you hate PHP because of this, you must also hate Java (since Android, at least, which at least halved the average competency of the community) Ruby (since Rails became too popular), JavaScript (see the jquery thread on the HN front page right now), Haskell (big ball of 2000 unorganized functions with two-letter argument names, anyone?), C# (This Is How Microsoft Does It So We Must Too) and Python (at least since Codecademy/Treehouse started unloading thousands of well-meaning but inexperienced Python programmers on the world). Don't even get me started about Perl and C++.

I'm not sure what's left. Clojure, Elixir, Turbo Pascal?

-----


I said that there is great PHP code, I've run into many projects in PHP that are extremely well written. However, I run into more PHP projects that are not.

PHP is fantastically easy to get started using, it's probably the simplest way to start doing website development, and Wordpress runs many of the small websites we see today. I recommend it to anyone getting started in web development. But what this leads to in website development is me running into more code in PHP that is bad than good.

You are correct in saying that there's horrible $YOUR_FAVORITE_LANGUAGE code, I do run into it all the time, but I just tend to run into this problem more with PHP due to how amazingly low the barrier to entry is.

Since you brought up my favorite language, Python, I will go to say that at least Python forces people who write it to use sensible whitespace more or less. I can read most Python projects, even if they are really bad. In PHP I've seen whitespace and lines that stretch over 500 characters and combinations of tabs and spaces that make my brain hurt. This goes for any language that doesn't have strict whitespace rules but specifically PHP and even JavaScript, with their ability to inline code in HTML, have lead to some nightmare codebases that I've had to work on. That is not to say that Python doesn't have some silly long lines with people who try to get too creative with lambda functions but that's a rare occurrence. Also the fact that you cannot inline Python (without some silly libraries that do exist) you do get at least some separation of templates and model/views. This goes for Java and C# and whatever other web dev language you want to put in. PHP's ability to inline code is both incredible for new coders and a nightmare for readability if not done properly.

-----


I think it's a bit silly that less-than-four-letter arguments/values/objects/functions are allowed in modern languages. I mean, what are the odds that the programmer is not writing horrible code in that scenario?

-----


Some trivial counterexamples (in ES6 for convenience):

    someArray.sort((a, b) => a - b);

    var odd = (x) => x % 2 == 0;
    highlightRows = rows.filter(odd);

    function isLegalAdult(age, locality){
       ...
    }

-----


That's very subjective. Yes, one-letter variable names are usually a pain, but throwaway loop increments can be an exception. Three letter variable names are often perfectly acceptable, and optimal - what would you suggest I use instead of age, day, or max? Long variable names are often a massive pain, particularly those with multiple words separated by differing case or non-alpha characters.

-----


I'd agree with this, but from an unusual perspective - I write some really, really bad PHP. So I thought I'd offer some perspective on where this actually comes from (from a sample set of 1).

PHP's documentation is almost too good. It's fantastic. My primary frustration dabbling with other languages is that no-one else has not only the language itself, but a huge subset of the core library documented to the standard that I've come to rely on from PHP.

But here also lays a huge problem. I'm not a programmer. I have next to no idea what MVC is, let alone what would qualify it as sensible. When it comes to architecture, I could give you a much more convincing description of flying buttresses than anything you'd hope to find in a codebase.

But what I can do, is break what I want to do down into small enough component tasks that I can find very workable examples within the PHP documentation, and then duct-tape these all together until I've accomplished my goal.

Now, the good news is that I know this is a terrible approach with terrible results, so I wouldn't dream of inflicting my results upon anyone else. But I thought I could offer a little insight onto how PHP enables such atrocities.

It's similar to the popular backlash against Bootstrap. Where Bootstrap enables me to kludge together a frontend with near no idea what I'm doing, PHP's documentation does the same for the backend. But I still find it difficult to blame the products themselves - I'm more than aware that this is my failing.

-----


Is it really that much better? I've found e.g. the Python documentation for the core library is very good. It seems to me that it should be possible to slap together some Django approximately as easily as PHP, and you'd end up with something a little bit better.

Is it just that something like Django requires a bit of up-front install, whereas PHP you can write <?php in a file on your shared webhost and be rolling? Am I wrong about the documentation being up to the same standards? Or is there something else going on?

-----


I think PHP has some of the best documentation I've ever come across. Particularly the comments section for every single command is incredibly helpful. I've learned tons and tons just from the comments. I think any programming language would be much improved if they copy PHP's documentation model.

(This is coming from a guy that does understand PHP very well, also MVC, objects, "patterns" even though I personally think that word is absurd :P)

-----


I guess this part is pretty subjective, but I do find PHP's docs more readable.

Here's an example I ran into recently, taking my first babysteps into Python: https://docs.python.org/2/library/json.html vs http://php.net/manual/en/function.json-encode.php

As far as I can tell, these should be functionally similar, at least for my goal of returning an array as json.

The first thing to compare is the very first line - where the php docs tell me quite clearly what this function does. Compare to what I can only call waffle on the Python docs.

The php docs go on to tell me: what the arguments are, what types they are, and what options are acceptable. Followed by examples that start with the very basic, and go on to cover some more involved scenarios - but are all self-documenting and standalone.

The Python docs start off with some examples that frankly, aren't self-documenting. I'm still not sure what type is being passed, or returned, in the first example. The following examples appear to be trying to cover some edge cases, but don't say what, or why. This for me is the huge difference - the documentation is the last place I expect to be trying to guess what they mean.

We them get into the "basic usage" section where my eyes frankly glaze over.

It seems the Python docs to go into a lot more depth, so could be called better-documented from that point of view. But my original argument was that the PHP docs are incredibly accessible, and I stand by that.

-----


I always found Python docs very readable. Did you try the tutorial? Oh, and do yourself a favour and start with Python3.

-----


Laravel (or any other PHP framework) also requires an "up-front install", but you don't need a framework like Django to "slap" together a Python program for web purposes either. What you need is an understanding of what a CGI application does and how to deploy one with your favorite web server. Deploying a Python application with Apache/mod_wsgi (or nginx/uwsgi) is really no more difficult than deploying a PHP application with Apache/PHP-FPM or FastCGI.

-----


I don't think you can apt-get install python and expect to be running a webserver. But I think we can all agree that running a python web app (properly) is 10 times easier than ruby.

-----


True, but by doing apt-get install php you won't be up and running either. My point was really to clarify that you don't need a full blown framework to run basic Python scripts for web programming purposes and also to state that the barrier to entry for Python isn't really that much higher than PHP.

-----


With PHP you don't need any of that. All you need is to rename your index.html to index.php and re-upload. The learning curve is incredibly shallow.

-----


I don't wish to degrade any new start-up, it's hard to make it out there but this one wasn't thought out or researched. People hate pop-ups. Really really hate pop-ups. Making an entire service based on the principle of serving pop-ups, for lack of a better word in my vocabulary, is idiotic. If you go around any given room and ask people, "When you are browsing a website do you like getting pop-ups? Say it's for a special offer for a whole 10% off! How about then?" I'm pretty sure the answer is going to be no and no.

Just for me personally if I get a pop-up on a website I'm more likely to go somewhere else, like to Amazon, where they don't give me pop-ups and already have my account information.

-----


If you're not using HTTPS it is trivial for anyone in the middle of the "client to server and back" connection to change any of the content.

If you use HTTPS you prevent alterations to that traffic and people receive exactly what you expect they should receive.

Examples of recent ISP misbehaving on non-https websites just 25 days ago on HN: https://news.ycombinator.com/item?id=8500131

Note that the Verizon issue isn't anything entirely content altering but someone who lives in a country with strict monitoring of traffic could easily change the wording of your website to match their propaganda if you aren't using HTTPS.

So yes, your content is publicly available free stuff and no one is probably sending you user login credentials or credit cards but it still matters.

-----


The "How It Works" page, https://letsencrypt.org/howitworks/, has me a bit worried. Anytime I see a __magic__ solution that has you running a single command to solve all your problems I immediately become suspicious at how much thought went into the actual issue.

If I'm running a single web app on a single Ubuntu server using Apache then I'm set! If I'm running multiple web apps across multiple servers using a load balancer, nginx on FreeBSD then...

All the same I'm really looking forward to this coming out, it can be nothing but good that all of these companies are backing this new solution and I'm sure it'll expand and handle these issues as long as a good team is behind it.

-----


What you're seeing today is demos, not the software in its final form. You're also seeing it demo'd with a focus on the most simple usage. There are, and will be, advanced options.

We'll be doing quite a bit of work based on user feedback between now and when we go live. We're well aware that we need to cater to a variety of types of users.

-----


I run Apache httpd, and there's no way I'd let a wizard anywhere near my configuration files or private keys, much less run it on a production server.

I think it's about time for a free CA that is recognized by all clients, but you still need to establish a trust chain to exchange a CSR for a signed certificate. This service needs to be server agnostic. The barrier to adoption isn't configuration, and HTTPS isn't the only thing that uses certificates.

-----


There are lots of different barriers to adoption. With this project we are attacking several of them at the outset, including the cost of obtaining a certificate, and the inconvenience or difficulty of obtaining and installing it for users who don't do that every day.

Because of the open protocol we also aspire to support users with more complex configurations and requirements, who are absolutely welcome and encouraged to write their own implementations of the protocol and integrate with their own existing certificate management and configuration methods. If you think of other barriers to adoption that we can help with, please let us know and we'll try to address them; if you just want our certs for free, please get them and enjoy!

-----


My concern is that your reach is too far. Asking domain administrators to trust your software to manipulate private keys (and server configurations) is as troubling as asking end users to click past security warnings. The whole purpose of the CSR is to obtain the signed certificate without putting the private key at risk. This decoupling isolates the challenge of identity verification in a reasonable place (nobody is saying it's easy). With your client, you're essentially telling people you accept checks or credit cards, but only if they show you their gold. It sets a bad precedent.

I do want your certs for free! But I also want/need to trust you and know that you're following best practices, not just with me but with everyone.

-----


Oh, our software does NOT send the private key to the CA. Never never never never. The point of having it manage the keys is not to give us access to them, it's to be convenient for the end-user, on the end-user's own system, under the end-user's control.

You can tell because our software is open source, written in Python.

https://github.com/letsencrypt/lets-encrypt-preview

We expect the users to get this software from their operating system repos, like from the Debian package repository -- the very same place they get their Apache or Nginx packages. We are not asking people to get the software directly from us, or to use it without being able to read it and check that it's safe and does what they want.

Edit: And if you want to implement your own client, we encourage you to do that -- the more clients the merrier!

-----


I'd still be more comfortable if the process never went anywhere near the private key (and I'm concerned that a proprietary competitor or look-alike would prey on naive users by leveraging your example). But I also applaud your effort and transparency. I admit I trust openssl to manage my own keys and certificates, and there is definitely room in this space for improvement and alternative approaches. But it does sadden me that we risk making administrators as trusting and ignorant of the underlying principles as end users already are today.

-----


Yes, this will only hit the common small-site case. Hopefully if you're running "multiple web apps across multiple servers using a load balancer" you will have the skill to configure HTTPS properly for that situation, which will probably involve custom configuration on the load balancer. It's not a criticism of something trying to solve the common case, where the common solution up until today is pretty much "just forget about it", that it doesn't work at "cloud scale".

-----


It doesn't seem as magical when you drill down. And if you roll your own nginx or whatever, it'll be less transparent still. But yeah, someone like Ubuntu or Red Hat could enable this on their product that simply.

Domain validation is done through a challenge (issued by a CA) to sign arbitrary data and put on a URL (covered by the domain) the CA can then query. This seems pretty solid. Better then email.

-----


I don't get why they are releasing a command line, instead of just giving us a cert that we can install by ourselves.

-----


Here's the current process:

Generate key, Generate CSR, Send CSR, Receive Certs from CA, Verify ownership, Install certs

Presumably their command line client creates the key, the CSR, sends the CSR, then gets back the certs (at least I'd hope so). I'd be happy to use a vetted command line utility which did that, or even just parts of that process, if I were sure the private key were not transmitted. It's just automating stuff which with current CAs needs to be done manually.

-----


The tool will gather the domains, use the CA API to validate ownership, obtain the certs (which cannot be unilaterally created since they are based on a public/private key pair) and manage their expiry.

That's a bit more then "giving us a cert"

-----


That wouldn't be safe, because then they would have access to your private key and impersonate you. Having you (indirectly via their script) generate the key and submit the public key for signing means your private key never leaves the premises.

-----


There is no reason for the CA to ever see the private key. All they need is a CSR. This approach is fundamentally broken.

-----


It's primarily because of the interactive challenge to prove that you control the domains you're requesting the cert for.

If you want, the client can just give you the cert at the end instead of installing it. In the common case for a user who's not currently comfortable with the process, the client is automating several things -- generating a private key and CSR, proving control of the domain, and installing the key and cert in the server.

-----


It would be really helpful if your how it works page explained in detail how it works, in particular that all browsers are covered, that a key and csr are generated, the certs recd, and that the private key never leaves the server (I'm assuming that at present).

My dream cli tool would just generate key, get certs, and dump them in the dir of my choice. The server config is nice to have but not really essential or the hard part.

Really looking forward to seeing this happen, is there any beta program at present?

-----


Developers who do stuff like this generally do it for themselves and people who are very similar to themselves. I've released quite a few products in a similar fashion requiring people to host and install it themselves and someone always makes this comment. I don't build software like this for other people, I build it for myself, I share it with everyone because someone else might want to build on top of it or use it, I don't really care if it "takes off" because it solves a personal problem in my own life.

-----


I have given up trying to unsub from many places, sometimes unsubing doesn't do anything, I generally just mark it as spam now days.

-----


Then you're punishing the good guys.

-----


The good guys don't send me mail I didn't ask for.

-----


Yes, login-to-unsubscribe would be much more palatable if it were for things I actually opted in to. If I did not subscribe, then it should be easy to unsubscribe.

I'm looking at you, LinkedIn and Twitter. I've unsubscribed from about three or four waves of your bullshit. No, I don't care about what I might have "missed on Twitter". I didn't subscribe to this, you spamming fucks.

-----


No, but they send you mail that you inadvertently asked for, and mail that you initially asked for but have since decided that you no longer want.

-----


"mail that you inadvertently asked for" IS spam.

Personally I give them the benefit of the doubt and try to unsubscribe with ONE click.

There is no good reason to make people click more than once.

-----


Seems back up now, maybe they were just switching to CloudFlare? I didn't think HN was on CloudFlare before.

-----


It wasn't. Somebody's mad at HN I guess.

-----


Who isn't? This bloody site costs at least an hour per day!

;-)

-----


I'd love to use this service but as a freelancer who would get much more than 300 feedbacks a month the pricing schema seems completely off point and makes it impossible for me to use.

I really hate companies that have tiered pricing, it's unfair to those who don't use all of their allocated tier and unfair to those who need much more and are fine with paying if I don't need to contact them, just implement a way for me to pay-per-feedback or something.

-----


As someone trying to solve the problem of Word to CMS copy/pasting, this is sadly what the majority of people do. As someone trying build build responsive websites I see people adding a bunch of spaces to center align instead of using the "center align" functionality this kills me.

I don't know the right solution, I've tried just about every editor and nothing seems to stop the Word to CMS copy/paste issue. Maybe the solution is to build a Word plugin to publish to CMS that cleans up the content as it publishes?

-----


That's actually not a bad idea at all. Word Plugin API, I assume (I don't even use Word, let alone making plugins for it), may give you the structure with the content and all you have to do would be just splitting that information to put into the right fields.

I'm actually thinking about giving this a go (I guess I need to purchase a Word license at first).

-----


The point is that people have a hard enough time using the existing features in Word and other WYSIWYG editors which allow for structured documents. Once an enterprising individual decides to depart from your template using tabs and spaces you will be helpless again.

-----


Looks like a great editor that is simple enough for your average user to understand. It's only problem seems to be it's "IE 10+" requirement. I understand not supporting 6 and 7, fine, not supporting 8, okay that's Windows XP users, they are dying off, fine, but not supporting 9?

That being said I'll probably still use this somewhere and just deal with the support calls or try to get it to support 9 somehow, great work!.

-----


Well, theoretically IE9 users should all be automatically upgraded to IE10 anyway, so IE9 has less market share than IE8 at the moment (see http://www.netmarketshare.com/browser-market-share.aspx?qpri...).

-----


Sir Trevor uses HTML contenteditable, which is a bit non-standard in IE<10, although to their credit, they had support before most browsers.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: