[fxtentacle]

I feel like the article misses out on two crucial truths:

1. Most of the new tools are pure nightmare to maintain. RoR has breaking API changes often enough that you need multiple people to maintain a large codebase, whereas in PHP you'd only need one person because things don't magically break that often. And MongoDB is so convoluted and complicated that almost nobody can deploy it correctly. And then there's "new" container techniques, which are basically just an admission that you have no f*ing clue on how to make your new tool set secure. In most cases, the loud new technology is just over-funded hipster stuff, but not ready for the real world yet.

2. Posting things online (e.g. Source Code) will not only attract the attention of peers. You might also get flooded with rather demanding emails by technically incompetent people who complain that your free source code release didn't solve their problem.

Also, I wonder if the author is aware of IRCs ongoing popularity for private development discussion rooms. It seems many people thought Slack was new, but some of us programmers have been hanging out like that since 95.

[bdcravens]

Rails has a very predictable cadence (once a year) and a published support policy.

https://guides.rubyonrails.org/maintenance_policy.html

> RoR has breaking API changes often enough ... magically break that often

According to the support policy, nothing magic about those breaking changes: "Breaking changes are paired with deprecation notices in the previous minor or major release."

[fxtentacle]

I remember that we had one particularly horrible maintenance update when Arel queries that used to work just fine suddenly started always loading one wrong item. Turns out, they did an internal change so that our way of doing User.where(User.arel_table[:id].eq(2)) now returned nil for the arel eq so that we were calling User.where(nil) which got translated into User.where(id: nil.id)

That said, I was referring more to the Ruby on Rails ecosystem in general. Our production deployment has 80 gems, which I'd say is a normal number for a big Rails webapp, and sadly many of them do not follow semantic versioning, so that minor gem version updates might contain unexpected breaking changes for us.

The advantage that old languages like PHP or C++ have here is that their standard libraries have been around for so long that the API rarely changes these days.

[jcoffland]

> You might also get flooded with rather demanding emails by technically incompetent people who complain that your free source code release didn't solve their problem.

Once I learned to listen to incompetent users, I started to create usable software.

My gut reaction is still, "RTFM you're doing it wrong." But now I follow that up by figuring out how to make the software work like the user thought it should or I change it so they never get in the frustrating situation in the first place.

What I finally realized was that if one person got frustrated enough with my software that they took the trouble to post an incoherent and technically incorrect rant on Github then it's likely that 100s more users had similar problems and said nothing.

Now I receive effusive emails about my Open-Source almost weekly.

[fxtentacle]

I fully agree with you that listening to users is the best way to create usable software.

But after reading the article, I thought that the 99% number was about developers not joining the discussion with other developers. And for that purpose, I'm not sure if open source is still a good idea.

[pm90]

> You might also get flooded with rather demanding emails by technically incompetent people who complain that your free source code release didn't solve their problem.

This. Happens so frequently, that making things OSS now carries an additional burden. I personally find it very painful to e.g. ignore the PR or issue opened by some hapless person in a bad situation trying to figure out the most dumbest thing. It makes the alternative (never OSS'ing anything) sound better, if only for my own peace of mind.

[siwatanejo]

Is PHP still a thing?

[emeraldd]

PHP is horrible as a language, but it fills its niche very well: * You can get it to run dang near anywhere. * It has an extremely low barrier to entry for new devs (blessing and a curse). * There's a large volume of code already out there. * If you need something that's a little more than a static site but not a full blown custom system, it's one of the simplest ways to get something out the door. * If you know how to use it, there's likely someone willing to pay you to do so on their behalf.

So yeah, PHP is still a thing.

[mtbcoder]

> PHP is horrible as a language

Eh, that's not really the case anymore either. It's made many improvements over the years. Not that I'm saying it's some wonderful language, but you can't really compare it to the PHP 4/early 5 days. I think credit is deserved to the folks who have brought PHP to where it is today.

[davesmith1983]

Yes. Most of the world's websites run on it.

[sfkdjf9j3j]

Is that still true if you don't count Wordpress sites?

[cblum]

Why would you not count those?

[rowanG077]

Because they are not really "code". Just like I don't consider someone making cookies from ready cookie dough a baker.

[mtbcoder]

I mean, the underlying code base is still PHP (granted the code base is awful) but there's a lot of Java spaghetti code out there too you know.

[fxtentacle]

In the enterprise world, very much so. PHP is super easy to deploy, requires little maintenance, and you can easily hire good admins to keep things running smoothly.

On the other hand, not even using a service like Heroku can save us from constantly having to patch or update the Rails apps.

[elorant]

30% of web sites are based on WordPress.