When clever is stupid

[M. Edward (Ed) Borasky]

. . . 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.

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.

C++, on the other hand, I consider a gross abomination.

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).

 

[Martin DeMello]

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

 

[Isaac Gouy]

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.

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

 

[Logan Capaldo]

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

 

[M. Edward (Ed) Borasky]

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

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.

 

[Chad Perrin]

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.

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.

 

[Isaac Gouy]

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.

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.)