“The most annoying bug I ever have is tracking an errant “end”.”
I too often complain about missing end’s.
But I was one of those coders that, in PHP, often forgot a ‘;’
I cant tell you how happy I am with ruby. No more need for ‘;’
About the missing end’s, over time I kinda developed a habit of
knowing where I made an error and can fix it up quickly.
It is not really that problematic for me. HOWEVER, I would actually
not mind some magical per-file way to omit end’s based on
indent. :>
From: “Dumaiu” [email protected]
Perhaps I should avoid buzzwords. I admit that, having never
actually looked ‘optimization’ up, I may define it more loosely than
you.
For what it’s worth, I’d suggest that the phrase “premature
optimization” may be more akin to canon, than buzzword, and
tends to mean something very specific.
(By canon, I mean, “the body of rules, principles, or standards
accepted as axiomatic and universally binding in a field of study
or art.”)
For completeness sake, the original appearance of the phrase in
publication:
“We should forget about small efficiencies, say about 97% of
the time: premature optimization is the root of all evil.”
(Knuth, Donald. Structured Programming with go to Statements,
ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)
((Knuth is said to have been parahprasing C.A.R. Hoare))
I didn’t mean optimization for performance but for elegance. Ça
ne se dit pas? The purpose of refactoring is to improve code by
increasing elegance, unless I seriously misunderstand. My own
tendency is to overthink it and try to reevaluate a design after every
single change. I think this is another case where balance is best.
If you have achieved such a balance with your “cycles,”
congratulations. I apologize if I offended you.
I think I was actually offended. But it was obviously
based on a misunderstanding.
I don’t think I’ve achieved ideal balance yet… I’m usually
coming at it from the other direction: skipping a few refactorings
until I realize some part of the code is really bothering me, then
having to make time for a larger cleanup. But hopefully I’m
improving.
Regards,
Bill
2007/12/10, Marc H. [email protected]:
not mind some magical per-file way to omit end’s based on
indent. :>
There are actually at least two measures that help preventing this: 1.
use an editor with proper syntax indentation and highlighting. 2.
Exercise the habit to enter matching pairs always together before you
enter the content (some editors will actually help with this as well
because they can enter the matching closing element when you enter the
opening element).
Kind regards
robert
On Dec 8, 6:51 pm, “Just Another Victim of the Ambient M.”
[email protected] wrote:
The two most popular sources of bugs for me when programming in Rubyare:
- Passing the wrong object as a parameter to a method.
- Accidentally creating a new variable.
1.) How does predeclaration help?
var l = [1,2,3]
var h = {:a=>“b”}
wants_an_array(h) # => error
2.) While that may alleviate the typo problem, it introduces another
class of bugs which are just as subtle:
var list = create_useful_list
if should_modify_list(list)
# I meant to modify the variable “list” here…
var list = modify_list(list)
end
use_list(list)
Once one became accustomed to typing “var”, there is every chance that
it would be used places where a pre-existing variable was meant, but
the “var” just got typed out of habit.
Regards,
Jordan
“James B.” [email protected] wrote in message
news:[email protected]…
How are you testing your code?
The usual way: by running it?
On Dec 10, 2007 12:10 PM, MonkeeSage [email protected] wrote:
Once one became accustomed to typing “var”, there is every chance that
it would be used places where a pre-existing variable was meant, but
the “var” just got typed out of habit.
This happens to me in perl, possibly about as often as the typo
problem in Ruby, possibly more. I’ll note that I have a habit
intended to avoid typo problems: I fairly consistently use Vim’s
“Ctrl-N” (complete based on string search in other parts of code),
even for short strings, just to avoid typos.
Eivind.
“Trans” [email protected] wrote in message
news:[email protected]…
are:
raise ArgumentError unless b.is_a?(Bar)
raise ArgumentError unless c.is_a?(Baz)or whatever
end
This is interesting but kind of overkill. Checking for a contract
is a
non-trivial, especially if you want to keep duck-typing. This would
increase programmer effort so much that it would become comparable to
programming in C, I think…
clarify my point. I so amazingly meant to assign to the pre-existing
Why do you have troubles like this? How big are your methods? Keep
them small and this, I think, would be very rare.
They're not that big. Having said that, it's often hard to keep a
method definition too small 'cause, well, sometimes there’s a lot to do!
Sometimes there’s a lot to do that’s inherently related and splitting
that
up would serve no logical purpose other than to keep the method
definition
small. Finally, I’ve actually worked with entire programs where no
function
body was more than six lines of code. It wasn’t understandable nor easy
to
work with. It was extremely difficult to tell what any function did and
it
was difficult to modify code to do something else. I don’t think
artificially keeping method definitions small necessarily solves
anything…
The most annoying bug I ever have is tracking an errant “end”.
I've had this problem, before, but luckily it's quite rare for me.
Perhaps it’s because I’ve gotten into the habit of typing out my loop
bounds
before filling in the loop body. I’ve always considered this a bad
habit of
mine but perhaps it’s not so bad…
“Dumaiu” [email protected] wrote in message
news:[email protected]…
The two most popular sources of bugs for me when programming in Rubyare:
- Passing the wrong object as a parameter to a method.
- Accidentally creating a new variable.
Seriously, as someone prone to lack of concentration, I agree. A
great many programmers have concluded, probably from painful
experience, that typed variables reduce error. Also I think that
building error-testing into the code will scale better than reliance
only on unit testing.
I actually don't think this is the case. Statically typed languages
didn’t come from long experience with bugs, it was just happenstance…
If I’m not mistaken, typed variables came from a world where
compiled
programming languages failed to completely shield the user from the
hardware. Back then, you had to declare variables so that the compiler
can
know to allocate them from static store when creating the executable
image.
Later on, when functions became more popular, they also had to do this
for
the stack. A lot of C syntax comes from how close it is to assembly
language…
“Robert K.” [email protected] wrote in message
news:[email protected]…
Bottom line: if you want a safer language with typed and declared
variables use one. This is such a fundamental change to the language that
it does not fit in very well. I also suggest to keep methods short. This
will help improve structure of the code and avoid all sorts of other bugs
as well.
Typed variables would be a huge change to Ruby but I disagree that
declaration would be. It’s a small, simple change and a feature that
many
languages have, including other dynamically typed languages and Ruby’s
precurser (if one can call it that). It’s a little against Ruby culture
but
it’s not hard to implement nor would it change the language much…
“Todd B.” [email protected] wrote in message
news:[email protected]…
To be fair, it has to be said that it is less of a problem inlanguages that require variables to be declared or typed.
Hmm. Maybe, but I kind of doubt it. var temp is no more or less
succinct than anything else. It doesn’t guarantee you “safeness”.
Safeness is what databases are for. Pre-declaration is sort of an
empty promise in flow-control.
You're really not thinking this through.
How on God's green Earth are you going to accidentally prepend an
extraneous "var " (or whatever keyword is decided upon) to a variable’s
assignment. Because this is highly unlikely, the described problem will
only happen if you accidentally want to declare a new variable. This is
rather distinct from wanting to use a variable and so the bug should
occur
far less frequently…
Hi, to respond briefly towards
“There are actually at least two measures that help preventing this: 1.
use an editor with proper syntax indentation and highlighting.”
[…]
"2. Exercise the habit to enter matching pairs always together before you
enter the content
What makes you believe I do not already? 
But editor aside, there is a huge difference in visually appealing
on something. The greatest IDE can make Java [*1] look great, folding
away
all the ugly bits, but under the hood it still remains ugly and
needlessly
verbose. Your brain adapts to the ugliness and blends away the
yucky parts, but the ugliness is still there, and the great
editor just conceals it, like a veil.
In this regard, I do find no “end” visually more appealing to
my eyes than an existing “end”. Or multiple ones, if one chose
to rely on heavy if-else branching.
It is not without reason that people prefer python or ruby these
days compared to perl. Years ago perl had no real competition,
it was still used heavily (and still is), but was it visually
really appealing? I think I wrote only about 100 .pl scripts,
compared to around 2000 .rb files so far.
I never had the impression that perl bothered at all about
visual elegance.
It is not a question of habit. Habit changes over time, you
adapt anyway. You have to use “workarounds” everywhere
too and can use your editor to easen up the workload.
It is a question of beauty and elegance.
This is a more general remark, don’t think I am focusing
only on ‘end’ - ‘end’ is not that important anyway
[*1] Replace Java with another language as you see fit.
I could mention (((lisp))) but I am afraid i would get
(burned) …
On Dec 10, 5:57 pm, Jay L. [email protected] wrote:
var destination
Boy, I know that if I were implementing this ‘var’ stuff, I would
make that illegal too!
var firsst_name
...And that wouldn't get written at all...
Hey, no error, no overlap!
...and the real issue would be how to handle the naming of block
parms, which I don’t think has been brought up yet.
Ruby already has a way (several ways, actually!) for all these errors to be
announced on the “first pass”. Test::Unit, RSpec, etc.
I can get back to you once I've tried RSpec.
-Jonathan
On Dec 10, 7:33 am, Eivind E. [email protected] wrote:
use_list(list)
Eivind.
Thank you. That's a good suggestion.
-J
Marc H. wrote:
About the missing end’s, over time I kinda developed a habit of
knowing where I made an error and can fix it up quickly.
It is not really that problematic for me. HOWEVER, I would actually
not mind some magical per-file way to omit end’s based on
indent. :>
I disagree, If you indent your code in the first place I find the
missing 'end’s pretty easy to pick up. If you indent 2 spaces, pass a
block, backspace 2 and there is your end. I know it wouldn’t be that
easy on larger applications, but the same idea still stands IMO. This
isn’t Python.
- Passing the wrong object as a parameter to a method.
So why not spend a couple of lines testing the object first?
- Accidentally creating a new variable.
This can happen a lot no matter what language you code, I don’t think
setting up the equivilant to Perls ‘strict’ would be the way to go, in
my opinion. But hey, I’m nothing but a humble Ruby programmer. 
Regards,
Lee
The two most popular sources of bugs for me when programming in Rubyare:
- Passing the wrong object as a parameter to a method.
- Accidentally creating a new variable.
I agree with number 1. I like duck typing and respect it, but I have
seriously thought of suggesting ‘voluntary’ type checks to Ruby before,
since it is a very common problem to pass a String instead of an
Integer.
I would have except I thought I might be bludgeoned by the community or
something. I still would use something like
def func_1(a ==> String, b ==> Fixnum)
end
if I had it. If only to ensure expected use at the beginning of coding
creation.
-Roger
“MonkeeSage” [email protected] wrote in message
news:[email protected]…
var l = [1,2,3]
var h = {:a=>“b”}
wants_an_array(h) # => error
It wouldn't help at all and no one claimed that it would. Did you
read
my post?
Once one became accustomed to typing “var”, there is every chance that
it would be used places where a pre-existing variable was meant, but
the “var” just got typed out of habit.
You don't really believe this, do you? Do you program in C/C++ at
all?
Do you find yourself accidentally typing “int” when using a variable or
function in that language?
Just because you need this keyword for declaring variables doesn’t
mean
you’re going to get so used to typing it that you’ll accidentally type
it
out all the time. That’s just silly…
On Dec 10, 11:38 am, “Just Another Victim of the Ambient M.”
[email protected] wrote:
- Passing the wrong object as a parameter to a method.
Once one became accustomed to typing “var”, there is every chance that
it would be used places where a pre-existing variable was meant, but
the “var” just got typed out of habit.You don't really believe this, do you? Do you program in C/C++ at all?Do you find yourself accidentally typing “int” when using a variable or
function in that language?
Just because you need this keyword for declaring variables doesn’t mean
you’re going to get so used to typing it that you’ll accidentally type it
out all the time. That’s just silly…
I don't really think it's equitable to liken Perl, where all you
do is use ‘my’, ‘my’, ‘my’, to C++, where the typing forces you to
really think about what you’re instantiating. There is more room for
error in Perl.
On Dec 10, 8:18 pm, Marc H. [email protected] wrote:
[*1] Replace Java with another language as you see fit.
I could mention (((lisp))) but I am afraid i would get
(burned) …
...or receive the "death of a thousand 'cdr's." Can't resist.
-J
On Mon, 10 Dec 2007 16:38:18 GMT, Just Another Victim of the Ambient
Morality wrote:
It wouldn't help at all and no one claimed that it would. Did you readmy post?
[…]
You don’t really believe this, do you? Do you program in C/C++ at all?
[…]
That’s just silly…
Tip: When proposing a fundamental, controversial, philosophy-shaking
change
to the very people who would be making such a change, you’re going to
want
to sound nicer.
On Dec 9, 11:17 pm, Bill K. [email protected] wrote:
tends to mean something very specific.
congratulations. I apologize if I offended you.
Regards,Bill
I’ve had a chance to think some more. First, is the word ‘canon’
canonical? I mean, do I have to use it? I’ve not encountered a field
outisde of computer science or the Roman Catholic Church in which
standards would be described as canon, even if they were ‘universally
binding,’ which they aren’t. It makes me feel like we ought to be
arguing about Star Wars or something.
But on a more serious note: I am bemused by the discovery that I
still cannot convince myself of any fundamental distinction of intent
between what we call the processes of optimization and of refactoring,
despite the great differences in procedure by which they are
undertaken. I earlier made the error of trying to see the issue in
terms of performance v. “good design,” you could say, but it’s really
more like a radial tug-of-war between many competing priorities.
After all, even when optimizing purely to decrease the load on the
computer, you still have to choose which part of the computer needs
the most attention. By comparison, you refactor code to decrease the
load on at least one, but never all, of the human “parts” of the
software project. And it’s blurred further within the domain of
dynamic languages. Even if you think only of maintainability, i.e.,
the human element, tradeoffs must still be made: the more you separate
interface from implementation, the uglier the implementation is going
to get.
Is that a contentious statement? I’m spinning this out as I go. Let
me know know what you think.
-Jonathan
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs