Yes. I've been working on an corporate internal RoR tool that launched in 2010. Various engineers over the years continued releasing new features and updating language/framework development... when I earlier this year, development/maintenance cost was no higher than any other software of that nature and age.

Cost only goes up and up when engineers go overboard with "clever" Ruby magic... which is human error, don't blame the tool.

>Cost only goes up and up when engineers go overboard with "clever" Ruby magic... which is human error, don't blame the tool.

I've only used a few languages in production for my non-developer job, but I've noticed very different frequencies of "clever" code between them.

R: This is my primary language. I love it, but it almost encourages clever coding. There are 10 ways to do any task without even touching third-party packages.

Python: My secondary language at work. Clever coding is definitely possible in Python, but the language's syntax makes it easy to spot. Detection isn't as good as prevention but it's better than nothing.

(I also grudgingly use SAS, but won't waste my time looking for ways it encourages clear coding.)

Couldn’t agree more. I was part of a $30 million Rails project that got unmanageable and burned after 2-3 years. Golang is so much more forgiving to human error.

30M. Well there’s your problem. I can just imagine the premature optimizations and the bloated abstraction that went in the planning phases.

Yeah, welcome to enterprise development (regardless of programming language). Every VP fancies themselves as the next Steve Jobs and like to be uncompromising about delivering their vision. Which ironically ends up as design by committee when you have that many assholes in a room unwilling to back down but also needing to save face.

And to be fair, most of the premature optimization and bloated abstractions are just your architects sitting around bored for 6 months while the project sponsors argue over reporting minutiae (but won’t approve the designs until their pet features are pulled in on the roadmap). They know the entire feature list is going to get changed at the last minute as the political winds shift, so they’re designing an overbuilt architecture to CYA for whatever random bullshit someone will pull a week before a deadline.

It's not even about programming languages at this point. It's Peopleware. People are the number 1 cause of all problems in software.

Have you maintained anything after the first year where that wasn't the case? Especially if you had a high degree of churn on the developers.

I'll grant that it is easier in more stable API environments. But we are our own worst enemies in that race.

if I pick up an old Java project, it might be a mess, but I'll be able to rename methods, refactor classes, and upgrade libraries until it gets into shape - and I'll have a fair amount of confidence that it'll keep working while I do that, because metaprogramming is rare, APIs are fairly stable, and the IDE will mostly be able to understand what the code is doing. In a ruby project - especially in a Rails project - you can never know for sure what code is calling what. There's no "Find usages" tool that can be relied on. And then, all your dependencies will have completely changed their APIs and behaviors, and they'll have a complex matrix of incompatibilities that means that you might have to upgrade several libraries at a time and rewrite a lot of code just to keep things working.

Apologies for the slow response.

I honestly can't compare to a rails app, as I don't have the experience. I can say that modern dev practices worry me with the constant upgrade train on api standards. On the one side, progress is quite nice. On the flipside, what you describe in "all your dependencies have completely changed their APIs" is just as annoying in Java as it is in any language. More so if someone has helpfully split your codebase into as many supposedly independent parts as they can.

More than that, it is amusing that many of the refactoring tools that you reference actually began in more dynamic languages. I've seen that folks that rely on their IDE to be able to refactor have a habit of making codebases that they have to use an IDE to refactor. I grant it could just be confirmation bias.

> metaprogramming is rare

In Java? Not really. Spring has been around since 2003 or so.

Having a framework do metaprogramming, and using that framework is one thing. I think that they mean user-level metaprogramming. This is MUCH more evident in dynamic languages.

I guess he was referring not to metaprogramming in the common sense, but to the change of behaviour of built-in methods and classes.

Ah, I thought that's called "monkey patching".

And probably also the non-local effects of using a framework - and a fairly magic one at that. All the effects of which are understood when creating the functionality, but the maintainer (even when it is the author) has a much harder time with probably only a partial understanding with certain things being out of mind.

I would stay Dynamic languages like Ruby are inherently more flexible and powerful, which more easily leads to complexity in the system... (if left unchecked)