5 ms·

I tend to think that the sophistication of the tools reflect the extent that the language is broken. Valgrind doesn't need to exist for the Java user. You don't

I tend to think that the sophistication of the tools reflect the extent that the language is broken. Valgrind doesn't need to exist for the Java user. You don't need class boilerplate getter/setter generators for Scala. Nobody needs NPE static analyzers for Rust. The need for rename refactoring tools is drastically diminished by the existence of type inference, almost to the point where `:%s/Foo/Bar/g` is entirely adequate. The non-existence of tools that you find in other languages might signal an immature ecosystem, but it might also signal a diminished need for them.

rictic 11y ago
It's been a while since I wrote much Ruby, but I can vividly recall wanting to find the definition of a method and being frustrated at how difficult it often was.
- dragonwriter 11y ago
  > It's been a while since I wrote much Ruby, but I can vividly recall wanting to find the definition of a method and being frustrated at how difficult it often was. Given Ruby's open classes and per-object metaclasses (which are still open), I'm pretty sure a general solution to "find the definition of the method being called at this point in the code" is impossible (and not just, "there is a single correct answer, no general solution is available" impossible, but "there is no guarantee that there is a single correct answer, and even for the subset of cases where there is, no general solution is available" possible.)
  - pjmlp 11y ago
    Ever used Smalltalk, Dylan or Common Lisp commercial tools?
    - hire_charts 11y ago
      Personally, I haven't -- is there a way that the benefits of these tools could be translated into a ruby-based environment? Are such solutions already available? Would be interested to know more.
      - pjmlp 11y ago
        Then this might interest you: http://devblog.avdi.org/2015/05/11/in-which-i-make-you-hate-ruby-in-7-minutes/ http://devblog.avdi.org/2015/05/11/in-which-i-make-you-hate-...
    - dragonwriter 11y ago
      No, nor have I missed the particular function described working with Ruby. But, OTOH, I am aware that its possible to do good-enough-for-many-uses implementations of things for which a complete, general solution is impossible, including the function described.
  - vidarh 11y ago
    Ahead of time, it can be impossible, but usually is quite trivial. But finding the set of likely candidates is not that hard. There are some pathological code-bases that dynamically defines lots of methods, but they are not that common.
- hire_charts 11y ago
  This is definitely the downside of ruby's dynamic/duck typing. On the flip side, the limitations of ruby forces its devs to adjust the way they write code. Knowing that I may need to use ⌘-shift-f (find in project) to look up method definitions changes some of my conventions, and because operations like refactor-rename (which I use all the time in C#) are very tedious, it forces me to think a bit harder up front when designing a class's API surface. I'm not arguing that it's better than having good tooling -- just that the lack of tooling adds some interesting constraints that, in some ways, force us to write simpler code.
  - pmontra 11y ago
    I dare to say that most Ruby code is written in Rails projects and we almost always know were a method is defined, because of conventions (models, views, lib, concerns). It's when the developer is too smart that we get into troubles. The only project where I needed ctags in the last years was a php zend application that I had to get familiar with to be able to design its v2. So it might be another issue with Rails' influence over Ruby: not many chances to move beyond the fence (me too.)
  - PuercoPop 11y ago
    > This is definitely the downside of ruby's dynamic/duck typing. No, IDEs were pioneered (and if you checkout Pharo you'll see they are still pushing the boundaries) by dynamic languages that allow runtime refleciton. Like smalltalk.
    - hire_charts 11y ago
      Just because some IDEs push the boundary when it comes to dynamic languages doesn't mean it still isn't a downside. By that I mean, on other languages it's not even a problem you have to solve. The solutions to 'go to definition' or 'rename all references' are trivial in languages like the C-variants.
      - PuercoPop 11y ago
        You are replying as if had I addressed your other statement. I pointed out that the general tooling woes is not due to its dynamic typing by providing a counter example. As for your other statement I also disagree: > I'm not arguing that it's better than having good tooling -- just that the lack of tooling adds some interesting constraints that, in some ways, force us to write simpler code. What lack of tooling (and introspection in general) deprive us from is from forming a clear picture of what is going on, perspective. To illustrate my point I'll quote a Ken Pitman's annecdote: > Last night on my Lisp Machine I was frustrated by the absence of NT file support. I had no idea how file support was implemented, but I had a general working understanding of how the Lisp Machine was organized, and within a small number of hours I had learned about how to extend the operating system to talk to NT over TCP and implemented a new set of classes so that I could transparently talk to my NT box over my local ethernet. A lot of my ability to do this was enabled by the ability to point and click on objects in order to debug them and inspect them without any fear or confusion about whether I was using the right sources, the right packages, etc. https://groups.google.com/forum/#!topic/comp.lang.lisp/XpvUwF2xKbk%5B101-125%5D https://groups.google.com/forum/#!topic/comp.lang.lisp/XpvUw... However I think this is a more nuanced point, therefore I have no interest in arguing it over the internet. I see the case for constraints resulting in simpler code. What I objected to is using Ruby's dynamic typing as a cop-out and try to pass it as trade-off.
spacemanmatt 11y ago
I agree about diminished need, but I think the article was addressing quality not quantity. Coverage is what matters, and that's a joint effect of the language+tools.
jasim 11y ago
Or as Avdi has rightly pointed out, it means that the language is not conducive for tooling. Tools have to operate on the static representation of code, and the more it diverges from runtime reality, the harder it becomes to understand the codebase structurally. The extreme opposite of all this would be Kotlin, which was built from the ground-up to have first-class IDE support.
- saosebastiao 11y ago
  In retrospect my statement may have come off as a claim to an absolute truth, but I didn't mean it that way. It is entirely possible for Ruby to be in a sweet spot of needing better tools but the language doesn't facilitate their existence. I just was explaining how a lack of tooling isn't necessarily (or even commonly) a bad thing.
  - catnaroek 11y ago
    Sweet or bitter?
mateuszf 11y ago
Do you know Clojure? I'm curious of what do you think about Clojure error stacktraces. Even though the languages seems to be designed very well - one thing that is underwhelming is how hard understanding errors may be for Clojure beginners.
catnaroek 11y ago
You're confusing "sophisticated" with "annoying or difficult to use". Boilerplate generators are annoying, and Valgrind is difficult to use, but they're unrefined: they solve problems that are best avoided than solved. A better measure of sophistication is how much bang you get for the buck, and how much of this bang is made possible by the language itself. In my opinion, the best example of this is GHCi: Using GHCi almost feels like asking the computer "Is what I'm doing right?". GHCi itself is made possible by Haskell's excellent balance between type system expressiveness and making inference feasible. To see why maximizing raw expressive power won't help, in most dependently typed languages, it's hard to construct nontrivial meaningful utterances, so you don't even get to the point where you can ask "Is what I'm doing right?" - the type checker will tell you "It isn't even wrong". That being said, I'm aware that the situation w.r.t. tooling is improving a lot. Another example is Rust's borrow checker: It will tell you exactly at which point an equivalent C or C++ program would have had a dangling pointer. It doesn't quite have the same "fluid conversation" feel as using GHCi, but it saves the enormous amount of time that would've been otherwise spent chasing memory bugs in a debugger, especially in a concurrent program. Ruby isn't defined by poor tools. Ruby is defined by a design that makes static analysis intractable. The lack of sophisticated tools is just a corollary.

rictic 11y ago

It's been a while since I wrote much Ruby, but I can vividly recall wanting to find the definition of a method and being frustrated at how difficult it often was.

dragonwriter 11y ago
> It's been a while since I wrote much Ruby, but I can vividly recall wanting to find the definition of a method and being frustrated at how difficult it often was. Given Ruby's open classes and per-object metaclasses (which are still open), I'm pretty sure a general solution to "find the definition of the method being called at this point in the code" is impossible (and not just, "there is a single correct answer, no general solution is available" impossible, but "there is no guarantee that there is a single correct answer, and even for the subset of cases where there is, no general solution is available" possible.)
- pjmlp 11y ago
  Ever used Smalltalk, Dylan or Common Lisp commercial tools?
  - hire_charts 11y ago
    Personally, I haven't -- is there a way that the benefits of these tools could be translated into a ruby-based environment? Are such solutions already available? Would be interested to know more.
    - pjmlp 11y ago
      Then this might interest you: http://devblog.avdi.org/2015/05/11/in-which-i-make-you-hate-ruby-in-7-minutes/ http://devblog.avdi.org/2015/05/11/in-which-i-make-you-hate-...
  - dragonwriter 11y ago
    No, nor have I missed the particular function described working with Ruby. But, OTOH, I am aware that its possible to do good-enough-for-many-uses implementations of things for which a complete, general solution is impossible, including the function described.
- vidarh 11y ago
  Ahead of time, it can be impossible, but usually is quite trivial. But finding the set of likely candidates is not that hard. There are some pathological code-bases that dynamically defines lots of methods, but they are not that common.
hire_charts 11y ago
This is definitely the downside of ruby's dynamic/duck typing. On the flip side, the limitations of ruby forces its devs to adjust the way they write code. Knowing that I may need to use ⌘-shift-f (find in project) to look up method definitions changes some of my conventions, and because operations like refactor-rename (which I use all the time in C#) are very tedious, it forces me to think a bit harder up front when designing a class's API surface. I'm not arguing that it's better than having good tooling -- just that the lack of tooling adds some interesting constraints that, in some ways, force us to write simpler code.
- pmontra 11y ago
  I dare to say that most Ruby code is written in Rails projects and we almost always know were a method is defined, because of conventions (models, views, lib, concerns). It's when the developer is too smart that we get into troubles. The only project where I needed ctags in the last years was a php zend application that I had to get familiar with to be able to design its v2. So it might be another issue with Rails' influence over Ruby: not many chances to move beyond the fence (me too.)
- PuercoPop 11y ago
  > This is definitely the downside of ruby's dynamic/duck typing. No, IDEs were pioneered (and if you checkout Pharo you'll see they are still pushing the boundaries) by dynamic languages that allow runtime refleciton. Like smalltalk.
  - hire_charts 11y ago
    Just because some IDEs push the boundary when it comes to dynamic languages doesn't mean it still isn't a downside. By that I mean, on other languages it's not even a problem you have to solve. The solutions to 'go to definition' or 'rename all references' are trivial in languages like the C-variants.
    - PuercoPop 11y ago
      You are replying as if had I addressed your other statement. I pointed out that the general tooling woes is not due to its dynamic typing by providing a counter example. As for your other statement I also disagree: > I'm not arguing that it's better than having good tooling -- just that the lack of tooling adds some interesting constraints that, in some ways, force us to write simpler code. What lack of tooling (and introspection in general) deprive us from is from forming a clear picture of what is going on, perspective. To illustrate my point I'll quote a Ken Pitman's annecdote: > Last night on my Lisp Machine I was frustrated by the absence of NT file support. I had no idea how file support was implemented, but I had a general working understanding of how the Lisp Machine was organized, and within a small number of hours I had learned about how to extend the operating system to talk to NT over TCP and implemented a new set of classes so that I could transparently talk to my NT box over my local ethernet. A lot of my ability to do this was enabled by the ability to point and click on objects in order to debug them and inspect them without any fear or confusion about whether I was using the right sources, the right packages, etc. https://groups.google.com/forum/#!topic/comp.lang.lisp/XpvUwF2xKbk%5B101-125%5D https://groups.google.com/forum/#!topic/comp.lang.lisp/XpvUw... However I think this is a more nuanced point, therefore I have no interest in arguing it over the internet. I see the case for constraints resulting in simpler code. What I objected to is using Ruby's dynamic typing as a cop-out and try to pass it as trade-off.

spacemanmatt 11y ago

I agree about diminished need, but I think the article was addressing quality not quantity. Coverage is what matters, and that's a joint effect of the language+tools.

jasim 11y ago

Or as Avdi has rightly pointed out, it means that the language is not conducive for tooling. Tools have to operate on the static representation of code, and the more it diverges from runtime reality, the harder it becomes to understand the codebase structurally. The extreme opposite of all this would be Kotlin, which was built from the ground-up to have first-class IDE support.

saosebastiao 11y ago
In retrospect my statement may have come off as a claim to an absolute truth, but I didn't mean it that way. It is entirely possible for Ruby to be in a sweet spot of needing better tools but the language doesn't facilitate their existence. I just was explaining how a lack of tooling isn't necessarily (or even commonly) a bad thing.
- catnaroek 11y ago
  Sweet or bitter?

mateuszf 11y ago

Do you know Clojure? I'm curious of what do you think about Clojure error stacktraces. Even though the languages seems to be designed very well - one thing that is underwhelming is how hard understanding errors may be for Clojure beginners.

catnaroek 11y ago

You're confusing "sophisticated" with "annoying or difficult to use". Boilerplate generators are annoying, and Valgrind is difficult to use, but they're unrefined: they solve problems that are best avoided than solved. A better measure of sophistication is how much bang you get for the buck, and how much of this bang is made possible by the language itself. In my opinion, the best example of this is GHCi: Using GHCi almost feels like asking the computer "Is what I'm doing right?". GHCi itself is made possible by Haskell's excellent balance between type system expressiveness and making inference feasible. To see why maximizing raw expressive power won't help, in most dependently typed languages, it's hard to construct nontrivial meaningful utterances, so you don't even get to the point where you can ask "Is what I'm doing right?" - the type checker will tell you "It isn't even wrong". That being said, I'm aware that the situation w.r.t. tooling is improving a lot. Another example is Rust's borrow checker: It will tell you exactly at which point an equivalent C or C++ program would have had a dangling pointer. It doesn't quite have the same "fluid conversation" feel as using GHCi, but it saves the enormous amount of time that would've been otherwise spent chasing memory bugs in a debugger, especially in a concurrent program. Ruby isn't defined by poor tools. Ruby is defined by a design that makes static analysis intractable. The lack of sophisticated tools is just a corollary.