4 ms·

I don't get it either. Neither see the supposed (objective) "errors" in the language design. Why not have both raise/rescue and throw/catch when the used are d

by zkomp 9y ago

I don't get it either. Neither see the supposed (objective) "errors" in the language design. Why not have both raise/rescue and throw/catch when the used are different. And why not have both methods, functions and closures? It is for different things... Why read docs when you have irb and can pretty much inspect everything you need. All the comparisons with java... I hate it, much rather use ruby style OO than the horrible boilerplate hell that I remember from java. Problem with ruby is not that it is not java, it is imho sometimes it is too easy and forgiving - letting you do crazy things like unintentional meta programming, and not catching errors until runtime. Other problems with ruby is complexity and the lack of clear spec (lookup what happened to the rubinius ruby spec project).

zbentley 9y ago
Debuggers/inspectors are great, but they absolutely do not serve the same need as documentation, and any language/community that recommends the former in place of the latter should be considered suspect as to the quality, reusability, and extensibility of its creations. > Why read docs when you have irb and can pretty much inspect everything you need? Because irb is another tool I have to learn how to use if I'm new to a language. Even if I already know the tool, I have to learn how to get the inspector to my code in order to inspect it in irb. That can be quite hard if I want to inspect an object that gets described and constructed during the runtime of a big "harness" I don't control. How do I get the inspector to run precisely where I need it to? In most situations like this, the code I want to inspect is itself running in a new process, or on a different server, so "just drop a breakpoint in", while possible, is far from easy advice to follow. And all that is assuming that the inspector's output, when I get it, will be at all useful! What if the code I want to inspect is highly dynamic, and has different object "shapes" at runtime depending on subtle differences in inputs? That kind of code isn't obscure in ruby land--I've seen common situations where inspection is at best a waste of time and at worst actively deceptive in Puppet, ActiveRecord, and various RSpec-ish frameworks. That's not to say their code is bad; just that it's a really bad idea to assume that a inspector can double as a documentation authority. The alternative--textual documentation--is absolutely essential and cannot be replaced with a debugger/inspector. I already know how to read English (or doc-language-of-choice). To read documentation, I don't need to learn a new tool (designed for prototype testing and debugging; probably not the first concerns on my mind if I'm at the "check the documentation/API reference" phase of development), carefully construct a contrived runtime context to reach my code, extrapolate the output as intended for the runtime back into something human-intelligible, and then pray that what I found is the right output, or is in any way representative of what my code is going to actually encounter when it runs.
- rajangdavis 9y ago
  I agree about debuggers although I have not needed to use anything beyond the "inspect" method on a given object for what I use Ruby for. From what I can tell, Pry is supposed to be the debugger of choice when working with Ruby but I think that's in a Rails context. I haven't touched Rails in about 6 months but never used Pry for the 3 years that I have worked with Ruby on Rails. I think the documentation issue exists in any (dynamic) language; however, from what I can tell, statically typed languages have better support for this. The majority of libraries that I use with Ruby (Sinatra, Parallel) tend to have great documentation; however, it can be a mixed bag.

by zkomp 9y ago

zbentley 9y ago

Debuggers/inspectors are great, but they absolutely do not serve the same need as documentation, and any language/community that recommends the former in place of the latter should be considered suspect as to the quality, reusability, and extensibility of its creations. > Why read docs when you have irb and can pretty much inspect everything you need? Because irb is another tool I have to learn how to use if I'm new to a language. Even if I already know the tool, I have to learn how to get the inspector to my code in order to inspect it in irb. That can be quite hard if I want to inspect an object that gets described and constructed during the runtime of a big "harness" I don't control. How do I get the inspector to run precisely where I need it to? In most situations like this, the code I want to inspect is itself running in a new process, or on a different server, so "just drop a breakpoint in", while possible, is far from easy advice to follow. And all that is assuming that the inspector's output, when I get it, will be at all useful! What if the code I want to inspect is highly dynamic, and has different object "shapes" at runtime depending on subtle differences in inputs? That kind of code isn't obscure in ruby land--I've seen common situations where inspection is at best a waste of time and at worst actively deceptive in Puppet, ActiveRecord, and various RSpec-ish frameworks. That's not to say their code is bad; just that it's a really bad idea to assume that a inspector can double as a documentation authority. The alternative--textual documentation--is absolutely essential and cannot be replaced with a debugger/inspector. I already know how to read English (or doc-language-of-choice). To read documentation, I don't need to learn a new tool (designed for prototype testing and debugging; probably not the first concerns on my mind if I'm at the "check the documentation/API reference" phase of development), carefully construct a contrived runtime context to reach my code, extrapolate the output as intended for the runtime back into something human-intelligible, and then pray that what I found is the right output, or is in any way representative of what my code is going to actually encounter when it runs.

rajangdavis 9y ago
I agree about debuggers although I have not needed to use anything beyond the "inspect" method on a given object for what I use Ruby for. From what I can tell, Pry is supposed to be the debugger of choice when working with Ruby but I think that's in a Rails context. I haven't touched Rails in about 6 months but never used Pry for the 3 years that I have worked with Ruby on Rails. I think the documentation issue exists in any (dynamic) language; however, from what I can tell, statically typed languages have better support for this. The majority of libraries that I use with Ruby (Sinatra, Parallel) tend to have great documentation; however, it can be a mixed bag.