Vector themed issue: How to wear sheepskin

On Jul 31, 8:20*am, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> A message on the J Forum this morning refers to a familiar issue: how
> to include (APL, J, K, q) components in a project implemented in other
> languages without getting chased out by the IT shepherds?

A reminder of the topic of this thread, which is veering towards the
familiar, related but different topic of how to attract newcomers to
APL...

The invitation is to discuss human aspects as well as the technical
ones.

For example, I recall belonging to a tiny APL group when we were
recognised a few years ago as the lead tool for 're-engineering' the
business of a substantial division of a very large company. Managers
immediately started focusing on our very sketchy schedule. Many tasks
took longer than forecast and the managers started showing each other
charts mottled with yellow, orange and red, and declaring a crisis.
Eventually they accepted that our forecasts, based on the haziest
ideas of the work ahead, were of slight value and that, since we were
progressing 1-2 orders of magnitude faster than their own IT division,
there was little to be gained from managing us so closely. (An analogy
with Heisenberg's Uncertainty Principle here?) Given that quantifying
and controlling is a primary responsibility of management, and that
their usual experience of IT projects was of accounting for failure,
this was a considerable hurdle for them to clear.

On a related note, our project nearly died when a crucial interface to
an internal mainframe took six months to appear instead of the
scheduled six weeks, a delay no one in IT or management thought
remarkable. (We had estimated three weeks as the longest we could
imagine, then doubled it. The programmer who coded it confirmed later
it had been less than a week's work.)

Relativity effects in management, anyone?

Stephen Taylor
editor@vector.org.uk

"Stephen Taylor <editor@vector.org.uk>"
<StephenTaylorFRSA@googlemail.com> wrote in message
news:47a27c74-aa8c-444a-8cdc-7ad6a763ac17@d45g2000hsc.googlegroups.com...
On Jul 31, 8:20 am, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> A message on the J Forum this morning refers to a familiar issue: how
> to include (APL, J, K, q) components in a project implemented in other
> languages without getting chased out by the IT shepherds?

>>>>>>>>>>>>
A reminder of the topic of this thread, which is veering towards the
familiar, related but different topic of how to attract newcomers to
APL...

On a related note, our project nearly died when a crucial interface to
an internal mainframe took six months to appear instead of the
scheduled six weeks, a delay no one in IT or management thought
remarkable. (We had estimated three weeks as the longest we could
imagine, then doubled it. The programmer who coded it confirmed later
it had been less than a week's work.)
>>>>>>>>>>>>

I'm afraid I'm reading this wrong. From which side or from whom came the
"note" - from heaven?
Or was it an act of "destroy them before they destroy us?" Did they
treat you as "wolves in sheepskin?"
I had something like that in my first lesson COBOL. While introducing
ourselves in the classroom, the instant I mentioned doing APL the
teacher gave me tit for tat: "APL-ers can't program!" Very bad conduct.
For the remaining I only know these things from the movies (like
dropping crucial folders behind cases) ...
^/jk

"On a related note, our project nearly died when a crucial interface
to an internal mainframe took six months to appear instead of the
scheduled six weeks, a delay no one in IT or management thought
remarkable. (We had estimated three weeks as the longest we could
imagine, then doubled it. The programmer who coded it confirmed later
it had been less than a week's work.)"

Does this mean:

1. That APL developers charge 3-6 times as much as it actually costs
to do a piece of work?
2. That APL developers sit down idle for 5 times the duration that a
piece of work took to complete?

More subtly,

3. It is reasonable for an organisation to introduce single points of
failure in their organisations? That is what teams of one solitary
individual are!

Even more subtely,

4. Do the specification (functional & non-functional), the suite of
unit tests, the suite of regression tests, the writing of technical &
user manuals, the planning and execution of deployment and user
training plans take less time if the project is undertaken in APL as
opposed to being undertaken in another language?

If you are still able to answer these questions in the affirmative,
try this final one:

5. The life cycle of a product is roughly 10 years. 75-80% of the cost
of the project is incurred in the maintenance phase. If development in
APL is that much faster, it is faster in respect of just 20-25 % of
the cost of software during its life cycle. In true light, I think
this is insignificant.

I do not believe that people who control the wallets of IT departments
are willingto believe any of this.

The RAD aspects of APL do offer something very valuable, especially of
you throw everything out of the window. Let me elaborate.

The single most difficult aspect of project planning is the estimation
of the duration it will take. That is because organisations rarely
keep metrics on previous projects and when they do, there are always
other factors that conspire to make the usefulness of such metrics
rather marginal.

The next most difficult aspect of any project is to get the
specification right. I do not believe that it is that easy to write
down computational functinality without ambiguity.

The third reality of project management is that projects are subject
to very different constraints
depending on whether they are internally or externally driven. An
example of an externally driven project might be one that arises
because of changes in legislation or self-regulation i.e. there is a
finite cut-off point. An internally driven project might be, say,
including support of a new database in the list of databases already
supported by a product.

In all these 3 respects, APL has a unique advantage if it can be used
to prototype the application to flush put all/most of the logical
flaws and in the process may provide valuable guidelines for project
estimation.

The catch is this: the APL application must be written such that
either it can be easily ported to the target language of the sponsor
or the prototype itself must be adaptable/scalable to the rigours of a
production system. More than anything else, thjis implies the use of
standard technology components.

When it comes to claims about speed, it is worth remembering that 9
members of the male species and one member of the female species would
still take 9 months to produce an offspring. Certainly the speed to
production matters but what matters even more is the embedded value of
the software and the confidence with which it can be deployed.

"On a related note, our project nearly died when a crucial interface
to an internal mainframe took six months to appear instead of the
scheduled six weeks, a delay no one in IT or management thought
remarkable. (We had estimated three weeks as the longest we could
imagine, then doubled it. The programmer who coded it confirmed later
it had been less than a week's work.)"

Does this mean:

1. That APL developers charge 3-6 times as much as it actually costs
to do a piece of work?
2. That APL developers sit down idle for 5 times the duration that a
piece of work took to complete?

More subtly,

3. It is reasonable for an organisation to introduce single points of
failure in their organisations? That is what teams of one solitary
individual are!

Even more subtely,

4. Do the specification (functional & non-functional), the suite of
unit tests, the suite of regression tests, the writing of technical &
user manuals, the planning and execution of deployment and user
training plans take less time if the project is undertaken in APL as
opposed to being undertaken in another language?

If you are still able to answer these questions in the affirmative,
try this final one:

5. The life cycle of a product is roughly 10 years. 75-80% of the cost
of the project is incurred in the maintenance phase. If development in
APL is that much faster, it is faster in respect of just 20-25 % of
the cost of software during its life cycle. In true light, I think
this is insignificant.

I do not believe that people who control the wallets of IT departments
are willingto believe any of this.

The RAD aspects of APL do offer something very valuable, especially of
you throw everything out of the window. Let me elaborate.

The single most difficult aspect of project planning is the estimation
of the duration it will take. That is because organisations rarely
keep metrics on previous projects and when they do, there are always
other factors that conspire to make the usefulness of such metrics
rather marginal.

The next most difficult aspect of any project is to get the
specification right. I do not believe that it is that easy to write
down computational functinality without ambiguity.

The third reality of project management is that projects are subject
to very different constraints
depending on whether they are internally or externally driven. An
example of an externally driven project might be one that arises
because of changes in legislation or self-regulation i.e. there is a
finite cut-off point. An internally driven project might be, say,
including support of a new database in the list of databases already
supported by a product.

In all these 3 respects, APL has a unique advantage if it can be used
to prototype the application to flush put all/most of the logical
flaws and in the process may provide valuable guidelines for project
estimation.

The catch is this: the APL application must be written such that
either it can be easily ported to the target language of the sponsor
or the prototype itself must be adaptable/scalable to the rigours of a
production system. More than anything else, thjis implies the use of
standard technology components.

When it comes to claims about speed, it is worth remembering that 9
members of the male species and one member of the female species would
still take 9 months to produce an offspring. Certainly the speed to
production matters but what matters even more is the embedded value of
the software and the confidence with which it can be deployed.

Some of the digression topics reminded me about the summer I worked at
IBM internally while in College.

I spent a couple of weeks learning about the implementation of APL
installed and most of the Summer trying to figure out what these folks
needed in a specific business application.

And then I spent about two weeks building a tracking application in APL
for someone else.

In retrospect: In discussion, one needs to separate how much time is
spent on coding vs. the business side of application development and
waiting around for other systems.

(That place was weird anyway. They pulled me aside near the end of the
Summer and told me this was not typical IBM and not to hold it against
them when considering a job. Needless to say I never returned but I
still miss the 5100 that sat in the corner office.)

AAsk wrote:
> "On a related note, our project nearly died when a crucial interface
> to an internal mainframe took six months to appear instead of the
> scheduled six weeks, a delay no one in IT or management thought
> remarkable. (We had estimated three weeks as the longest we could
> imagine, then doubled it. The programmer who coded it confirmed later
> it had been less than a week's work.)"
>
> Does this mean:
>
> 1. That APL developers charge 3-6 times as much as it actually costs
> to do a piece of work?
> 2. That APL developers sit down idle for 5 times the duration that a
> piece of work took to complete?
>
> More subtly,
>
> 3. It is reasonable for an organisation to introduce single points of
> failure in their organisations? That is what teams of one solitary
> individual are!
>
> Even more subtely,
>
> 4. Do the specification (functional & non-functional), the suite of
> unit tests, the suite of regression tests, the writing of technical &
> user manuals, the planning and execution of deployment and user
> training plans take less time if the project is undertaken in APL as
> opposed to being undertaken in another language?
>
> If you are still able to answer these questions in the affirmative,
> try this final one:
>
> 5. The life cycle of a product is roughly 10 years. 75-80% of the cost
> of the project is incurred in the maintenance phase. If development in
> APL is that much faster, it is faster in respect of just 20-25 % of
> the cost of software during its life cycle. In true light, I think
> this is insignificant.
>
> I do not believe that people who control the wallets of IT departments
> are willingto believe any of this.
>
> The RAD aspects of APL do offer something very valuable, especially of
> you throw everything out of the window. Let me elaborate.
>
> The single most difficult aspect of project planning is the estimation
> of the duration it will take. That is because organisations rarely
> keep metrics on previous projects and when they do, there are always
> other factors that conspire to make the usefulness of such metrics
> rather marginal.
>
> The next most difficult aspect of any project is to get the
> specification right. I do not believe that it is that easy to write
> down computational functinality without ambiguity.
>
> The third reality of project management is that projects are subject
> to very different constraints
> depending on whether they are internally or externally driven. An
> example of an externally driven project might be one that arises
> because of changes in legislation or self-regulation i.e. there is a
> finite cut-off point. An internally driven project might be, say,
> including support of a new database in the list of databases already
> supported by a product.
>
> In all these 3 respects, APL has a unique advantage if it can be used
> to prototype the application to flush put all/most of the logical
> flaws and in the process may provide valuable guidelines for project
> estimation.
>
> The catch is this: the APL application must be written such that
> either it can be easily ported to the target language of the sponsor
> or the prototype itself must be adaptable/scalable to the rigours of a
> production system. More than anything else, thjis implies the use of
> standard technology components.
>
> When it comes to claims about speed, it is worth remembering that 9
> members of the male species and one member of the female species would
> still take 9 months to produce an offspring. Certainly the speed to
> production matters but what matters even more is the embedded value of
> the software and the confidence with which it can be deployed.

"AAsk" <AA2e72E@lycos.co.uk> wrote in message
news:9c1977f1-b059-4366-99c5-eca2686b7e0a@k37g2000hsf.googlegroups.com...
> "On a related note, our project nearly died when a crucial interface

[...]
>
> 5. The life cycle of a product is roughly 10 years. 75-80% of the cost
> of the project is incurred in the maintenance phase. If development in
> APL is that much faster, it is faster in respect of just 20-25 % of
> the cost of software during its life cycle. In true light, I think
> this is insignificant.
>

In my experience the life cycle of a (software) product is 3 years at
most. Very soon "maintenance" in legacy-IT environments comes
arbitrarily close to one hundred percent.
Thus, APL-like languages are indispensible.

> Does this mean:
>
> 1. That APL developers charge 3-6 times as much as it actually costs
> to do a piece of work?

Would that it did!

> 2. That APL developers sit down idle for 5 times the duration that a
> piece of work took to complete?
>

Well they either get on with the next bit (that's called increased
productivity) or they are between contracts

>
> 3. It is reasonable for an organisation to introduce single points of
> failure in their organisations? That is what teams of one solitary
> individual are!

The reasoned alternative is to have several developers working at
substantially below full capacity to act as reserves. While I'm not
saying run 1 developer flat out with no backup, developers get bored
and either leave or produce shoddy work - or worse produce shoddy work
AND then leave.

>
> 4. Do the specification (functional & non-functional), the suite of
> unit tests, the suite of regression tests, the writing of technical &
> user manuals, the planning and execution of deployment and user
> training plans take less time if the project is undertaken in APL as
> opposed to being undertaken in another language?

The specs are usually a heck of a lot lighter in any agile environment
(if we lump APL in there). We avoid link tests and the like, I will
veer away from saying we should test APL less, but on the whole, yes I
have found this burden to be lighter. User manuals are thinner and
training easier too, if you've had some interaction with them from the
start & they fell a bit more interest in, and ownership of, the
solution. Deploying a workspace or a function file is a lot easier
than some ways of doing it, although I can think of equally easy ways
of doing it.


>
> 5. The life cycle of a product is roughly 10 years. 75-80% of the cost
> of the project is incurred in the maintenance phase. If development in
> APL is that much faster, it is faster in respect of just 20-25 % of
> the cost of software during its life cycle. In true light, I think
> this is insignificant.

Well I don't agree with the 10 years, but if it takes 1 APLer to
develop it versus 6 in some other language, well shouldn't it take 1/6
of the support staff too? If support means turning round bug fixes
then the ability to cut code quickly is still an advantage in
maintenance
>
> I do not believe that people who control the wallets of IT departments
> are willing to believe any of this.

Budgets focus on delivering the product in, say, this year's plan.
Support, well, leave that to another year, and probably another
manager to sort out - or have I just encountered a lot of short
sighted IT managers over the years?

Reading the rest of your post I don't think you would disagree.

The real problem is how to "sell" the whole APL approach to blinkered
management. They like being part of a herd & using APL exposes them to
the wolves - oh dear too many animal metaphors in this thread.

- let's get rid of any special ways APL is using (component files,
dynamic (agile) approach, whatsoever...)

Comment: Component files - by all means don't eliminate component
files. Make them available as an includable feature of a project
written in APL, but don't force every project written in APL to
incorporate the underlying APL necessary to support component files.
This and the associated 'manifest' are fundamental elements of .Net
programming and one which should be adopted by APL language
implementations. The idea is that the project programmer and not the
APL language implementor determines which language features to
incorporate into the project and the manifest indicates this so that
the end user can decide if they want to consider using the project on
their machine(s).

Comment: Implementing APL in a .Net/Visual Studio environment in no
way reduces the dynamic/agile benefits of APL.

- let's integrate APL into Visual Studio

Comment: Why not? Doing so does not reduce the effectiveness of the
APL language or the programmer using APL. VisualAPL is an
implementation of APL within Visual Studio 2005/2008. Integrating APL
into Visual Studio, provides numerous benefits all using the same
source code such as:
+ Additional deployment options for APL, like as a web service, as a
1-click install from a web site, as a traditional .exe, as an
encapsulated .dll totally interoperable with any other .Net language,
etc.
+ Platform independence, see VisualAPL at
http://aplteam2.com/aplwiki/moin.cgi...ortedPlatforms
+ Integrated debugging of mixed programming language projects
including C#, VB.NET, VisualAPL, etc. because all use the same
exception/error handling.
+ Superior GUI development tools in Visual Studio
+ Comprehensive utility base available [all of .Net]
+ Interoperability with a host of additional .Net languages, even
Ruby and Python, databases, open source and commercially-licensed add-
ons, etc.

- Let us introduce strong type checking as well

Comment: As an option, why not, as in VisualAPL. Strong data typing
can improve performance significantly. It can be added after the
program is prototyped and debugged and it doesn't have to be applied
to the entire application or even an entire function. In VisualAPL the
programmer can, if desired, write code which seamlessly goes between
fixed and dynamic data typing on a line-by-line basis.

- Let's remove the APL characters.

Comment: As an option, why not, as in VisualAPL. Some programmers are
more comfortable with keywords rather than single glyphs, so as long
as both are available to the programmer without detrimental effects.

- Let's compile APL.

Comment: As an option, why not, as in VisualAPL. Compilation can
improve performance significantly. Using VisualAPL one can program
interactively to prototype and debug and view objects in the
interpreted session. The result can be delivered as a script and used
as is, in a manner analogous to traditional APL, or one can compile
the APL as an .EXE or .DLL, or other options for deployment and gain
some performance.

- I wonder why people still believe that it is possible to attract
ordinary IT guys to APL.

Comment: The inclusion of the potentially derogatory adjective
'ordinary' is exactly why some APL'ers should not be in the business
of convincing anyone in the majority, mainstream programming world to
consider APL. The computer language is always secondary to the mind of
the programmer.

Earlier I asked "So, what have I been missing?"

I think I have found the answer in Joe_Blaze's last response.

"APL'ers should not be in the business of convincing anyone in the
majority, mainstream programming world to consider APL. The computer
language is always secondary to the mind of the programmer."

"The idea is that the project programmer and not the APL language
implementor determines which language features to incorporate into the
project and the manifest indicates this so that the end user can
decide if they want to consider using the project on their
machine(s)."

.... in the last sentence, I read 'vendor' for 'implementor'

Typically, APL'ers [I abhor this term] expect everything for
'nothing', want to stay firmly in the closet that the workspace is,
and are happiest re-inventing the wheel in APL & them bemoan the fact
that no-one is taking notice ... very 'negative'. I also sense that
there are pockets of APL activity that are the exclusive domain of the
'smarter' element of this merry band of people where the manpower
resources is drawn from an inner circle.

Equally, vendors need to learn to distinguish real growth in APL
activity from what I can only describe as 'fungal' growth.

On Aug 12, 4:30 am, Jack <jgr...@comcast.net> wrote:
>
> In my environment, it has always been risky to have our real-time
> systems have anything to do with APL, since some people would always
> be ready to blame APL whenever anything failed.

How and why would they blame APL?

I guess that was the attitude some decades ago but it is hardly
relevant today.


> I avoid this by doing
> my development and offline testing in APL; when we decide that a given
> algorithm should be put into our real-time system, we translate it to
> C and integrate it. So our missile defense customer sees nothing but
> C and C++.

So you are not giving them any chance of judging any APL and as far as
your message goes you do use APl but you will not let anyone know how
you came up with your solution.

I think it is time to drop the old idea that APL is just for certain
people and some people are dead against it.

I think this thread is basically based on the old idea that APL code
can blow up with APL errors displayed on the screen.

There are error handlings in all new modern APLs and no need for the
user to know other than the solution was done in APL and it works.

The reason for the solution was done in APL was because it was easier
and faster.


----------------
Björn Helgason
http://groups.google.com/group/J-Programming