6 ms·

but have you ever had to maintain a ruby project after the first year? The cost just goes up and up, and I think it’s because the language is so hostile to stat

but have you ever had to maintain a ruby project after the first year? The cost just goes up and up, and I think it’s because the language is so hostile to static analysis.

jumpinalake 7y ago
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.
- jaequery 7y ago
  30M. Well there’s your problem. I can just imagine the premature optimizations and the bloated abstraction that went in the planning phases.
  - wayoutthere 7y ago
    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.
    - james_s_tayler 7y ago
      It's not even about programming languages at this point. It's Peopleware. People are the number 1 cause of all problems in software.
lsd5you 7y ago
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.
losteric 7y ago
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.
- vharuck 7y ago
  >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.)
taeric 7y ago
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.
- jes5199 7y ago
  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.
  - tannhaeuser 7y ago
    > metaprogramming is rare In Java? Not really. Spring has been around since 2003 or so.
    - sam_lowry_ 7y ago
      I guess he was referring not to metaprogramming in the common sense, but to the change of behaviour of built-in methods and classes.
      - tannhaeuser 7y ago
        Ah, I thought that's called "monkey patching".
    - michaelcampbell 7y ago
      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.
gitgud 7y ago
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)

but have you ever had to maintain a ruby project after the first year? The cost just goes up and up, and I think it’s because the language is so hostile to static analysis.

jumpinalake 7y ago

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.

jaequery 7y ago
30M. Well there’s your problem. I can just imagine the premature optimizations and the bloated abstraction that went in the planning phases.
- wayoutthere 7y ago
  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.
  - james_s_tayler 7y ago
    It's not even about programming languages at this point. It's Peopleware. People are the number 1 cause of all problems in software.

lsd5you 7y ago

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.

losteric 7y ago

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.

vharuck 7y ago
>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.)

taeric 7y ago

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.

jes5199 7y ago
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.
- tannhaeuser 7y ago
  > metaprogramming is rare In Java? Not really. Spring has been around since 2003 or so.
  - sam_lowry_ 7y ago
    I guess he was referring not to metaprogramming in the common sense, but to the change of behaviour of built-in methods and classes.
    - tannhaeuser 7y ago
      Ah, I thought that's called "monkey patching".
  - michaelcampbell 7y ago
    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.

gitgud 7y ago

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)