6 ms·

One of the things I've hated about maintaining PHP web apps is how reliant on the web interface they usually are; this has thankfully started to change. Drupal

One of the things I've hated about maintaining PHP web apps is how reliant on the web interface they usually are; this has thankfully started to change. Drupal (finally) has decent CLI tools. MediaWiki is among the few to have had CLI tools for many years. But, the thing that struck me about this project and the examples is just how verbose PHP has gotten over the years. It is strikingly similar to old Java, in terms of class definitions and the like. I know PHP has also gotten faster and lot of "grown up" language features in that time, too, but some of its charm as a language with strong "whipuptitude" is lost. I'm certain it's a better language than it was a decade or two ago, and it was, frankly, awful by many measures back then. But, it sure does take a lot of typing. So, I like that things like this exist (though I likely wouldn't use it...I really need most of my CLI tools to be standalone with no non-core dependencies). I'd like it if every web developer knew how to make good CLI apps and did so for every web app. I use Perl or POSIX shell mostly for my CLI apps, but PHP makes perfect sense for tools that work with existing web apps (the Drupal helper scripts I've written are mostly in PHP).

chx 9y ago
Sigh. drush has been the Drupal shell since 2009 or something and have been amazing for more years than I can count.
- SwellJoe 9y ago
  drush is great, and I've been using it for a few years. But, module support in drush was abysmal until pretty recently, though (still pretty weak; I'd guess 80-90% of modules have no drush support). And, for a lot of core Drupal stuff that I would think would be obvious (CRUD for arbitrary entities, for example) one has to write one's own drush plugin, and it's often complicated as hell. I love what drush does, but I've frequently been disappointed/frustrated by what it doesn't. That's not to denigrate drush or the developer(s) of drush. drush is/was a remarkable improvement over the pre-drush era. I just think Drupal wasn't built to be driven by a CLI. It isn't API-native, by any stretch of the imagination, nor is it front-end agnostic. So, drush is historically working around rather than working with, and it shows in that most of Drupal is still inaccessible to drush (at least in Drupal 7; I haven't deployed Drupal 8 and probably never will as the migration from 6 to 7 was too painful for me to be willing to ever do it again). So...I think we may just disagree on what "decent" and "finally" means. Also, compare to some other ways to build web apps; most modern web frameworks have pretty obvious ways to build CLI tools, and often are built around standard frameworks for doing so (Yeoman or generators/console in Rails). Drupal being based on Symfony now gets it a lot of that same kind of thing; so, it is recently decent, by my estimation. Others may disagree, of course.
  - sputr 9y ago
    Drush was amazing ... but only in the context of the hell that Drupal 6/7 was.
    - chx 9y ago
      Hell is D8. I mean, it sure is amazing when things work but when they don't, the rabbit hole goes so deep you can't even imagine.
      - SwellJoe 9y ago
        I feel that way about D7. If D8 is worse, I definitely don't want to go down the rabbit hole even a little bit. I feel like Drupal could be a workshop on why "a wrong abstraction is worse than no abstraction". I'd assumed things were better on that front in D8, based on what I'd read, and based on the theory that at least the wrong abstractions would be common across everything (Drupal has always had the problem of a dozen different modules for every trivial thing, and every module needs a different combination of those trivial thing modules). I'd hope, at least, that database abstractions are nicer? The database API in Drupal 7 is, frankly, awful.
        chx 9y ago
        > The database API in Drupal 7 is, frankly, awful. While Larry Garfield architected it, yours truly here put in quite some work implementing the API you like so much :) But that's just context -- I could ask you what are your problems but I won't, I am out and the API is frozen until D9. I would recommend filing an issue to tell what you don't like.
        SwellJoe 9y ago
        Sorry to be harsh, and I guess my problem is really at a higher level, now that I'm looking at the code again. It's the entities and fields and a bunch of other higher level APIs that interact with the database that I hate. But, that's the way everything interacts with the database in D7. So, I'm wrong about the database API...it's just that working with data in D7 doesn't use the database API directly anymore, it uses entities and other higher-level APIs. My problem is that by the time something reaches the database is it completely unrecognizable and is spewed all over the database in a half dozen tables. This is a problem of D7 much more than D6. It takes a handful of queries to build an "entity", for instance, and forget hitting the database from outside of Drupal. Every CMS we've used in the past, I was able to use the database as the source of truth across many apps in many languages; the database was effectively the API I used to share data across our Perl and Python apps and Drupal. With Drupal 7 I can't do that at all. I have to go through Drupal to pull anything out or put anything into the database in a way that Drupal can work with it. It's just a pain in the ass. And, Drupal 7 is an awful experience for building APIs, so I can't really integrate stuff that way, either. I understand improving the API building experience is a focus for D8. Anyway, I want my database to look like my model, and Drupal 7 doesn't do that. It spreads the model across a whole bunch of tables (I've got like 60 "drupal_field" tables in my D7 database...I have no idea what to do with all that mess). And, the APIs in Drupal to work with entities and fields and such are really ornery to work with and getting useful errors out of them is impossible. That's not the fault of the low-level database API, but it is the fault of how Drupal 7 implements putting things into the database. If that makes sense. Mostly I've just realized Drupal doesn't fit my mental model of how CRUD apps should work, and working with it has been a real chore. I know lots of people are super productive with it, but in several years of poking at it in my spare time, I still don't "get it". I honestly still don't even have a good mental model for how the pieces fit together; it's so big, there are so many competing ways to do anything, it's full of re-implementations from one version to the next, etc. I can't make any sense out of it, and every time I come back to it it takes me hours just to get up to speed enough to make minor changes.
camus2 9y ago
> But, the thing that struck me about this project and the examples is just how verbose PHP has gotten over the years. It is strikingly similar to old Java, in terms of class definitions and the like. It's all opt-in. Nothing forces you to use Composer, classes or even type hinting in PHP if you do not depend on third party libraries backed by composer. Most of C extensions from 10 years ago are still here and procedural code from that era would probably still work today on PHP 7.
- SwellJoe 9y ago
  Sure, I think they're good things. But, some other languages manage to do the same without so many letters and without so much boilerplate.
  - NightlyDev 9y ago
    Just curious - what languages do you have in mind?
    - SwellJoe 9y ago
      JavaScript has gotten extremely concise in recent years, even with type annotations (with TypeScript or Flow). Perl with Moose/Moo is very concise. I dunno about Ruby or Python in terms of type annotations, but both have more concise class definition syntax. So, kinda all of the direct competitors to PHP have a more concise syntax for the same features. But, maybe more importantly, this seems to be using classes where it makes little sense to use classes, but I see it a lot in PHP code. An idiomatic implementation of the same kinds of tools in JS/Perl/Python/Ruby might be shorter simply by virtue of not wrapping everything in a class. It's sort of an anti-pattern to OOP-all-the-things in those languages, while in PHP there seems to be a religious zeal for classes.
- lj3 9y ago
  > Nothing forces you to use Composer And yet nearly everybody does. Is there a compelling upside to justify that tradeoff? I can't think of a worse fate for a language than trying to mimic Java circa 1998, but that's exactly what's happening.
deleted 9y ago
[deleted]
TazeTSchnitzel 9y ago
> But, the thing that struck me about this project and the examples is just how verbose PHP has gotten over the years. It is strikingly similar to old Java, in terms of class definitions and the like. Something that probably hurts the language here is the lack of autoloading for functions, whereas it exists for classes, so exposing bare functions is a runtime performance penalty (their containing files must be loaded on every request, if you use Composer), which results in a preference for putting everything in a class. :/
- SwellJoe 9y ago
  Ah, that explains it. I didn't know about that, but my first thought was, "Why the hell is every single thing wrapped in a class?" That'd be considered non-idiomatic in JS/Perl/Python/Ruby, I think. Maybe not Ruby; Rubyists like their classes.
wmichelin 9y ago
Laravel has built in console commands (using a light Symfony console wrapper I believe)

chx 9y ago

Sigh. drush has been the Drupal shell since 2009 or something and have been amazing for more years than I can count.

SwellJoe 9y ago
drush is great, and I've been using it for a few years. But, module support in drush was abysmal until pretty recently, though (still pretty weak; I'd guess 80-90% of modules have no drush support). And, for a lot of core Drupal stuff that I would think would be obvious (CRUD for arbitrary entities, for example) one has to write one's own drush plugin, and it's often complicated as hell. I love what drush does, but I've frequently been disappointed/frustrated by what it doesn't. That's not to denigrate drush or the developer(s) of drush. drush is/was a remarkable improvement over the pre-drush era. I just think Drupal wasn't built to be driven by a CLI. It isn't API-native, by any stretch of the imagination, nor is it front-end agnostic. So, drush is historically working around rather than working with, and it shows in that most of Drupal is still inaccessible to drush (at least in Drupal 7; I haven't deployed Drupal 8 and probably never will as the migration from 6 to 7 was too painful for me to be willing to ever do it again). So...I think we may just disagree on what "decent" and "finally" means. Also, compare to some other ways to build web apps; most modern web frameworks have pretty obvious ways to build CLI tools, and often are built around standard frameworks for doing so (Yeoman or generators/console in Rails). Drupal being based on Symfony now gets it a lot of that same kind of thing; so, it is recently decent, by my estimation. Others may disagree, of course.
- sputr 9y ago
  Drush was amazing ... but only in the context of the hell that Drupal 6/7 was.
  - chx 9y ago
    Hell is D8. I mean, it sure is amazing when things work but when they don't, the rabbit hole goes so deep you can't even imagine.
    - SwellJoe 9y ago
      I feel that way about D7. If D8 is worse, I definitely don't want to go down the rabbit hole even a little bit. I feel like Drupal could be a workshop on why "a wrong abstraction is worse than no abstraction". I'd assumed things were better on that front in D8, based on what I'd read, and based on the theory that at least the wrong abstractions would be common across everything (Drupal has always had the problem of a dozen different modules for every trivial thing, and every module needs a different combination of those trivial thing modules). I'd hope, at least, that database abstractions are nicer? The database API in Drupal 7 is, frankly, awful.
      - chx 9y ago
        > The database API in Drupal 7 is, frankly, awful. While Larry Garfield architected it, yours truly here put in quite some work implementing the API you like so much :) But that's just context -- I could ask you what are your problems but I won't, I am out and the API is frozen until D9. I would recommend filing an issue to tell what you don't like.
        SwellJoe 9y ago
        Sorry to be harsh, and I guess my problem is really at a higher level, now that I'm looking at the code again. It's the entities and fields and a bunch of other higher level APIs that interact with the database that I hate. But, that's the way everything interacts with the database in D7. So, I'm wrong about the database API...it's just that working with data in D7 doesn't use the database API directly anymore, it uses entities and other higher-level APIs. My problem is that by the time something reaches the database is it completely unrecognizable and is spewed all over the database in a half dozen tables. This is a problem of D7 much more than D6. It takes a handful of queries to build an "entity", for instance, and forget hitting the database from outside of Drupal. Every CMS we've used in the past, I was able to use the database as the source of truth across many apps in many languages; the database was effectively the API I used to share data across our Perl and Python apps and Drupal. With Drupal 7 I can't do that at all. I have to go through Drupal to pull anything out or put anything into the database in a way that Drupal can work with it. It's just a pain in the ass. And, Drupal 7 is an awful experience for building APIs, so I can't really integrate stuff that way, either. I understand improving the API building experience is a focus for D8. Anyway, I want my database to look like my model, and Drupal 7 doesn't do that. It spreads the model across a whole bunch of tables (I've got like 60 "drupal_field" tables in my D7 database...I have no idea what to do with all that mess). And, the APIs in Drupal to work with entities and fields and such are really ornery to work with and getting useful errors out of them is impossible. That's not the fault of the low-level database API, but it is the fault of how Drupal 7 implements putting things into the database. If that makes sense. Mostly I've just realized Drupal doesn't fit my mental model of how CRUD apps should work, and working with it has been a real chore. I know lots of people are super productive with it, but in several years of poking at it in my spare time, I still don't "get it". I honestly still don't even have a good mental model for how the pieces fit together; it's so big, there are so many competing ways to do anything, it's full of re-implementations from one version to the next, etc. I can't make any sense out of it, and every time I come back to it it takes me hours just to get up to speed enough to make minor changes.

camus2 9y ago

> But, the thing that struck me about this project and the examples is just how verbose PHP has gotten over the years. It is strikingly similar to old Java, in terms of class definitions and the like. It's all opt-in. Nothing forces you to use Composer, classes or even type hinting in PHP if you do not depend on third party libraries backed by composer. Most of C extensions from 10 years ago are still here and procedural code from that era would probably still work today on PHP 7.

SwellJoe 9y ago
Sure, I think they're good things. But, some other languages manage to do the same without so many letters and without so much boilerplate.
- NightlyDev 9y ago
  Just curious - what languages do you have in mind?
  - SwellJoe 9y ago
    JavaScript has gotten extremely concise in recent years, even with type annotations (with TypeScript or Flow). Perl with Moose/Moo is very concise. I dunno about Ruby or Python in terms of type annotations, but both have more concise class definition syntax. So, kinda all of the direct competitors to PHP have a more concise syntax for the same features. But, maybe more importantly, this seems to be using classes where it makes little sense to use classes, but I see it a lot in PHP code. An idiomatic implementation of the same kinds of tools in JS/Perl/Python/Ruby might be shorter simply by virtue of not wrapping everything in a class. It's sort of an anti-pattern to OOP-all-the-things in those languages, while in PHP there seems to be a religious zeal for classes.
lj3 9y ago
> Nothing forces you to use Composer And yet nearly everybody does. Is there a compelling upside to justify that tradeoff? I can't think of a worse fate for a language than trying to mimic Java circa 1998, but that's exactly what's happening.

deleted 9y ago

[deleted]

TazeTSchnitzel 9y ago

> But, the thing that struck me about this project and the examples is just how verbose PHP has gotten over the years. It is strikingly similar to old Java, in terms of class definitions and the like. Something that probably hurts the language here is the lack of autoloading for functions, whereas it exists for classes, so exposing bare functions is a runtime performance penalty (their containing files must be loaded on every request, if you use Composer), which results in a preference for putting everything in a class. :/

SwellJoe 9y ago
Ah, that explains it. I didn't know about that, but my first thought was, "Why the hell is every single thing wrapped in a class?" That'd be considered non-idiomatic in JS/Perl/Python/Ruby, I think. Maybe not Ruby; Rubyists like their classes.

wmichelin 9y ago

Laravel has built in console commands (using a light Symfony console wrapper I believe)