Question to Arbortext: Long term plans for ACL?

[karl.johan]

Any Arbortext/PTC gurus lurking here?

It's now more than ten years since the first time
I built a customer integration with Arbortext Editor. Over time,
I have Learned to Stop Worrying and Love the Arbortext Command Language
(to paraphrase Stanley Kubrick).

When returning to this community a year ago, I was delighted to meet
AOM and the possibility to use Java or JavaScript. However,
these new acquaintances make me wonder about the future destiny of ACL.

On one hand, from the tremendous amount of technical re-structuring
that the Editor obviously has undergone behind the curtains,
one would guess that the days of ACL are numbered.

On the other hand: the immense amount of (more or less core) ACL code
in the "packages" directory seems to indicate that ACL will continue
to be a "first class citizen" for a very long time.

So please, Arbortext, how should one advice one's clients regarding
the long term strategy for ACL?

Thanks,
K J







--
Kleist IT Consulting, Karl Johan Kleist
Frankfurter Allee 45, DE-10247 Berlin

+49 30 42 01 70 91 (office)
+49 17 38 35 82 06 (mobile)

Maintainer of

[lhales]

KJ,

I am with you on this. One of the last things I recall hearing is that
ACL is going to be here for a while. My PERSONAL two pfennigs on ACL is
this.

Arbortext will continue to use ACL, but I think they are slowly but surely
phasing it out in favor of other more widely used languages. As you
pointed out, the sheer volume of Epic code written in ACL is prohibitive
of just dumping it. From the looks of new code coming out in Epic
releases, each release sees an increase in Java or other code files. I
just did a REAL check on my statement here. I did a search for ACL files
in version 4.3.1 and there were 357 files, the oldest being from Oct 1997.
In 5-2, there were 413, the oldest being from Dec 1998.

I also checked a couple of files for differences and Epic is still
updating existing ACL to support changes.

If my history of ACL serves me correctly, it was developed early on in the
Adept process. First versions of Adept were Unix based (first Windoze
version was 5.4 in 1995 and I saw my first version of Adept in 1992 or 93
[because I didn't have a BS in CS, I couldn't be 'trusted' to touch the
multi thousand dollar Sun Solaris system we bought to run Adept]). When
the early Adept developers were writing code, there was no common
available language in Unix they could use, so they took (and I NEVER EVER
remember the language they based ACL on) some language modified it into
ACL so they could make Adept work (which it still does).

As a non programmer, I like ACL, it has allowed me to do things with the
built in functions and scripting that I would not have been able to do
otherwise, even after the support for other languages was introduced.

So the original question still applies. PTC, what is the long term plan
for ACL? By long term, I am saying three to five years down the road.

Lynn

[jdreystadt]

Our plans for language support involve adding more and more to the AOM
for non-ACL programmers. We have no plans to "dump" ACL. As has been
pointed out, we have lots of ACL in the installation tree and we don't
see any gain in having to rewrite all of this code. We still add
occasional new features using ACL. It is not dead, not even orphaned.

It is also equally true that you will not see as much new development in
ACL coming out in new versions of our software as you have seen in the
past. As our customer base has more and more people using the AOM for
customization, we should be "eating our own dog food" if you know that
phrase.

John Dreystadt
Software Development Director
Arbortext - PTC
734-327-6079
-

[JasonBuss]

I would agree that, unless I hear otherwise, I would expect ACL to still be
around in the next 3-5 years.

Where I differ from many of my other developer-types (other than not having
the BS in CS, you weren't the only one that had to do it the hard way,
Lynn), is that I would hate to see ACL go away. Others can complain that
"it's not an open language" and "it's a proprietary solution", but it's a
good tool for getting a lot done quickly. Plus, it's so tied into the
infrastructure of Epic that trying to replicate some of the functionality
that ACL provides would be time-consuming at best, and infuriating at worst.
It's just a good-enough blend of Perl and C to be useful, plus the help
documentation (IMO) is an impressive example of how scripting languages
SHOULD be documented.

Honestly, if Arbortext wanted to phase out ACL, what I would LOVE to see
(and I can't say how hard this would be), is for them to implement the
majority of ACL functionality with another, open scripting language. If
they could replicate most of the ACL funcs and commands with, say, Python
(or preferably Jython), can you imagine how much more you could do within
the app?

Don't get me wrong, I don't hate Java, it's good for it's intended purpose.
It's just there's so much in ACL that can be performed with one alias or
func that takes on so much extra complexity trying to recreate in Java.

Just my 0.02-

-Jason A. Buss

[ekimber]

Buss, Jason A wrote:

> Honestly, if Arbortext wanted to phase out ACL, what I would LOVE to see
> (and I can't say how hard this would be), is for them to implement the
> majority of ACL functionality with another, open scripting language. If
> they could replicate most of the ACL funcs and commands with, say, Python
> (or preferably Jython), can you imagine how much more you could do within
> the app?

You can use Python with Epic today using either AOM (through Jython) or
via the Python COM support under Windows. We did this in 1999 for one of
our projects. It's not quite as convenient as just hacking up an ACL
script, but it works pretty well (in fact, at the time we had a problem
where we were trying to do something where used a C++ program first and
it always crashed. When we moved it to Python it worked
perfectly--something with how Python was interacting with COM API layer
in the editor.

Cheers,

Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com