Forum: Ruby Ruby - Imperative Language Features?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D1309ef77561e3cdf0ddcab60b244e52?d=identicon&s=25 Mike Stephens (aspirer)
on 2009-03-05 16:39
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?
Cb6bbc826cd7d9238a2fae344958f7ec?d=identicon&s=25 Sandor Szücs (Guest)
on 2009-03-05 17:59
(Received via mailing list)
On 05.03.2009, at 16:38, Mike Stephens 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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-03-05 18:00
(Received via mailing list)
On 05.03.2009 16:38, Mike Stephens 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.

http://en.wikipedia.org/wiki/Imperative_programming
http://en.wikipedia.org/wiki/Declarative_programming

Kind regards

  robert
7a561ec0875fcbbe3066ea8fe288ec77?d=identicon&s=25 Sebastian Hungerecker (Guest)
on 2009-03-05 19:23
(Received via mailing list)
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.
Bfc93c0b6445bf138e06986214be5878?d=identicon&s=25 Martin Rinehart (Guest)
on 2009-03-05 21:20
(Received via mailing list)
On Mar 5, 11:54 am, Robert Klemme <shortcut...@googlemail.com> 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.
D1309ef77561e3cdf0ddcab60b244e52?d=identicon&s=25 Mike Stephens (aspirer)
on 2009-03-05 23:43
Robert Klemme 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.
Cb6bbc826cd7d9238a2fae344958f7ec?d=identicon&s=25 Sandor Szücs (Guest)
on 2009-03-06 00:30
(Received via mailing list)
On 05.03.2009, at 19:22, Sebastian Hungerecker 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
149379873fe2cb70e550c6bff8fedd0c?d=identicon&s=25 Jeff Schwab (Guest)
on 2009-03-06 02:13
(Received via mailing list)
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!";
             }
         });

     }
}
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-03-06 09:05
(Received via mailing list)
On 05.03.2009 23:42, Mike Stephens wrote:
> Robert Klemme 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.

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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-03-06 09:10
(Received via mailing list)
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
149379873fe2cb70e550c6bff8fedd0c?d=identicon&s=25 Jeff Schwab (Guest)
on 2009-03-06 13:51
(Received via mailing list)
Robert Klemme 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.
Cb6bbc826cd7d9238a2fae344958f7ec?d=identicon&s=25 Sandor Szücs (Guest)
on 2009-03-09 13:20
(Received via mailing list)
On 06.03.2009, at 13:48, Jeff Schwab 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 topic is locked and can not be replied to.