4 ms·

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?

by nstart 10y ago

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

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?

by 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