APL in 2020 - Object Orientation
Dick Bowman
have introduced object-orientation in recent years. Possibly a
game-changing step for APL, so...
[0] Have you used these object-oriented features?
[1] Were they useful to you?
[2] Can you measure the usefulness?
[3] How does APL's object-orientation measure up against other languages?
[4] Can you live without object-orientation?
[5] How does object-orientation fit with the traditional model of APL?
[6] Are there things spectacularly right or wrong in the APL O-O
implementations?
[7] Will people from outside APL feel at home with APL's O-O?
[8] Do differences between vendors affect/bother you?
and the big question...
[9] Are things happening outside of APL which are a step beyond
object-oriented programming and what should we know about them?
Bjorn
> Several versions/dialects/whatever of APL (and J - we're inclusive here)
> have introduced object-orientation in recent years. Possibly a
> game-changing step for APL, so...
>
> [0] Have you used these object-oriented features?
I have only tried them in J.
> [1] Were they useful to you?
Yes, Very!
> [2] Can you measure the usefulness?
They make use of utilities very easy,
Extending utilities and changing some is very powerful.
Making system into modules and separating names is very useful.
Being able to investigate classes and objects life is something that
is easy in J and gives you a much better understanding of the whole
concept.
> [3] How does APL's object-orientation measure up against other languages?
Before J I had a bit of hard time understanding object oriented
programming.
J has made object oriented become an easy and very useful tool.
All kinds of textbooks and courses using other languages did more
confuse the issue.
Being able to touch the objects in J and the excelent labs and
examples you can try and use in J made object oriented become useful
and understood.
> [4] Can you live without object-orientation?
Of course one can live without it but after using it for a long time
now it would probably be hard.
> [5] How does object-orientation fit with the traditional model of APL?
As I see it then it fits J like a glove and makes the power much more
useful.
> [6] Are there things spectacularly right or wrong in the APL O-O
> implementations?
I can only speak from my experience with J and I can not see anything
wrong with it.
I find it spectacularly right and it seems now like it has always been
intended.
> [7] Will people from outside APL feel at home with APL's O-O?
I think that it may take some getting used to J in general and
especially the ideas of everthing being live and the use of locales.
O-O in particular I do not think should be a problem if people would
understand it at all.
As we know then people who come from other programming tools may find
it too easy so it might be a bonus of not knowing other programming
languages before.
> [8] Do differences between vendors affect/bother you?
I do not know too much about O-O in other APL environments so I am not
able to comment on that.
I am actually not sure how O-O is working in other APL environments.
J keeps you on the toes all the time with new stuff so it is more than
enough to keep up there.
I do look at other APLs but have not experienced O-O enough to say I
understand it enough to comment.
I have seen it working and it seems to be doing a good job too.
>
> and the big question...
>
> [9] Are things happening outside of APL which are a step beyond
> object-oriented programming and what should we know about them?
I am not sure I understand what that could be.
Martin Neitzel
>Before J I had a bit of hard time understanding object oriented
>programming.
>J has made object oriented become an easy and very useful tool.
Cool. Can you explain to us how to form an array of objects in J
and how to invoke a class method on the entire object array?
Martin
Bjorn
wrote:
It is best for you to download a copy and study the labs and demos.
If you have difficulty learning then contact the J forums.
Dick Bowman
> Several versions/dialects/whatever of APL (and J - we're inclusive here)
> have introduced object-orientation in recent years. Possibly a
> game-changing step for APL, so...
>
> [0] Have you used these object-oriented features?
In Dyalog APL/W, mostly.
> [1] Were they useful to you?
Yes, I suspect that introducing O-O was vital for Dyalog to implement
things like DotNet support; that's in addition to the benefits of "pure"
O-O.
> [2] Can you measure the usefulness?
Numerically, no. But I feel that my code using objects is clearer and more
easily extendable.
> [3] How does APL's object-orientation measure up against other languages?
I tried to learn SmallTalk once, but it was not a success. Aside from that
I have very little experience of O-O in other languages.
> [4] Can you live without object-orientation?
Not now that I've used it for a while.
> [5] How does object-orientation fit with the traditional model of APL?
It still feels a bit "bolted on" to me, for example I create a new variable
with the "is" arrow, but a new object needs quadNEW.
> [6] Are there things spectacularly right or wrong in the APL O-O
> implementations?
I feel uncomfortable with "scripts"; possibly because of exposure at early
stages of Dyalog's implementation - things are a lot better now. I can't
find much attraction to the idea of editing code away from the integrated
APL environment.
> [7] Will people from outside APL feel at home with APL's O-O?
Don't know, I've heard anecdotally that "outsiders" feel comfortable with
Dyalog's implementation.
> [8] Do differences between vendors affect/bother you?
Yes - I yearn back to the days when we could promiscuously shift our code
across implementations and hardware platforms, yet still have 99% work
straight away. I like the way that quadXML is a new feature which is
"agreed" between APLX and APL/W.
>
> and the big question...
>
> [9] Are things happening outside of APL which are a step beyond
> object-oriented programming and what should we know about them?
I don't know enough about the computing world outside of APL, but I doubt
that O-O is going to be the final world in programming paradigms. Rather
hoping that someone would point the discussions in an interesting
direction.
Richard Nabavi
>
> It still feels a bit "bolted on" to me, for example I create a new variable
> with the "is" arrow, but a new object needs quadNEW.>
Interesting. At MicroAPL we had exactly that feeling, but decided in
the end to go with the Dyalog style (as closely as we could, given
differences in the scope of what we were trying to do), in the
interests of cross-vendor compatibility.
Bjorn
> have introduced object-orientation in recent years. Possibly a
> game-changing step for APL, so...
>
I am not sure if it has anything to do with O-O but there seem to be
much more of APL integration with the rest of the world.
In J there are a number of applications that use J to control and call
utilities outside of J.
There are also a number of applications calling J to do something that
J is better at.
The cover utilities in J are often baked into O-O so that the user
does not need to see them among own written names.
Grouping names and braking up applications into better defined modules
is possibly what O-O is all about and it fits very well in APL to do
so.
I remember times when it was a challenge to make naming pre or
postfixes in huge workspaces in order to have applications sort of
organized.
O-O has made all that much easier and locales in general is an
extension that is hard to live without.
Bakul Shah
>> [9] Are things happening outside of APL which are a step beyond
>> object-oriented programming and what should we know about them?
> I don't know enough about the computing world outside of APL, but I doubt
> that O-O is going to be the final world in programming paradigms. Rather
> hoping that someone would point the discussions in an interesting
> direction.
I wonder if something like Haskell's type classes might feel less
"bolted on"....
In a traditional O-O language you define a class and a set of
operations on instances of this class (i.e. objects). In Haskell
you define a _type_ class and associate a set of operations (or
methods). An instance of a type class is a type (and not an object)
that must define these methods.
Thus in expression a == b, a & b are of the same type but can be
any type that is an instance of type class Eq. An instance of Eq
must define an == operator. If you define a new type Foo and you
want to use == on objects of type Foo, you would add
instance Eq Foo where
x == y = x `FooEq` y
The right side can be any expression.
As you can see, unlike C++/Java, the defn of a type is separated
from defns of methods associated with that type. This is far more
flexible. Far more "composable". It also feels a lot less
intrusive than C++/Java -- you still say `f x' and not `x.f()'.
Probably because Haskell doesn't need as many syntactic aids as
C/C++ to figure out types. This last point is why I thought
Haskell type classes may be a good model for APL languages. I shall
investigate this further if ever I make enough progress with my
Scheme based array language implementation.
The following tutorial is a very good introduction to type classes.
http://www.haskell.org/tutorial/classes.html
Another direction to look at is what go does with 'interfaces'. It
feels more right than the C++/Java style but still has that ugly
x.f() syntax!
David Liebtag
David Liebtag
IBM APL Products and Services
Bjorn
> have introduced object-orientation in recent years. Possibly a
> and the big question...
>
> [9] Are things happening outside of APL which are a step beyond
> object-oriented programming and what should we know about them?
I have been thinking about this one and it led me to look again at UML
and that might be something to think about.
Describing a system with UML and generate J code and possibly create
UML automatically from J scripts.
Bakul Shah
> From your description, Haskell's type classes sound like Java's interfaces.
Almost. The key difference is you can make a type an instance of some
type class even after the type has been declared (even on a type provided
by someone else). This is much more appealing to me; I can dream up new
operators and can apply them to objects of familiar types! See for
instance
http://www.xoltar.org/old_site/languages/haskell/skinning_haskell.html
where the author extends (!) the index operator ([] in most languages) to
maps of all kinds even though in Haskell it is defined only for arrays.
Contrast that with, for example, k4 that added built-in indexing on
dictionaries & tables.
del
J does not have instances properly speaking. They are locales and
locales are not assignable (like in APL) so you cannot have arrays of
instances or classes (which are also locales).
J's simulation of OO also has limited OO features and properties,
interfaces and nested classes are for ex. impossible.
Nevertheless you can achieve a lot with it if you know what you're
doing.
Bjorn
You may want to send in a request or clarification to the J forum if
you find things missing from J O-O implementation.
I do not recall seeing anyone asking for anything more or different
regarding J O-O in the J forum.
It would be interesting to see what answers you would get in the J
forum because there you have the experts and they will know if you are
right or not.
As far as I am concerned J O-O is quite adequate and good and not at
all limited and I am not sure if I would want anything different.