4 ms·

Good article that raises interesting points. I would also be interested in knowing what happens to experienced programmers using Rails - do they simply become u

by param 17y ago

Good article that raises interesting points. I would also be interested in knowing what happens to experienced programmers using Rails - do they simply become used to the poor error messages (so this is just a ramp-up problem) or are you always stuck with making sure everything is without typos etc?

tptacek 17y ago
Without conceding that these are poor error messages --- most of them are pretty direct, and the one that confused him the most actually gave him a step-by-step for diagnosing the problem --- I do think that addressing this post point-by-point would be another opportunity for Rails to charm web developers. Note that very, very few software development frameworks "gracefully" handle the typo problem.
- jbellis 17y ago
  It's worse in Ruby though, because the "use maps for optional parameters" approach means you have to manually check for invalid keys in the map, whereas the same approach in a language that supports native named parameters would throw an exception about the invalid parameter. Several of the errors in this article would be caught by this.
  - grandalf 17y ago
    True, but Ruby also allows for the Rails DSL to be fairly concise. If you assume a constant number of typos per typed word, the author would have made more errors in a more verbose language even if it had named params :)
    - deleted 17y ago
      [deleted]
  - jeremymcanally 17y ago
    Rails does this many places already. It seems he probably just stumbled into one of the few cases where the flexibility is needed and therefore the parameters aren't easily checkable.
- pvg 17y ago
  They strike me as fairly poor, while not catastrophically so. The fact that such messages are typical doesn't make them not-poor. They're not, though, something constrained to Rails and I'm not sure a Rails-specific rebuttal would help all that much - the difficulty is fundamental when the language and abstractions of expression are different from and essentially unknown to the system that's actually doing the runtime error checking. Another commenter spoke of the infamous JSP stack traces. Googling 'clojure error messages' brought up a thread on this as an error message: (ns foo.bar.baz (use clojure.contrib.core :only seqable?)) #<CompilerException java.lang.IllegalArgumentException: Don't know how to create ISeq from: Boolean (NO_SOURCE_FILE:0)>

by param 17y ago

tptacek 17y ago

Without conceding that these are poor error messages --- most of them are pretty direct, and the one that confused him the most actually gave him a step-by-step for diagnosing the problem --- I do think that addressing this post point-by-point would be another opportunity for Rails to charm web developers. Note that very, very few software development frameworks "gracefully" handle the typo problem.

jbellis 17y ago
It's worse in Ruby though, because the "use maps for optional parameters" approach means you have to manually check for invalid keys in the map, whereas the same approach in a language that supports native named parameters would throw an exception about the invalid parameter. Several of the errors in this article would be caught by this.
- grandalf 17y ago
  True, but Ruby also allows for the Rails DSL to be fairly concise. If you assume a constant number of typos per typed word, the author would have made more errors in a more verbose language even if it had named params :)
  - deleted 17y ago
    [deleted]
- jeremymcanally 17y ago
  Rails does this many places already. It seems he probably just stumbled into one of the few cases where the flexibility is needed and therefore the parameters aren't easily checkable.
pvg 17y ago
They strike me as fairly poor, while not catastrophically so. The fact that such messages are typical doesn't make them not-poor. They're not, though, something constrained to Rails and I'm not sure a Rails-specific rebuttal would help all that much - the difficulty is fundamental when the language and abstractions of expression are different from and essentially unknown to the system that's actually doing the runtime error checking. Another commenter spoke of the infamous JSP stack traces. Googling 'clojure error messages' brought up a thread on this as an error message: (ns foo.bar.baz (use clojure.contrib.core :only seqable?)) #<CompilerException java.lang.IllegalArgumentException: Don't know how to create ISeq from: Boolean (NO_SOURCE_FILE:0)>