Are there real tangible benefits that non-declared, dynamically typed
(at binding time) variables provide? Or do dynamic variables simply
create less compile time errors and more (harder to catch) runtime
errors?
Every language feature that reduces how much typing I have to do is a
tangible benefit to me. It eases stress on my body machine, and speeds
the delivery of my code.
The only downside I can think of is that typos may not be caught for
instance/class variables as readily:
class Foo
def bar @somethingDelicious = 12
end
def whee
print( @sonethingDeIicious )
end
end
If you personally find that you are having trouble in this arena, I
suspect that it wouldn’t be hard to write a code analyzer that alerted
on potential misspellings. I’ve personally not needed it.
The only downside I can think of is that typos may not be caught for
If you personally find that you are having trouble in this arena, I
suspect that it wouldn’t be hard to write a code analyzer that alerted
on potential misspellings. I’ve personally not needed it.
for those of you using vim, the completion feature virtually eliminates
this
kind of bug. for instance, i can type @som, then hit ‘ctrl-n’, and @somethingDelicious simply appears. this is a huge bug stopper for me,
because i reely cant spel.
Every language feature that reduces how much typing I have to do is a
tangible benefit to me. It eases stress on my body machine, and speeds
the delivery of my code.
That seems a ridiculous thing to say to me. Time taken to type out
code is not the limiting factor in your productivity.
If you sacrifice readability, maintainibility, safety, extensibility
or supportibility for a fewer characters, it’s hardly a worthwhile
tradeoff.
Terseness is not a virtue. If it were, I’d be a perl programmer.
tangible benefit to me. It eases stress on my body machine, and
def whee
eliminates this
kind of bug. for instance, i can type @som, then hit ‘ctrl-n’, and @somethingDelicious simply appears. this is a huge bug stopper for
me,
because i reely cant spel.
In TextMate this is done with the escape key and I couldn’t agree
more about it being an excellent habit to get into.
If you personally find that you are having trouble in this arena, I
suspect that it wouldn’t be hard to write a code analyzer that alerted
on potential misspellings.
Here’s a simple example I just came up with. (If this were to be taken
a little further, it should probably report line numbers. If it were to
be taken a lot further, it should probably use actual parsing of Ruby
code to determine class scope for variables, leave out things that look
like variables inside strings/regexp/comments, etc.)
require ‘typochecker’
class Foo
def foo
@@name = ‘boot’ @name = ‘wow’ @somethingDelicious = 12
end
def whee
print( @mane, @@names )
print( @somethingDelicions )
end
end
#=> Possible typo: @@name versus @@names
#=> Possible typo: @name versus @mane
#=> Possible typo: @somethingDelicious versus @somethingDelicions
it even uses getoptlong to reduce the busywork. in ruby it’s about 40
lines.
it’s been proven (many times - google it) that programmers write the
about the
same number of lines of code per day regardless of the language, be it
assembler or ruby. so, given that it might take be something like 30
minutes
to produce a 40 line option parser in ruby, we can interpolate that the
equivalent c parser would take about two and half days to produce.
that’s
quite expensive if you ask me, espcially considering that there is no
good
reason (speed for example) to parse options in c.
it’s not the actual typing of the lines that takes so long - it’s
reasoning
over it. without even seeing the code i’m sure you’ll have no trouble
believing that the ruby opt parser takes seconds to comprehend, while
the c
one takes considerably longer - simply based on it’s size.
and this point isn’t even considering security faults, which have been
shown
to scale linearly with tloc.
-a
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.