On 9/2/06, Joel VanderWerf [email protected] wrote:
Going further OT, but you can omit the “true”:
result = case
when a == b: 0
when a < b : 1
when a > b : -1
end
Why does this work?
martin
[email protected] wrote:
Some time in the past, I wrote a line of code.
It looked like this:
if pu : pu = pu.url.to_s != ‘’ ? pu : nil end
I wasn’t even aware that you can use “:” instead of “then”…
Is this equivalent to your code?
pu = nil if pu && pu.url.to_s == ‘’
I find it still pretty concise and much easier to read.
Sure, it’s concise, but what did I gain by making it so concise over
making it so that it was clearly readable a year and a half later?Not much.
Was there any gain at all?
Sometimes clever is good, when there is a reason for it. However, that
time, clever was just plain stupid.
Right.
Kind regards
robertM. Edward (Ed) Borasky wrote:
There are tools and programming styles that can make C programming as
easy as programming in a dynamic language like Ruby or Perl or Python.
And the whining about the edit/compile/link/test cycle being less
efficient than the edit/test cycle of a dynamic language I think is just
that – whining. If your complex application is properly modularized,
that’s just not a big deal.
No, not just whining.
There’s so much to know about any programming language and tool chain,
that we are understandably ignorant of other languages and tools.
However in these Google days it’s harder to understand why we would
continue to assume that the only tools available for C are
compilers/linkers… Searching on c interpreter should be enough to
find things like http://root.cern.ch/root/Cint.html
On Sep 2, 2006, at 4:45 PM, Martin DeMello wrote:
Why does this work?
Cause ruby is cool like that? 
There are actually two forms of case, the first being
case x
when y
…
when z
…
else
…
end
which is equivalent to:
if y === x
…
elsif z === x
…
else
…
end
and
case
when cond1
…
when cond2
…
else
…
end
which is equivalent to
if cond1
…
elsif cond2
…
else
…
end
On Sun, Sep 03, 2006 at 03:30:06AM +0900, M. Edward (Ed) Borasky wrote:
Chad P. wrote:
. . . and I wouldn’t use C or Fortran for certain classes of complex
application programming, either.
There are a lot of things I wouldn’t use Fortran for, although when it
was the only high-level language my colleagues were used to, I did.
But despite its original intent as a systems programming language, I
can’t think of a single application I wouldn’t write in C if that’s what
I was paid to do.
Hell, pay me enough, and I’ll write your word processor web application
in assembly. This discussion is, I thought, about what languages make
sense to use for a given task – not whether you’d be willing to do
awful drudgery for beaucoup bucks.
I wouldn’t use Java at all, if I could help it, but that’s another
story.
Well … I liked Java at one time well enough to choose it over the
protestations of management for a project … as an excuse to learn the
language. I find Ruby to be a happy blend of all that’s good in Java
(objects, classes, methods, garbage collection) and Perl (regular
expressions, system administration primitives built in, arrays and
hashes, simplified syntax), with a few other nice touches of its own
(lambdas, continuations, open classes).
Perl does garbage collection via reference counting, and does it
exceedingly well. Most languages these days do objects, classes, and
methods (Perl included). I find the way Java does most of this stuff to
be pretty odious, personally.
M. Edward (Ed) Borasky wrote:
There’s so much to know about any programming language and tool chain,
Let’s put it this way … I’m saying programmers shouldn’t whine that
the edit/compile/link/test cycle of C is less efficient than the
edit/test cycle of Ruby, because it isn’t if their program is properly
modularized. And you seem to be saying that they shouldn’t whine about
the edit/compile/link/test cycle of C being less efficient than the
edit/test cycle of Ruby because there is a C interpreter.
Yes, either understandable ignorance (didn’t know there were C
interpreters) or disingenuous pretence (mentioning C interpreters
edit/test completely undermines the relative advantage of Ruby
edit/test, without needing to assert that edit/compile/link/test is
just as efficient).
(In anycase I wouldn’t characterize it as whining.)
Isaac G. wrote:
that we are understandably ignorant of other languages and tools.
However in these Google days it’s harder to understand why we would
continue to assume that the only tools available for C are
compilers/linkers… Searching on c interpreter should be enough to
find things like http://root.cern.ch/root/Cint.html
Ah … but why would I waste the time to search for, download, install,
learn, and most likely beta test a C interpreter when I’m perfectly
effective with Vim, gcc, make, autoconf, cvs/subversion, etc.? Or in the
Windows environment with Visual C++ Express and the platform SDK?
Let’s put it this way … I’m saying programmers shouldn’t whine that
the edit/compile/link/test cycle of C is less efficient than the
edit/test cycle of Ruby, because it isn’t if their program is properly
modularized. And you seem to be saying that they shouldn’t whine about
the edit/compile/link/test cycle of C being less efficient than the
edit/test cycle of Ruby because there is a C interpreter. 