5 ms·

I still love you, Ruby. I wish we spent more time together.

by dollar 10y ago

hota_mazi 10y ago
I was madly in love with Ruby in 2005 but now, Ruby feels like this ex girlfriend you were completely infatuated with and eventually broke up with because you were too young to pay attention to her flaws.
- nstart 10y ago
  Since I never picked up ruby (I joined Python and now I'm about to pick up ruby). Curious what made you move away and what you've moved to?
  - hota_mazi 10y ago
    It's dynamically typed, which is a deal breaker for me today. I need not just a type system but one that supports parametric polymorphism, so definitely not Ruby, Python or even Go.
    - xapata 10y ago
      You can use traits instead. I know it's different, but it probably solves your problem.
      - hota_mazi 10y ago
        Traits are orthogonal to the dynamic/static question. My experience has taught me that not having type annotations in a source code makes it very hard to understand and maintain that source in the long run.
        vidarh 10y ago
        Ruby is more than flexible enough for you to add type annotation via DSLs, and use them to drive tests/fuzzing if you want that. There are a lot of people who have done that. They rarely see much use, though, because most of us quickly experience that the type annotations that seem essential when we work on statically typed languages quickly become less essential once you adopt a more idiomatic Ruby style. E.g. if you want to output something as text, rather than dictate what should be passed in, call #to_s on it (and optionally handle the failure if it doesn't implement #to_s, if it is reasonable to continue). Once you adopt the attitude of asking for what you actualy need rather than demanding the client pass in what you think should be passed in, type annotations start feeling like a clamp around your foot rather than a necessity in most cases, and most of the remaining assistance they could provide tends to fall away with test cases you would require in either case. I used to be a static typing zealot, and I still want things to be "as static as possible", but I've come to accept that most of the time the burdens it adds are not worth the benefits. I'm sure we can do better, and there are certainly cases where optional static type annotation could be helpful, but at this point I'm not giving up the expressiveness dynamc typing gives me - a static system would need to be practically "invisible" for me to find it acceptable.
        xapata 10y ago
        My experience has taught me that if static typing improves your code, it's probably hiding deeper flaws. I won't deny there are some clever things one can do to improve code with sophisticated typing. However, the typical usage is to alleviate the mistakes of bad names and poor design. When I find type errors at runtime, I look for a way to refactor that avoids confusion without needing to add type checking. I don't always succeed, but when I do the code is more elegant.
    - pmontra 10y ago
      Statically typed is my deal breaker. See how varied people are? :-)
  - ddebernardy 10y ago
    Can't speak for GP but for me the kicker was that you cannot get any guarantees on the mutability of an object, and the unexpected quirks that could result from it. Example: https://redmine.ruby-lang.org/issues/6037 https://redmine.ruby-lang.org/issues/6037 You can (must) be pragmatic, of course; and assume that all will go well. But under the hood, it means a great many objects get pointlessly allocated and reallocated - or not, sometimes, with hard to find bugs occurring when a gem author overoptimizes their code to avoid making a few object copies, and ends up mutating your object's properties without you realizing it. Things have improved since, with e.g. strings being frozen by default if you want them to be since a few versions ago. Even in this changelog, there's a least one point related to memory allocation that touches the performance consequences of needlessly allocating new objects. Back then, I found Obj-C (and Swift, maybe?) more conforting in this respect, with most things being immutable unless you explicitly requested the mutable version. And I liked ARC a lot. (I haven't programmed much in recent years, so can't say what I'd use today if I were neck deep into code. Probably Swift.) Another issue was that Ruby was then attracting a lot of end-users that had no formal software engineering skills. Which is fine for day to day tasks; not so much when they start distributing libraries. (Always vet your gems' authors and source code.) I still love Ruby, mind you. It's beautifully expressive and it's still my preferred language for non-trivial "glue" tasks.
    - timrogers 10y ago
      "Accidental" mutability in gems tends to cause pain - spotted this one in Rails, for example. https://github.com/rails/rails/pull/25735 https://github.com/rails/rails/pull/25735
- vlunkr 10y ago
  Maybe you were actually too young to know how good it really was. :P
  - hota_mazi 10y ago
    I'm very likely older than you are, so... no. It was very good at the time. Not so much today. We've learned a lot in language design and Ruby feels very antiquated (mostly because it's dynamically typed).
    - galfarragem 10y ago
      Try Crystal, her younger sister. Just as beautiful but more nerdy and fast thinking.
      - matt4077 10y ago
        Can we stop using women as a metaphor now? Especially if beauty is the first criterium and she's apparently just waiting to be "tried"? Thx
    - deleted 10y ago
      [deleted]
    - tinco 10y ago
      Which statically typed language do you feel offers the same level of developer comfort as Ruby? My favorite statically typed languages are Haskell, Rust and C# but I prefer Ruby over them whenever possible.
      - hota_mazi 10y ago
        > Which statically typed language do you feel offers the same level of developer comfort as Ruby? So far, Kotlin has hit that sweet spot for me.
    - hashkb 10y ago
      What have we learned? Does LISP feel antiquated to you as well? How about Java?
- GavinMcG 10y ago
  I appreciate that you were responding to the analogy the parent comment offered, but without concrete criticisms it comes across to me as a sort of haughtiness and an insult to those who haven't caught up or are too blind to have dumped Ruby by now. That seems especially out of place in a thread about a new version of the language.
- Archio 10y ago
  To me, Ruby feels like this ex-girlfiend I was completely infatuated with and eventually broke up with because I was too young to pay attention to the fact that her flaws were in all the right places instead of the ones that truly matter.
matt4077 10y ago
Soo, so true. Working with Tensorflow, python is unfortunately the only realistic option. I'm getting the hang of it, but I'd still love to use ruby for it – it's all just data wrangling, it doesn't even need to be fast, and ruby code is just beautiful (to my eyes, I know it's a matter of opinion). I've also only recently discovered the beauty that is rake. Especially for data pipelines it's a fantastic tool. Hit a bug? No need to rerun everything – it'll pick up at the exact step that failed. One of ten data files changed? It knows exactly what needs to be redone. Etc.
- mooreds 10y ago
  Make does the same thing, but boy is rake syntax nicer.
- MrBra 10y ago
  > python is unfortunately the only realistic option. https://medium.com/@Arafat./introducing-tensorflow-ruby-api-e77a477ff16e#.wzf4ozvsi https://medium.com/@Arafat./introducing-tensorflow-ruby-api-... https://github.com/somaticio/tensorflow.rb https://github.com/somaticio/tensorflow.rb

I still love you, Ruby. I wish we spent more time together.

by dollar 10y ago

I still love you, Ruby. I wish we spent more time together.

I was madly in love with Ruby in 2005 but now, Ruby feels like this ex girlfriend you were completely infatuated with and eventually broke up with because you were too young to pay attention to her flaws.

nstart 10y ago
Since I never picked up ruby (I joined Python and now I'm about to pick up ruby). Curious what made you move away and what you've moved to?
- hota_mazi 10y ago
  It's dynamically typed, which is a deal breaker for me today. I need not just a type system but one that supports parametric polymorphism, so definitely not Ruby, Python or even Go.
  - xapata 10y ago
    You can use traits instead. I know it's different, but it probably solves your problem.
    - hota_mazi 10y ago
      Traits are orthogonal to the dynamic/static question. My experience has taught me that not having type annotations in a source code makes it very hard to understand and maintain that source in the long run.
      - vidarh 10y ago
        Ruby is more than flexible enough for you to add type annotation via DSLs, and use them to drive tests/fuzzing if you want that. There are a lot of people who have done that. They rarely see much use, though, because most of us quickly experience that the type annotations that seem essential when we work on statically typed languages quickly become less essential once you adopt a more idiomatic Ruby style. E.g. if you want to output something as text, rather than dictate what should be passed in, call #to_s on it (and optionally handle the failure if it doesn't implement #to_s, if it is reasonable to continue). Once you adopt the attitude of asking for what you actualy need rather than demanding the client pass in what you think should be passed in, type annotations start feeling like a clamp around your foot rather than a necessity in most cases, and most of the remaining assistance they could provide tends to fall away with test cases you would require in either case. I used to be a static typing zealot, and I still want things to be "as static as possible", but I've come to accept that most of the time the burdens it adds are not worth the benefits. I'm sure we can do better, and there are certainly cases where optional static type annotation could be helpful, but at this point I'm not giving up the expressiveness dynamc typing gives me - a static system would need to be practically "invisible" for me to find it acceptable.
      - xapata 10y ago
        My experience has taught me that if static typing improves your code, it's probably hiding deeper flaws. I won't deny there are some clever things one can do to improve code with sophisticated typing. However, the typical usage is to alleviate the mistakes of bad names and poor design. When I find type errors at runtime, I look for a way to refactor that avoids confusion without needing to add type checking. I don't always succeed, but when I do the code is more elegant.
  - pmontra 10y ago
    Statically typed is my deal breaker. See how varied people are? :-)
- ddebernardy 10y ago
  Can't speak for GP but for me the kicker was that you cannot get any guarantees on the mutability of an object, and the unexpected quirks that could result from it. Example: https://redmine.ruby-lang.org/issues/6037 https://redmine.ruby-lang.org/issues/6037 You can (must) be pragmatic, of course; and assume that all will go well. But under the hood, it means a great many objects get pointlessly allocated and reallocated - or not, sometimes, with hard to find bugs occurring when a gem author overoptimizes their code to avoid making a few object copies, and ends up mutating your object's properties without you realizing it. Things have improved since, with e.g. strings being frozen by default if you want them to be since a few versions ago. Even in this changelog, there's a least one point related to memory allocation that touches the performance consequences of needlessly allocating new objects. Back then, I found Obj-C (and Swift, maybe?) more conforting in this respect, with most things being immutable unless you explicitly requested the mutable version. And I liked ARC a lot. (I haven't programmed much in recent years, so can't say what I'd use today if I were neck deep into code. Probably Swift.) Another issue was that Ruby was then attracting a lot of end-users that had no formal software engineering skills. Which is fine for day to day tasks; not so much when they start distributing libraries. (Always vet your gems' authors and source code.) I still love Ruby, mind you. It's beautifully expressive and it's still my preferred language for non-trivial "glue" tasks.
  - timrogers 10y ago
    "Accidental" mutability in gems tends to cause pain - spotted this one in Rails, for example. https://github.com/rails/rails/pull/25735 https://github.com/rails/rails/pull/25735
vlunkr 10y ago
Maybe you were actually too young to know how good it really was. :P
- hota_mazi 10y ago
  I'm very likely older than you are, so... no. It was very good at the time. Not so much today. We've learned a lot in language design and Ruby feels very antiquated (mostly because it's dynamically typed).
  - galfarragem 10y ago
    Try Crystal, her younger sister. Just as beautiful but more nerdy and fast thinking.
    - matt4077 10y ago
      Can we stop using women as a metaphor now? Especially if beauty is the first criterium and she's apparently just waiting to be "tried"? Thx
  - deleted 10y ago
    [deleted]
  - tinco 10y ago
    Which statically typed language do you feel offers the same level of developer comfort as Ruby? My favorite statically typed languages are Haskell, Rust and C# but I prefer Ruby over them whenever possible.
    - hota_mazi 10y ago
      > Which statically typed language do you feel offers the same level of developer comfort as Ruby? So far, Kotlin has hit that sweet spot for me.
  - hashkb 10y ago
    What have we learned? Does LISP feel antiquated to you as well? How about Java?
GavinMcG 10y ago
I appreciate that you were responding to the analogy the parent comment offered, but without concrete criticisms it comes across to me as a sort of haughtiness and an insult to those who haven't caught up or are too blind to have dumped Ruby by now. That seems especially out of place in a thread about a new version of the language.
Archio 10y ago
To me, Ruby feels like this ex-girlfiend I was completely infatuated with and eventually broke up with because I was too young to pay attention to the fact that her flaws were in all the right places instead of the ones that truly matter.

matt4077 10y ago

Soo, so true. Working with Tensorflow, python is unfortunately the only realistic option. I'm getting the hang of it, but I'd still love to use ruby for it – it's all just data wrangling, it doesn't even need to be fast, and ruby code is just beautiful (to my eyes, I know it's a matter of opinion). I've also only recently discovered the beauty that is rake. Especially for data pipelines it's a fantastic tool. Hit a bug? No need to rerun everything – it'll pick up at the exact step that failed. One of ten data files changed? It knows exactly what needs to be redone. Etc.

mooreds 10y ago
Make does the same thing, but boy is rake syntax nicer.
MrBra 10y ago
> python is unfortunately the only realistic option. https://medium.com/@Arafat./introducing-tensorflow-ruby-api-e77a477ff16e#.wzf4ozvsi https://medium.com/@Arafat./introducing-tensorflow-ruby-api-... https://github.com/somaticio/tensorflow.rb https://github.com/somaticio/tensorflow.rb