The Wikipedia entry for Ruby says:
“Ruby supports multiple programming paradigms, including functional,
object oriented, imperative and reflection.”
Is this correct? What features does Ruby have, compared to say Java,
that support the imperative paradigm?
On 05.03.2009, at 16:38, Mike S. wrote:
“Ruby supports multiple programming paradigms, including functional,
object oriented, imperative and reflection.”Is this correct?
Yes.
What features does Ruby have, compared to say Java,
that support the imperative paradigm?
In ruby you can just write a script without class/module definitions
like:
#! /usr/bin/env ruby
def f1
…
end
…
def fn
…
end
statement1
statement2
…
\EOF
That’s the imperative way.
In Java you always have a class definition and a main method which is
called.
class Bla {
p. s. v. main(…) {…}
}
Yes you don’t have to instantiate a class or define a custom constructor
in Java, but that’s anyway not another paradigm.
For the functional part in Java you can define classes which you use
as pseudo
function parameters, but that’s really not nice to use, because foreach
operation you want to p.e. map(), you have to define a whole class in
a separate
file.
regards, Sandor
Szücs
On 05.03.2009 16:38, Mike S. wrote:
The Wikipedia entry for Ruby says:
“Ruby supports multiple programming paradigms, including functional,
object oriented, imperative and reflection.”Is this correct?
Yes. Although IMHO reflection is not a programming paradigm but rather
a specific language feature. But Wikipedia seems to disagree here.
What features does Ruby have, compared to say Java,
that support the imperative paradigm?
Java is imperative as well. “imperative” in this context just means
that you explicitly state which operations have to be executed in order.
In contrast, “declarative” languages (such as SQL and some functional
languages) just define the outcome and the language runtime or compiler
is free to deliver specified results in any way it sees appropriate.
This is probably best known for SQL, where the RDBMS’s optimizer tries
to find the best execution plan given the statement and the data
accessed. But this also happens in other languages for example Prolog.
Kind regards
robert
Sandor Szücs wrote:
For the functional part in Java you can define classes which you use
as pseudo
function parameters, but that’s really not nice to use, because foreach
operation you want to p.e. map(), you have to define a whole class in
a separate
file.
No, you don’t. Java has anonymous classes.
On Mar 5, 11:54 am, Robert K. [email protected] wrote:
Yes. Although IMHO reflection is not a programming paradigm but rather
a specific language feature.
Reflection is not a programming paradigm, but “reflective programming”
is a paradigm. The best example may be Conway’s Game of Life written
in a single line of APL. (The APL writes the APL that creates the
game.) I changed “reflection” to “reflective” in Wiki.
Robert K. wrote:
“imperative” in this context just means
that you explicitly state which operations have to be executed in order.
Good point. I’d taken imperative to mean procedural, and you’re right -
it actually is starting off on another tack: imperative vs functional
(or declaritive).
I’m interested in this angle because I’m worried people learn OO and
miss the many simple tricks of old-fashioned programming. I’ve inherited
a multi-million .NET development that has a central C# ‘module’ of 8000
lines. Every minor change creates 5 side-effect defects. It’s a
nightmare and I wonder whether it wouldn’t have been so much better if
written in the 1970s style of modular/structured procedural programming.
Sandor Szücs wrote:
No, you don’t. Java has anonymous classes.
Yes that’s true, but you can instantiate an anonymous class just once
and use this as a parameter or am I miss something?
You am miss something.
It’s some years ago but as I looked into function parameters in Java it
was just a pain to use. Maybe Java7 added some nice features.
This has been around since the beginning.
class Main {
public static void main(String[] args) {
System.out.println(new Object( ) {
public String toString() {
return “Aloha!”;
}
});
}
}
On 05.03.2009, at 19:22, Sebastian H. wrote:
Sandor Szücs wrote:
For the functional part in Java you can define classes which you use
as pseudo
function parameters, but that’s really not nice to use, because
foreach
operation you want to p.e. map(), you have to define a whole class in
a separate
file.No, you don’t. Java has anonymous classes.
Yes that’s true, but you can instantiate an anonymous class just once
and
use this as a parameter or am I miss something?
It’s some years ago but as I looked into function parameters in Java it
was just a pain to use. Maybe Java7 added some nice features.
regards, Sandor
Szücs
On 06.03.2009 00:28, Sandor Szücs wrote:
No, you don’t. Java has anonymous classes.
Yes that’s true, but you can instantiate an anonymous class just once
and
use this as a parameter or am I miss something?
This is not exactly true. You can instantiate it in one code location
only (because you do not have a name to refer to it) but you can of
course have multiple instances and use it in multiple places (e.g. by
having a creator method that returns the super class or interface that
you use to define the anonymous class).
It’s some years ago but as I looked into function parameters in Java it
was just a pain to use. Maybe Java7 added some nice features.
Not really, as Jeff already pointed out. I’d concede that it is more
cumbersome than in Ruby with blocks because of the limitations
(variables used inside the anon class must be final for example).
Kind regards
robert
Robert K. wrote:
On 06.03.2009 00:28, Sandor Szücs wrote:
It’s some years ago but as I looked into function parameters in Java it
was just a pain to use.
ITYM “lambda expressions,” not “function parameters.”
I’d concede that it is more
cumbersome than in Ruby with blocks because of the limitations
(variables used inside the anon class must be final for example).
Agreed, but Ruby blocks and Java anonymous classes are subtly different
things. Java anonymous classes were meant to be an approximation to
closures.
When a closure is called, it still “lives” in the scope that created it.
Java’s anonymous classes don’t really have access to their parent
scopes, but Java fakes it by copying data before the scope goes away.
Of course, the copies have to be immutable, or else two AC instances
from the same creating scope could tell that they weren’t really
accessing the same variables.
Ruby blocks are something completely different, but IMO, they’re more
like closures than Java ACs, because they execute in the scope where
they are created. They’re not really lambdas at all, though, because
you can’t pass them around as objects. Of course, Ruby also supports
real closures, and class Proc fills a similar role to Java ACs.
On 05.03.2009 23:42, Mike S. wrote:
Robert K. wrote:
“imperative” in this context just meansthat you explicitly state which operations have to be executed in order.
Good point. I’d taken imperative to mean procedural, and you’re right -
it actually is starting off on another tack: imperative vs functional
(or declaritive).I’m interested in this angle because I’m worried people learn OO and
miss the many simple tricks of old-fashioned programming.
IMHO then they have a bad teacher. I view OO as a superset of plain old
procedural programming. All procedural design principles
(modularization to name an important one) still hold true. Software
engineering is always about how you spread a certain set of
functionality across a number of programming language artifacts
(functions, classes, modules etc.). One of the most ubiquitous errors I
have seen is to lump too much into a single entity (be it function,
class or whatever). Somehow people seem to be afraid of creating too
many artifacts by properly breaking down things.
I’ve inherited
a multi-million .NET development that has a central C# ‘module’ of 8000
lines. Every minor change creates 5 side-effect defects. It’s a
nightmare and I wonder whether it wouldn’t have been so much better if
written in the 1970s style of modular/structured procedural programming.
I would have made certain things a bit easier maybe. But the error is
not in the paradigm but its application. I would concede that OO is
harder to master than plain procedural because OO adds at least one or
two dimensions onto functionality can be distributed. With the
increased number of choices it seems harder for people to pick the
proper ones.
Having said that, since 8000 LOC does not sound too much - maybe you can
promote a rewrite of the core module. Of course, if the interface of it
is totally flawed the core rewrite will not help too much. The only
other thing you can do is to gradually refactor the code to at least get
the internal implementation in better shape.
Kind regards
robert
On 06.03.2009, at 13:48, Jeff S. wrote:
must be final for example).
weren’t really accessing the same variables.Ruby blocks are something completely different, but IMO, they’re
more like closures than Java ACs, because they execute in the scope
where they are created. They’re not really lambdas at all, though,
because you can’t pass them around as objects. Of course, Ruby also
supports real closures, and class Proc fills a similar role to Java
ACs.
Thank you both for pointing it out.
It’s nice to learn that Java is not as bad as I thought!
Regards, Sandor
Szücs
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