APL in 2020 - IDE vs.Session
crishog
Visual Studio.
That imposes some constraints, obvisously,but more importantly it
detacts the developer form the "traditional" APL session.
Personally I believe that the session is one of the strengths of APL -
what do other people feel about this?
1) Should APL go with Visual Studio or any other IDE? Or should it
stick with session based development?
2) Should the session be emphasised as one of the features of APL?
3) Should other IDE features be incorporated into the session
manager? Most APLs have some workspace organizers, even if it's only
search and/or trace/walkthrough tools. We already have auto-complete
and point-and-edit from some vendors.
4) How do these ideas fit with APL scripts? IIn external files, I
imagine, I don't use them myself, so I'm not that familiar with them,
but I do use function files as a resository and part of a change
control mechanism.
All comments welcome, I'll chip in with my personal two'penneth later.
Chris
Curtis A. Jones
...
> 2) Should the session be emphasised as one of the features of APL?
I operate mostly in Dick Bowman's first mode: "Tool of thought" with
help from an assortment of toolkits. I'm very happy in the APL2
session manager, and maybe I'm just too ignorant of the benefits of
modern development environments to wish for them.
Paul Jackson, on the other hand, started his retirement by writing an
APL to use tools in .Net and Microsoft Visual Basic.
http://home.comcast.net/~paul.l.jackson/PLJsAPL/
Curtis
PGilbert
I am like you that think that the session is an advantage of
APL. This is a unique tool to debug a function and help develop
rapidly your application. If you deploy your application to customers
and there is a problem that you can't find easily from the office, you
can always go in development mode at your customer's site and while
the program is running easily find the bug. The alternative with
Visual APL would be to install Visual Studio on your customer computer
(no an easy task if you do it remotely). You can always have an
'image' of the WS saved when the bug happens and try to work on it at
the office.
PGilbert
Dick Bowman
> Visual APL has made an interesting move in making APL available within
> Visual Studio. [...]
I think the questions Chris raises here are interesting ones - and that
have significant impact on where APL will be in 2020.
There may have been murmurings before, but the first serious discussion of
this seemed to have been at Dyalog's 2003 event in Horsley - which is
nearly seven years ago with nothing apparently implemented for APL/W in
that time. So, if it's such a good idea, why hasn't it happened?
[0] I suspect that one realisation is that Visual Studio (an environment
for building code) is different from .NET (a rich subroutine library). The
gain for established APL seems to me to be in the latter rather than the
former.
[1] APL brings with it such a rich and appropriate development environment,
that it's hard to see how grafting it into another infrastructure will make
the code-development process any better for the established APLer.
Sometimes we don't appreciate how fortunate we are - another thread here
led me to take a quick peek at Haskell, which was educational.
[2] We're sometimes told that aligning ourselves with the mainstream is
going to make APL more popular among the general programming world. I'm in
something of a "show me the money" mood about this. I'd like to see a few
documented instances of this actually happening - maybe the Visual APL
people can enlighten us.
That's where I stand, and I'm in no way implying that any of the APLs we
have today couldn't be made better - but I don't see that upping sticks and
plonking APL into Visual Studio does much more than create a pile of work
to get us back to where we are now (if indeed as far as that).
For me, a message we need to get across is that APL (of whatever
description, and from wherever) has notation as a part of a complete and
effective development environment. Something to be proud of rather than
apologetic for.
Richard Nabavi
graphing/display/class edit windows etc etc which you get in a modern
APL, all designed specifically to fit smoothly into the APL language
environment) are THE most important feature of APL system - even more
important than the language itself. It is the ease of trying out
small parts of the your code, and examining data interactively, which
is key IMO.
(As it happens, I also intensely dislike Visual Studio, in particular
the daft idea of tabbed panes and docking, which means you can't
arrange windows to see the bits you're interested in simultaneously -
but that I guess is a matter of taste and not central to the
argument).
Of course, you can try to implement the Session and other related
stuff under Visual Studio (or another environment such as Eclipse),
but it's not a natural fit.
PLJ
tease a few apart.
0) The language and the development environment do not have to be
tightly bound. One can produce both and let users decide how much
then need. In can this isn't clear, I have a working example.
1) Not all APL implementations provide a development environment to
users of an application.
2) Most APL implementations which cost charge more for a development
environment. Run time environments are often free.
3) .Net provides a free development environment for anyone to use.
Check out the Express edition.
4) Remote debugging can be tedious regardless of the language or
platform you use. Please notice, I didn't say impossible, just
tedious.
5) .Net has supported true remote debugging for several releases.
This does not mean having the development environment on the user's
machine.
6) I like saving the context when a bug occurs and then running it
back at the development machine. This is not unique to APL. I've
used such programs with pre .Net versions of VB, which means more than
ten years.
7) Visual Studio 2010 has just added this feature. They call it
IntelliTrace (Historical Debugger), but it is only available within
the Ultimate edition.
8) With good problem reporting, I find I can solve most problems
without any of this. I believe the primaty thing remote viewing of a
session gives me is imporved problem reporting.
Paul
On Jun 23, 9:41 am, Richard Nabavi <micro...@microapl.demon.co.uk>
wrote:
joe_blaze
detacts [detaches?] the developer form the "traditional" APL session."
Actually using the VisualStudio IDE eliminates limitations and
constraints which have plagued the rather ancient 'traditional' APL
'session'. Superior searching, error handling, non-proprietary Unicode
text format source code, separation of source code, program state and
data, ability to compile from the command line, a universe of sample
code, inherent multi-threading, inherent and superior memory
management, coherent and transparent multi-programming-language
application system solutions, trivial to write and easily scalable web
services [WCF], xml-based GUI declarative programming [WPF], etc.,
etc.
The 'restrictions' of the .Net / Visual Studio environment are
actually security-based impositions, such as access only to virtual
memory, which make fully-managed .Net code safer. If not already
there, these 'security restrictions' will eventually impose themselves
on traditional APL.
With respect to VisualAPL, careful examination of the product would
result in the 'discovery' of the Cielo Explorer 'session' which is a
fully interactive way to run APL code either line-by-line or within a
'script' (just like running multiple lines of APL code from within a
function contained in an editable, savable workspace container).
Typically a VisualAPL programmer will design and debug their portion
of the application system using the Cielo Explorer and then
encapsulate the result into a fully-managed .Net assembly for
transparent integration with the rest of the application system
solution. Each component or tier of the application system, GUI,
business rules/calculations, data might be written using different
programming .Net programming languages.
One important purpose of VisualAPL is not to convert all traditional
APL programmers to .Net or VisualStudio, but instead to provide an APL
which can be fully integrated into the .Net environment not because
programmers can or want do this, but because some APL programmers need
to do this for their application systems to survive. For some
application system programmers, there is an imperative need to produce
fully-managed .Net code and VisualAPL provides a way for them to re-
purpose their legacy APL applications so that it can be integrated
into the mainstream. Currently VisualAPL the only implementation of
APL which can do this. More implementations will follow, some might do
it better.
joe_blaze
that you can't find easily from the office, you
can always go in development mode at your customer's site and while
the program is running easily find the bug."
Actually this scenario is only possible if each of the customers has a
properly licensed copy of the APL development environment. Otherwise
the customer of the APL programmer is entitles only to the 'runtime'
version of the APL environment.
"The alternative with Visual APL would be to install Visual Studio on
your customer computer..."
Actually remote debugging has been a part of Visual Studio for several
years.
In addition should a software developer/vendor ask/expect customers to
debug an application system? What happened to setting up a proper test
regime and test environment?
joe_blaze
discussion of this seemed to have been at Dyalog's 2003 event in
Horsley - which is nearly seven years ago with nothing apparently
implemented for APL/W in that time."
The first implementation of VisualAPL [called APL SanteFe at the fime]
was at the beginning of 2003 in Visual Studio .Net, then came the
implementations of VisualAPL for Visual Studio 2003, 2005 and 2008.
"[0] I suspect that one realisation is that Visual Studio (an
environment for building code) is different from .NET (a rich
subroutine library). The gain for established APL seems to me to be
in the latter rather than the former."
This is a good point. The attractivness of the .Net API implies at
least two possible approaches to benefiting from its richness.
The []net [Dyalog & APLX] or NetAccess [APL2000/APL+Win] approach is
traditional and has precendents such as access from APL to
legacy .dlls via []na and access from APL to ActiveX via []wi. This
approach has limited potential to expand the APL programming
community, since .Net is deemed subordinate to APL which is not
realistic. In addition with this approach there is the issue of how to
maintain pace with, or more realistically attempt to catch up to, the
continuous and significant .Net updates.
An alternative approach is to make APL accessible from .Net which is
the VisualAPL [integrate APL into Visual Studio and .Net] approach and
has as precedent APL2000's implementation of APL+Win as an ActiveX
server. The VisualAPL approach incorporates two branches, the
VisualAPL LAE [lightweight array engine] whereby C# types are extended
to provide the array-based operators of VisualAPL and the VisualAPL
Cielo Explorer [essentially the interactive 'session' of VisualAPL]
coupled with the ability to create fully-managed .Net assemblies from
VisualAPL source code. This approach makes APL one of the many
programming languages available to the .Net application system
solution developer to be selected when APL is the appropriate choice
to implement an application system component.
"[1] APL brings with it such a rich and appropriate development
environment, that it's hard to see how grafting it into another
infrastructure will make the code-development process any better for
the established APLer."
Another excellent point. The 'established APLer' is the reason that
the []Net or NetAccess approach exists. However mainstream application
system development has changed to adopt a multi-lingual style, so no
one programming language is deemed appropriate for developing every
component of an application system. Just as there are experts in
engineering, science and business who are not professional programmers
but can use APL, there are experts in GUI and database design who make
their own programming language choices and they they have good reasons
for not choosing APL for these system components. There is an element
of current fashion in this of course. Think of the concept of the GM
assembly line with a worker installs one part all day compared to the
concept of the Volvo plant where a worker is assembling an entire car.
"[2] We're sometimes told that aligning ourselves with the mainstream
is going to make APL more popular among the general programming
world. I'm in something of a "show me the money" mood about this.
I'd like to see a few
documented instances of this actually happening - maybe the Visual APL
people can enlighten us."
That VisualAPL arose from an imperative need is evident considering
that APL programming language vendors are commercial entities with
management responsibilities. That need was primarily the preservation
of legacy APL source code, valuable because it has been previously
perfected by 'domain experts', which because of end user requirements
had to be integrated into fully-managed .Net application systems as
mandated by customer management. These requirements were either
satisfied or APL could no longer be used in those application systems.
In the process of satisfying that need, other potential benefits of
the VisualAPL approach emerged, including the VisualAPL LAE
[lightweight array engine] for C# programmers, the Cielo Explorer
which is the only existing interactive 'session' for C# (as well as
VisualAPL), the non-proprietary, Unicode, text-based VisualAPL source
code which can be seamlessly incorporated into source code
repositories popular in the corporate world. These elements are
probably not going to expand the community of APL programmers in the
traditional sense or building application systems using APL only.
Instead they may become tools used by multi-lingual application system
developers.
Specific application systems incorporating VisualAPL .Net assemblies
in mainstream production systems will be mentioned in the APL2000
presentations at APL Berlin 2010. Remember though that vendors
generally face contractual disclosure restrictions limiting the
identification of customers, application system features and
implementation methodogies.
"...I'm in no way implying that any of the APLs we have today couldn't
be made better - but I don't see that upping sticks and plonking APL
into Visual Studio does much more than create a pile of work to get us
back to where we are now (if indeed as far as that)."
For an 'established APLer' who has not experienced a customer
requirement to produce a fully-managed .Net application system,
VisualAPL probably offers little beyond a curiosity. That's why
vendors spend significant resources maintaining and enhancing their
traditional APL products for truly cherished 'established APLers'.
Actually there are elements of Visual Studio and .Net which will take
the programmer far beyond what is or may ever be possible in APL, but
without a need for these benefits, they are also mere curiosities.
joe_blaze
the daft idea of tabbed panes and docking, which means you can't
arrange windows to see the bits you're interested in
For reference, although I may have misinterpreted Richard's issue, in
Visual Studio 2008 and Visual Studio 2010, right clicking on the tab
of a source code window provides the option to create an additional
vertical or horizontal window, so that, limited by screen area of
course, one can simultaneously see the programmer-selected lines of
source code in any number of class files. The richness of the Visual
Studio IDE borders on overwhelming complexity until one uses it daily
for a few weeks. One very nice feature is the ability to export and
import the IDE programmer customizations, so that when I take over the
keyboard of a co-worker, I can customize the IDE during that session
and the co-worker can restore their IDE customizations as soon as they
regain control of the keyboard.
"Of course, you can try to implement the Session and other related
stuff under Visual Studio (or another environment such as Eclipse),
but it's not a natural fit."
This is an excellent point, however Microsoft [I don't know Eclipse]
is incorporating dynamically-typed and dynamically-executed languages
into .Net and Visual Studio - consider Linq to Objects, C# 4.0 generic
extension methods, Ruby, Python and Visual Studio 2010 F#. Also the
VisualAPL Cielo Explorer is a fully interactive APL and C# session.
Curtis A. Jones
interest folks interested in IDEs.
Jeff Raskin, "The Woes of IDEs", ACM Queue, 30 July 2003
http://queue.acm.org/detail.cfm?id=864034
A major part of the piece is about the difficulty of documenting code
in IDEs - and things may have improved since 2003.
My own favorite illustration is the tale of his son:
"
My son, then in grade school, preferred to learn to program on our old
Apple II rather than on a spiffy new Macintosh. Why? Because he just
had to type “command-B” and he was in BASIC. Then he could type
PRINT “HELLO”
tap return and see
HELLO
on the display. He didn’t have to write a preamble, open a window and
specify its size, nor do any other preliminaries. He could get a
drawing up in four or five lines of code. The IDE was nearly
transparent. A simple problem had a simple solution.
"
Keep in mind "JEF RASKIN is best known for his book, The Humane
Interface (Addison-Wesley, 2000) and for having created the Macintosh
project at Apple."
Curtis
PLJ
> the daft idea of tabbed panes and docking, which means you can't
> arrange windows to see the bits you're interested in
> simultaneously..."
I may have read this comment wrong as well, but I didn't see it as an
appeal for more source windows. Instead, I thought Richard was
complaining about the default set of windows when you first start
Visaul Studio.
I've used it for so many year, I'm not sure I know how to get back to
the default way it looks when first installed. What I do know is that
the fact that the product starts a particular way does not mean the
various windows cannot be moved around. Docked is probably the
initial default, but you can undoc any of them and have them float
much like ordinary application windows.
Also, you can see multiple things at once even if they are docked. I
routinely have two docked on the right hand side. The one on top lets
me navigate the source files and the one at the bottom has the
properties for the control I've highlighted.
I usually only have the Immediate Window at the bottom. I don't lock
that one down, so it appears when I'm running and disappears when I'm
writing code. Occasionally I put a second window at the bottom to
watch expressions while I step through code.
The Immediate Window provides a place to try expressions, view and
change values before resuming execution. While it isn't where you
input functions, it is in most regards like a scrolling APL session.
Paul
PLJ
investigating what is in a file of unknown origin. Of course, I've
also spent a considerable amount of my career designing and writing
APL features.
I wrote my own APL for several reasons.
1) I just bought my daughter a 64 bit machine and I found APLse
wouldn't work.
2) I'm frequently looking at UTF-8 or Unicode files and APLse was
useless for this.
3) I wanted to be able to print fonts in Windows, and was pleased
with Phil Chastney’s efforts, see
http://www.chastney.com/~philip/
Once I got into writing APL I found a few more reasons:
1) After 41 years of using APL, and adding to it, I enjoyed
learning what is really going on.
2) I've often felt a great deal is lost because it isn't compiled,
and I found there was very little
I had to give up.
3) It became a game to find an object oriented equivalent for each
of APL's features.
I understand that people don't want to bother to learn something new
if they are pleased with what they have. I've been the say way about C
++, Java and C#. However, I don't agree that there is a large
disconnect between APL's session manager and either Visual Studio,
Eclipse or MonoDevelop. You can write code, run it, debug it, change
it, and run it again just as I did for years in APL.
What you cannot always do is change the code and restart from that
line. I must say, I never did this when I was working exclusively in
APL. Unless you can prove that you've never visited that line before,
I consider this asking for trouble.
The other issue )SAVE WS then )LOAD WS then ->[]LC
While that can be interesting, it can also be dead wrong. As soon as
APL added shared varibles, it was wrong. There are lots of live
connection possibilites in the modern computing environment, and
restarting a paused session is also asking for trouble.
Paul
PLJ
program used to do." I confess that is only because I wanted an
excuse for my own lack of interest.
There has been one improvement in having paragraphs to document
functions in Visual Studio. C# added /// in 2005, and VB added ''' in
2008. If you do this before a function, an XML framework for
documentation is provided. It is relatively easy to write and it
checks to see that the argument names agree with the current
arguments. It provides two types of results, an extractor will
produce written documentation, and when you build a .DLL the main
portion is displayed when the programmer chooses that function.
When I began writing PLJsAPL, I realized having online documentation
for all the supporting classes and functions would be helpful to
anyone using my code. However, I didn't bother to document the APL
functions and operators. Subsequently, I've learned that the only
interest in what I've done is people trying to get rid of APL.
Perhaps I should revisit that decision.
Paul
On Jun 24, 2:09 pm, "Curtis A. Jones" <curtis_jo...@ieee.org> wrote:
> I searched ACM Queue for "APL" and came across an article which might
> interest folks interested in IDEs.
> Jeff Raskin, "The Woes of IDEs", ACM Queue, 30 July 2003http://queue.acm.org/detail.cfm?id=864034
Ibeam2000
rather different needs.
From my vantage point, an IDE's primary advantage is to provide
integrated navigation, editing, and build for a code base for a
verbose compiled language. The navigation is especially important as
the code base can be extremely large. Next, an IDE provides a
seamless interface to other related features like screen composition
(as in Visual Studio) and report writing (like BIRT). As for
interactive debugging, VB6 provided something (just) approaching the
quality of APL, but the newer VB/C#/Visual Studio and Java/Eclipse,
particularly the latter, are in my meager opinion not as good. As
these IDEs were designed to support verbose compiled languages, having
a session does not make that much sense. "1+1" requires a fair bit of
code around it to produce an answer, plus compilation, load and go,
etc.
Compared to APL and other terse interpreted languages, it is not
unusual to see the code base size balloon an order of magnitude or
more. Not only is there the code, but also lots of XML things,
documentation, scripts embedded in XML, what not. The beauty of APL
was that it was so compact. You often didn't need any of that
sophisticated navigation to get around. APL also insulated the user
from the mindless tedium of the more secretarial aspects of
development. As such, an APL IDE to handle aspects of navigation may
be useful but not urgently necessary.
IDEs for APL are not that new. In the 1980s, IPSharp had Logos, a
nice tool suitable for large-ish APL applications - navigation, build,
and version control all rolled into one. I don't recall a full screen
(IBM3270) interface, but it would have been easy enough to write
something in the spirit of ISPF 3.4.
I agree that the session is one of the strengths, if not the most
important strength, of APL. Even without any full screen extras, the
idea that you can stop execution, change a variable, change the code,
restart elsewhere, etc. is something that not a lot of other systems,
if any, let you do.
In short, in my opinion, an IDE a la Visual Studio is really needed
when you have a LOT of code (i.e. 250K lines) to navigate through.
Richard Nabavi
> For reference, although I may have misinterpreted Richard's issue, in
> Visual Studio 2008 and Visual Studio 2010, right clicking on the tab
> of a source code window provides the option to create an additional
> vertical or horizontal window, so that, limited by screen area of
> course, one can simultaneously see the programmer-selected lines of
> source code in any number of class files.
No, that it not what I want. I want proper INDEPENDENT, fully-
floating windows that I can arrange as I like anywhere on (or, most
importantly, partially off) the screen - exactly the original concept
of MacOS and Windows, in fact, which mimics how you can arrange pieces
of paper on your desk.
Unless I've misunderstood (and I use it quite a lot), Visual Studio,
for some incomprehensible reason, forces you to waste large amounts of
screen space, and divide up the remaining area into either vertical or
horizontal bands, which is not necessarily what you want.
Even more strangely, you can undock a pane (such as the Output
window), but then it stays on top of the code windows, which is
completely daft.
Have I missed something? Is there some hidden 'let me arrange my
windows as I damned well want them (in position, size, and Z-order)'
option?
More generally, this sort of unnecessary constraint seems to be
getting worse in Microsoft products. Excel is super-unfriendly in
this respect - even if you start a completely new instance of the
program, it insists on docking the new window into the same rectangle
as your existing spreadsheet, so you can't see both.
PLJ
wrote:
> Have I missed something? Is there some hidden 'let me arrange my
> windows as I damned well want them (in position, size, and Z-order)'
> option?
>
> More generally, this sort of unnecessary constraint seems to be
> getting worse in Microsoft products. Excel is super-unfriendly in
> this respect - even if you start a completely new instance of the
> program, it insists on docking the new window into the same rectangle
> as your existing spreadsheet, so you can't see both.
Yes, you've missed several features. I'll respond to the Excel
behavior first. The behavior you've described is the default. If you
click on two spreadsheet files, you will open only one instance of
Excel, even though there are two items listed on the task bar.
I believe this was to avoid issues with two instances of Excel editing
the same file, but that is just a guess. To change the behavior
you've described, please do the following:
1) Observe that there are two window handles in the upper right corner
of the single Excel window. Both of these have _ [] X
2) Click on the lower [] or box icon. This will give you stacked
windows which you can arrange.
3) If you close and reopen Excel, you will notice that this becomes
the new default.
Now for the nasty part. Excel and Word have eleminated the menu,
basically obsoleting all of my knowledge of how to use these
products. To do what used to be on the Windows menu, do the
following:
1) Click View
2) Click Arrange All
3) Click Vertical or Horizontal
Given you asked for independent floating windows that you control,
this stage probably isn't something you need to know.
Paul
Richard Nabavi
>
> 1) Observe that there are two window handles in the upper right corner
> of the single Excel window. Both of these have _ [] X
>
> 2) Click on the lower [] or box icon. This will give you stacked
> windows which you can arrange.
>
Thanks Paul - I had missed that. Microsoft's abandonment of
traditional menus mean it is now pure guesswork as to where features
like that might be hidden.
(This probably isn't the right place for help on Excel - but many
thanks anyway!)
Richard