Re: Language evolution C->Perl->C++->Java->Python (Is Python the ULTIMATE oflanguages??)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Language evolution C->Perl->C++->Java->Python (Is Python the ULTIMATE oflanguages??)

David Simmons
--
-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."
"Just Me" <[hidden email]> wrote in message
news:[hidden email]...
> First let me say that I don't want to start yet another religious war
about

> languages, but in Smalltalk this would be:
>
>   |x|
>   x=1.
>
> Notice the same amount of keystrokes? ;-)
>
> Now, let's see a case where Smalltalk is clearly better. Take this code
> from Java for example:
>
>   java.util.Enumeration enum=allEmployees.elements();
>   while( enum.hasMoreElements() ) {
>     Employee eachEmployee=(Employee)enum.nextElement();
>     eachEmployee.firstMethod();
>     eachEmployee.secondMethod();
>   }
>
> ...into Smalltalk:
>
>   allEmployees do: [:eachEmployee |
>      eachEmployee
>         firstMethod;
>         secondMethod ].

In SmallScript (a language that encompasses Smalltalk) this can also be
written as:

    for(each employee in allEmployees)
       employee firstMethod; secondMethod.


Or, if the "allEmployees" supports different iterators by <type> we can
distinguish them:

    for(each <Employee> e in allEmployees)
       e firstMethod; secondMethod.


We also have the options within the iteration to:
---------------------------
    break.
    continue.
    leave.
    redo.

And, assuming we have an <Iterator> interface and a class
called EmployeeCollection. We could write it with the
following scriptlets: (each is fully self contained and
their text could be evaluated as is)
----------------------------------------------------------

<!--
==========
ASSUMES:
==========

There is some other script that references or defines the
<EmployeeCollection> and <Employee> classes. It also assumes
the existence of the <Iterator> interface within the visible
set of namespaces for this project (or the default if no
explicit project/assembly was specified). Finally, it
assumes that somewhere within the visible namespace scopes
there is a shared (namespace/pool) variable called
"allEmployees".

========== -->

<class name=EmployeeCollection interfaces="+Iterator"/>
[
    |iterator| := allEmployees as: Iterator for: Employee.
    [iterator next] whileNotNil: [:e| e firstMethod; secondMethod].
]

<!-- OR -- possibly: -->
<class name=EmployeeCollection interfaces="+Iterator"/>
[
    |iterator| := allEmployees#Iterator.for: Employee.
    while(iterator next) [:e| e firstMethod; secondMethod].
]

<!-- OR -- possibly: -->
<class name=EmployeeCollection interfaces="+Iterator"/>
[
    |iterator| := allEmployees::Iterator.for(Employee).
    while(iterator next) [:e| e firstMethod; secondMethod].
]

<!-- OR -- possibly: -->
<class name=EmployeeCollection interfaces="+Iterator"/>
[
    |iterator| := allEmployees.asFor(Iterator,Employee).
    while(iterator.next) [:e| e firstMethod; secondMethod].
]

<!-- OR -- possibly: -->
<class name=EmployeeCollection interfaces="+Iterator"/>
[
    |iterator| := allEmployees.asFor(Iterator,Employee).
    1 to: iterator limit do: [:i| iterator[i] firstMethod; secondMethod].
]

<!-- OR -- possibly: -->
<class name=EmployeeCollection interfaces="+Iterator"/>
[
    |iterator| := allEmployees.asFor(Iterator,Employee).
    until(iterator.atEnd) iterator.next firstMethod; secondMethod.
].


<!-- OR -- not at all clear but the message #::(<Behavior>)
           could be written in <Iterator> to provide: -->
method class=Iterator scope=ThisProject [
(<Behavior> doType)
    ^for(doType)
]
<class name=EmployeeCollection interfaces="+Iterator"/>
[
    |iterator| := allEmployees(Employee).
    "" also writeable as 'allEmployees::Iterator.(Employee)'
    while(iterator next) [:e| e firstMethod; secondMethod].
]

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>
> In Smalltalk it's simple, elegant and easy to read whereas in Java one can
get
> headaches from all these braces. I mean what are braces for anyway if a
> method has no arguments?
>
> And as you can see, no types mean less typing!
>
>
> Kenny Pearce wrote:
>
> > I haven't used SmallTalk, but from this conversation it seems that the
only difference
> > between "everything is an object" and having primitives is that the
latter requires
> > less typing. Ex.
> > int x =1;
> > as opposed to
> > Integer x = new Integer(1);
> >
> > I can't c y there would be any other difference...
>