13 ms·

In mature OOP you have ways to write nice models and have good validations. https://guides.rubyonrails.org/active_record_validations.html https://guides.rubyonr

In mature OOP you have ways to write nice models and have good validations. https://guides.rubyonrails.org/active_record_validations.html https://guides.rubyonrails.org/active_record_validations.htm... I will argue that the complexity of software development is not because of OOP vs Functional. Tooling, documentation, quality of libraries and people are what matter most. Ruby was a massive success is largely attributed to above. We are humans, we can understand and deal with a fixed amount of complexity if I can offload some of it to a framework, library or tool I will have more time to work on my problem. Every time I try to play with anything Functional I got hit by a bus of undocumented frameworks(Erlang), multiple standard libraries (ocaml), competing half finished implementations (lisp), arcane tooling (scala), no tooling (Haskell) and broken tooling (F# on Linux).

jes5199 7y ago
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)
cottsak 7y ago
Agree. You can write terse, maintainable, well encapsulated, testable and readable code in most any language. The problem is about the humans not the language they select. But yes, complexity is also a major problem.
- alkonaut 7y ago
  What I have learned is that what makes a language (or platform, or tool) "good" isn't how easy it is to write good code, but how hard it is to write bad code. Does a beginner following the path of least resistence, on a tight schedule, end up with maintainable code or not? I'd argue that this is the weakness with (the traditional) OO languages. An experienced developer with plenty of time can write good software with almost any tool. But that's not what's interesting. I want to see tools that not just lets but rather guides inexperienced developers into making maintainable software. Things like "no nulls" or "immutable by default" in Rust and most functional languages are two examples of such designs. OO itself doesn't necessarily mean the developers get trapped in poor code, but the traditional 3 (C++, Java, C#) sure do give developers lots of guns to shoot at their feet. Perhaps not mainly because they are OO, but because they inherited some poor fundamental decisions about mutability and nulls (from C) and about inheritance as a default method of abstraction (from C++) etc.
  - pytester 7y ago
    >isn't how easy it is to write good code, but how hard it is to write bad code In many languages they make it harder to write bad code but they do so at the expense of delivering functionality quickly. There's a clear trade off there - one which is often very project dependent (some projects primarily need to develop functionality quickly; others prioritize stability). The problem of slowing down development becomes particularly pronounced when developing something where the biggest risk isn't building the thing wrong, but building the wrong thing. It's extremely expensive to use a very strict language if you're developing code where requirements are highly in flux and cannot be discerned up front. Ideally general purpose languages should enable a smooth transition from coding up a prototype/MVP all the way to production-hardened, spotlessly clean code. I like rust a lot but I would only use it to write very low level code where the requirements are cast in stone and speed and stability is of the utmost importance. It's a lovely language but it's very slow to build stuff in, and in almost all cases it should be used to rewrite something existing rather than to build it anew.
jacknj 7y ago
When you mention "no tooling (Haskell)" what do you mean? I am using Haskell (mostly for hobby projects) and am wondering what I am missing out on, since I feel the tools available is sufficient.
merlincorey 7y ago
> competing half finished implementations (lisp) As well as one of the most complete specifications in ANSI Common Lisp.
- agumonkey 7y ago
  I'm curious about lispers. I thought quicklisp made a lot of things frictionless.
walshemj 7y ago
I think the argument is that for a lot of cases OOP isn't the right paradigm
pjmlp 7y ago
The irony is that Smalltalk already offered many FP patterns. In the end multi-paradim languages will win. What many FP advocates fail to acknowledge is that all FP languages that got some kind of mainstream adoption, might be FP first, but they are actually multi-paradigm.
- tabtab 7y ago
  No FP language has gotten mainstream adoption. Mainstream languages may have had FP features added, but that's different. I confess I don't "get" the benefits of FP for the type of applications I work on. Most examples are for a domain completely different, make unrealistic assumptions about domain patterns of change that I actually see, or fill in for weaknesses of a given language's OOP model.
  - pjmlp 7y ago
    I mean those FP languages that enjoy some commercial use like Common Lisp, Clojure, Scala, F#, OCaml and Haskell. All of them also expose OOP concepts.
    - tabtab 7y ago
      Lisp is flexible enough to be just about every paradigm. Too much flexibly can be a problem in some circumstances, but I don't want to get into yet another "Lisp fight" here about that. There are hundreds on the internet already.
apta 7y ago
This is already achievable using annotations in Java or attributes in C#, in a less verbose way. You just tag your method parameter with `@Valid` or `[Valid]` or what have you, and the framework you're using automatically ensures that the validations you specified on the data model are valid at that point in time.

jes5199 7y ago

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)

cottsak 7y ago

Agree. You can write terse, maintainable, well encapsulated, testable and readable code in most any language. The problem is about the humans not the language they select. But yes, complexity is also a major problem.

alkonaut 7y ago
What I have learned is that what makes a language (or platform, or tool) "good" isn't how easy it is to write good code, but how hard it is to write bad code. Does a beginner following the path of least resistence, on a tight schedule, end up with maintainable code or not? I'd argue that this is the weakness with (the traditional) OO languages. An experienced developer with plenty of time can write good software with almost any tool. But that's not what's interesting. I want to see tools that not just lets but rather guides inexperienced developers into making maintainable software. Things like "no nulls" or "immutable by default" in Rust and most functional languages are two examples of such designs. OO itself doesn't necessarily mean the developers get trapped in poor code, but the traditional 3 (C++, Java, C#) sure do give developers lots of guns to shoot at their feet. Perhaps not mainly because they are OO, but because they inherited some poor fundamental decisions about mutability and nulls (from C) and about inheritance as a default method of abstraction (from C++) etc.
- pytester 7y ago
  >isn't how easy it is to write good code, but how hard it is to write bad code In many languages they make it harder to write bad code but they do so at the expense of delivering functionality quickly. There's a clear trade off there - one which is often very project dependent (some projects primarily need to develop functionality quickly; others prioritize stability). The problem of slowing down development becomes particularly pronounced when developing something where the biggest risk isn't building the thing wrong, but building the wrong thing. It's extremely expensive to use a very strict language if you're developing code where requirements are highly in flux and cannot be discerned up front. Ideally general purpose languages should enable a smooth transition from coding up a prototype/MVP all the way to production-hardened, spotlessly clean code. I like rust a lot but I would only use it to write very low level code where the requirements are cast in stone and speed and stability is of the utmost importance. It's a lovely language but it's very slow to build stuff in, and in almost all cases it should be used to rewrite something existing rather than to build it anew.

jacknj 7y ago

When you mention "no tooling (Haskell)" what do you mean? I am using Haskell (mostly for hobby projects) and am wondering what I am missing out on, since I feel the tools available is sufficient.

merlincorey 7y ago

> competing half finished implementations (lisp) As well as one of the most complete specifications in ANSI Common Lisp.

agumonkey 7y ago
I'm curious about lispers. I thought quicklisp made a lot of things frictionless.

walshemj 7y ago

I think the argument is that for a lot of cases OOP isn't the right paradigm

pjmlp 7y ago

The irony is that Smalltalk already offered many FP patterns. In the end multi-paradim languages will win. What many FP advocates fail to acknowledge is that all FP languages that got some kind of mainstream adoption, might be FP first, but they are actually multi-paradigm.

tabtab 7y ago
No FP language has gotten mainstream adoption. Mainstream languages may have had FP features added, but that's different. I confess I don't "get" the benefits of FP for the type of applications I work on. Most examples are for a domain completely different, make unrealistic assumptions about domain patterns of change that I actually see, or fill in for weaknesses of a given language's OOP model.
- pjmlp 7y ago
  I mean those FP languages that enjoy some commercial use like Common Lisp, Clojure, Scala, F#, OCaml and Haskell. All of them also expose OOP concepts.
  - tabtab 7y ago
    Lisp is flexible enough to be just about every paradigm. Too much flexibly can be a problem in some circumstances, but I don't want to get into yet another "Lisp fight" here about that. There are hundreds on the internet already.

apta 7y ago

This is already achievable using annotations in Java or attributes in C#, in a less verbose way. You just tag your method parameter with `@Valid` or `[Valid]` or what have you, and the framework you're using automatically ensures that the validations you specified on the data model are valid at that point in time.