5 ms·

Yep. IMHO MySQL becoming boring (fast, pretty reliable, non-compliant quirks being ironed out, decent backup tool availability, credible admin tools, JSON and

Yep. IMHO MySQL becoming boring (fast, pretty reliable, non-compliant quirks being ironed out, decent backup tool availability, credible admin tools, JSON and CTE support) is one of the most important long term trends on the internet. Along with the parallel evolution of PHP.

klysm 5y ago
I strongly dislike the combination of php and MySQL, from the (recent) experiences I’ve had with it. I don’t see a good reason to pick that as a greenfield stack, but I could be convinced otherwise.
- pphysch 5y ago
  For me it's not necessarily the tech themselves, but the lack of any framework to guide development for the next guy. All the PHP+MySQL I've worked with has been horribly bespoke and brittle. Want to significantly change a URL? Need to refactor every path in the .PHP file, because it's importing something from ../.. Or get in the spaghetti business with path aliasing on the webserver. Want to refactor the database schema? Difficulty: Impossible, because raw SQL strings are scattered everywhere, including on other systems. Want to add/modify a new internal CRUD form? Gonna be several hours of work to RE what the last guy did to keep things consistent, while tiptoeing into the SQL to not break anything. With a proper framework, this is a 5 minute task and a few LOC into the "admin interface". It works, and you can do a lot with just a few php files and a basic Linux system, but there are downsides.
  - unfocussed_mike 5y ago
    There are several PHP frameworks worth using. Laravel is, IMO, among the best web frameworks available full stop. Certainly one of the most maturely documented. It addresses all the points you make.
    - alophawen 5y ago
      I had a 10 year career doing PHP, in the last year or so I also enjoyed Laravel and built 10 or so sites with it. It did many things right. Eventually some blade template error resulted in an impossible stack trace due to the insane amount of magic behind the scenes in Laravel, and while debugging that I decided to stop relying on such black magic hack of a framework. Around the same time Go gained in popularity and I have been working with Go since and are very happy with it. This was Laravel 5 days and I'm sure much has changed. I completely adored the laracasts made by Jeffrey Way. I wish every framework had a guy like that do produce learning materials.
      - tored 5y ago
        Frameworks helps developers to move in the right direction, and that is a good thing, however when you have used a framework long enough you start seeing the cracks. Frameworks solves a general problem, you on the other hand has a specific problem. To be able to accommodate your specific problem and everyone else specific problems frameworks has tendency to heavily rely on magic. * magic classes - using PHP magic methods for everything, the actual class is usually empty and things happening elsewhere. * magic files - put a file with the correct name in folder somewhere and things happen * magic configuration - put a hard coded string in some config file and you change the entire behaviour of the app. * magic layers - if you follow the execution path with the debugger you spend the majority of time circling around in different layers and very little time in your own code. All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks.
        klysm 5y ago
        > All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks. I think that’s because that kind of code has a much higher maintenance burden. It’s much more difficult to get up to speed on what’s going on in complex magical code. But you can probably trust a framework that’s achieved critical mass to make reasonable decisions and stay alive for a while.
  - tored 5y ago
    All of these problems are created by the developers. I have created many on-the-fly mini-PHP frameworks to use within existing legacy code bases to avoid all of this. Easiest way to avoid manually requiring files is to use classes with the auto loader. Done. The second easiest solution is to have different constants that has the full path to a directory and then just you use the correct constant when doing a require. No relative paths required. You can even have one require constant per file if that is your game. Raw sql is fine, just don’t scatter it in every file, instead put sql in specific repositories, e.g ArticleRepository, and do all article queries in there. Now it is easy. An ORM actually creates more problems when refactoring because entities are spread out everywhere. If you use something like Phpstorm IDE it can help refactor raw sql too. Problem is that many developers doesn’t think this thru and even worse they accept the situation and don’t do anything about even if they can. Instead they go to forums and complain. I’m sorry but I have zero tolerance for that.
    - pphysch 5y ago
      A decent ORM framework provides all those things out of the box, and I disagree that the ORM creates more problems than its worth. It is a fine tool to accelerate development.
- unfocussed_mike 5y ago
  MySQL + PHP (Laravel + Composer + Lighthouse + Spatie MediaLibrary) is very productive.
  - klysm 5y ago
    I agree it's _initially_ productive, but the it becomes very difficult to maintain.
    - unfocussed_mike 5y ago
      Why/where, particularly in Laravel? Laravel has an excellent ORM, a great query builder (I write almost no SQL), an effective database migrations system, a solid class hierarchy (no include statements anywhere), a really useful job queuing system, and it is built around Composer (one of the best package managers anywhere). Lighthouse is really a first-class, schema-first GraphQL binding with a very logical code interface. I don't see any code maintenance problems in Laravel that can't be mitigated by the same discipline you need anywhere else.
      - klysm 5y ago
        I don’t have anything objective to back this up, but in my experience it requires a lot more discipline and initial knowledge from the devs. Much of the existing documentation for PHP is just plain wrong, or horrible advice. It’s difficult for new devs to learn these practices. PHP let’s you be ‘lazy’ and hack in shortcuts to solve problems - lots of discipline required there. If you have a solid team and some people with a good background in the framework and PHP that can mentor effectively, then it probably won’t be bad. It still would not be my first choice though.
        tored 5y ago
        Compared to what?

klysm 5y ago

I strongly dislike the combination of php and MySQL, from the (recent) experiences I’ve had with it. I don’t see a good reason to pick that as a greenfield stack, but I could be convinced otherwise.

pphysch 5y ago
For me it's not necessarily the tech themselves, but the lack of any framework to guide development for the next guy. All the PHP+MySQL I've worked with has been horribly bespoke and brittle. Want to significantly change a URL? Need to refactor every path in the .PHP file, because it's importing something from ../.. Or get in the spaghetti business with path aliasing on the webserver. Want to refactor the database schema? Difficulty: Impossible, because raw SQL strings are scattered everywhere, including on other systems. Want to add/modify a new internal CRUD form? Gonna be several hours of work to RE what the last guy did to keep things consistent, while tiptoeing into the SQL to not break anything. With a proper framework, this is a 5 minute task and a few LOC into the "admin interface". It works, and you can do a lot with just a few php files and a basic Linux system, but there are downsides.
- unfocussed_mike 5y ago
  There are several PHP frameworks worth using. Laravel is, IMO, among the best web frameworks available full stop. Certainly one of the most maturely documented. It addresses all the points you make.
  - alophawen 5y ago
    I had a 10 year career doing PHP, in the last year or so I also enjoyed Laravel and built 10 or so sites with it. It did many things right. Eventually some blade template error resulted in an impossible stack trace due to the insane amount of magic behind the scenes in Laravel, and while debugging that I decided to stop relying on such black magic hack of a framework. Around the same time Go gained in popularity and I have been working with Go since and are very happy with it. This was Laravel 5 days and I'm sure much has changed. I completely adored the laracasts made by Jeffrey Way. I wish every framework had a guy like that do produce learning materials.
    - tored 5y ago
      Frameworks helps developers to move in the right direction, and that is a good thing, however when you have used a framework long enough you start seeing the cracks. Frameworks solves a general problem, you on the other hand has a specific problem. To be able to accommodate your specific problem and everyone else specific problems frameworks has tendency to heavily rely on magic. * magic classes - using PHP magic methods for everything, the actual class is usually empty and things happening elsewhere. * magic files - put a file with the correct name in folder somewhere and things happen * magic configuration - put a hard coded string in some config file and you change the entire behaviour of the app. * magic layers - if you follow the execution path with the debugger you spend the majority of time circling around in different layers and very little time in your own code. All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks.
      - klysm 5y ago
        > All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks. I think that’s because that kind of code has a much higher maintenance burden. It’s much more difficult to get up to speed on what’s going on in complex magical code. But you can probably trust a framework that’s achieved critical mass to make reasonable decisions and stay alive for a while.
- tored 5y ago
  All of these problems are created by the developers. I have created many on-the-fly mini-PHP frameworks to use within existing legacy code bases to avoid all of this. Easiest way to avoid manually requiring files is to use classes with the auto loader. Done. The second easiest solution is to have different constants that has the full path to a directory and then just you use the correct constant when doing a require. No relative paths required. You can even have one require constant per file if that is your game. Raw sql is fine, just don’t scatter it in every file, instead put sql in specific repositories, e.g ArticleRepository, and do all article queries in there. Now it is easy. An ORM actually creates more problems when refactoring because entities are spread out everywhere. If you use something like Phpstorm IDE it can help refactor raw sql too. Problem is that many developers doesn’t think this thru and even worse they accept the situation and don’t do anything about even if they can. Instead they go to forums and complain. I’m sorry but I have zero tolerance for that.
  - pphysch 5y ago
    A decent ORM framework provides all those things out of the box, and I disagree that the ORM creates more problems than its worth. It is a fine tool to accelerate development.
unfocussed_mike 5y ago
MySQL + PHP (Laravel + Composer + Lighthouse + Spatie MediaLibrary) is very productive.
- klysm 5y ago
  I agree it's _initially_ productive, but the it becomes very difficult to maintain.
  - unfocussed_mike 5y ago
    Why/where, particularly in Laravel? Laravel has an excellent ORM, a great query builder (I write almost no SQL), an effective database migrations system, a solid class hierarchy (no include statements anywhere), a really useful job queuing system, and it is built around Composer (one of the best package managers anywhere). Lighthouse is really a first-class, schema-first GraphQL binding with a very logical code interface. I don't see any code maintenance problems in Laravel that can't be mitigated by the same discipline you need anywhere else.
    - klysm 5y ago
      I don’t have anything objective to back this up, but in my experience it requires a lot more discipline and initial knowledge from the devs. Much of the existing documentation for PHP is just plain wrong, or horrible advice. It’s difficult for new devs to learn these practices. PHP let’s you be ‘lazy’ and hack in shortcuts to solve problems - lots of discipline required there. If you have a solid team and some people with a good background in the framework and PHP that can mentor effectively, then it probably won’t be bad. It still would not be my first choice though.
      - tored 5y ago
        Compared to what?