Whither Scientific & Engineering APL?
Doug White
for that. I heard that at one time all engineering students at U.
Waterloo had to take APL. Somehow I doubt that is still true. I know
there are a few dwindling pockets of APL usage out there (MIT Lincoln
Laboratory for one, JPL possibly), but 99% of the focus of the APL
community seems to be on business applications. I suspect that this is
"where the money is", but there used to be a thriving market for APL that
has apparently been abandoned.
All of the new features I hear about are focussed on Windows &
networking, most of which is of limited interest to the engineering
crowd. As far as I know, IBM's APL2 is (after a decade or two?) the only
APL with native support for complex numbers.
I'm trying (in my very limited spare time) to resurrect at least a piece
of the engineering APL world through the release of the MARTHA circuit
analysis package into the public domain (http://www.marthallama.org).
The initial vesion is configured to run in APLSE to keep the entry cost
(at least in $$) to zero.
The next step is to move it to a more capable & modern APL. I've been an
STSC/Manugistics/APL2000 user for about 25 years, but their product and
their pricing is clearly geared towards businesses with deep pockets.
Their "cheapest" product is $1,750, which gets you no support. In the
engineering world, you are competing with Matlab. It's hard to find
individual pricing for it, but I doubt the basic package is that much,
and I know you'd get support.
APL could/should be Matlab's toughest competitoin, but it's probably too
late. I view this as a serious missed opportunity that could have made a
big difference in APL's stature in the world.
Because I'm old & cranky, I refuse to give in & convert all of MARTHA to
Matlab. I need to pick a modern, well supported APL that is affordable
by individuals (not just students). The best way to make inroads in the
enginering community if you can't sneak in through the academic market is
through the radio amateur & homebrew circuit builders. Most of them work
in engineering for their day jobs, and if they have a good tool they use
at home, there is at least a chance they will bring it into their
professional work. Thus spreads the virus...
I'd appreciate feedback on what folks feel would be the best APL to use
moving forward. Here are my thoughts, based on heresay & vague
recollections:
APL2000 would be nice because I've already got an ancient copy of
APL+WIN. However, there is no way an individual is going to fork over
the cash they want for a license. I am stuck at APL+WIN version 3
because I couldn't justify the cost of support & upgrades for my personal
use, much less buy a new license. I _know_ how valuable APL can be, but
it's an impossible sell at thsoe prices for somebody who isn't familiar
with it.
Because of IBM's complex number support, they are a definite contender.
However, I'm a bit leery of their mainframe heritage. I don't know how
much of the internals are still tied to EBCDIC, auxiliary processors &
mainframe file handling concepts. I have no idea what their pricing
structure is these days.
I used MicroAPL's APL68000 in the early 1990's, and even ported MARTHA to
it. The experience was not pleasant. The code was buggy, and the
support was poor. I had to re-write their SLT conversion program myself
before I could even begin. Once bitten, twice shy. I haven't paid any
attention to their offerings since.
Dyalog looks very promising. They seem A) very active, and B) friendly
towards small users who can't afford to pay full freight to experiment.
I can't recall every hearing anything negative about their product or
service. The one annoyance is (I believe) the lack of complex number
support.
Those seem to be the big players. I'd be happy to learn if there is
something viable that I missed. I have no interest in struggling with
beta versions of open source APL's, although I wish them all the luck in
the world.
Thanks!
Doug White
Gosi
> crowd. As far as I know, IBM's APL2 is (after a decade or two?) the only
> APL with native support for complex numbers.
J has a native support for imaginary numbers
http://www.jsoftware.com/jwiki/Essays/Complex_Operations
> The next step is to move it to a more capable & modern APL.
...........
> I need to pick a modern, well supported APL that is affordable
> by individuals (not just students).
.....
> I'd appreciate feedback on what folks feel would be the best APL to use
> moving forward.
I personally use both Dyalog and J
I like them both and they both have their positive sde.
You can get J for free and Dyalog does not cost much and in many
situations (for students like me) it is free.
I started going to school (learning about growing trees and tending
woods in a University) and a side effect of that is I got Dyalog for
free.
Learning J is not so hard for anyone.
Learning the really complicated one-liners may take some time if you
are so inclined but you may never need it.
There are a number of utilities to call upon and lots of demos to copy
from so with going through some labs and using copy and paste you can
be up and running in no time.
So as far as I am concerned J is an APL.
It has imaginary/complex numbers.
It is very modern.
It is free.
If you are considering anything outside of APL then why not look at J
too?
Bob Cain
> If you are considering anything outside of APL then why not look at J
> too?
I'd bet that Doug knows about J but is interested in APL. Further, I'd bet that
everyone reading comp.lang.apl knows about J but is interested in APL.
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
Gosi
On Jun 1, 1:17 pm, gwh...@alum.mit.edu (Doug White) wrote:
> crowd. As far as I know, IBM's APL2 is (after a decade or two?)
the only
> APL with native support for complex numbers.
What about IPSA and SAX?
aleph0
Which code please ?
My experience over decades was 0 bugs in the interpreter !
External Drivers are another matter of course !
micr...@microapl.demon.co.uk
> I used MicroAPL's APL68000 in the early 1990's, and even ported MARTHA to
> it. The experience was not pleasant. The code was buggy, and the
> support was poor. I had to re-write their SLT conversion program myself
> before I could even begin. Once bitten, twice shy. I haven't paid any
> attention to their offerings since.
>
> Those seem to be the big players. I'd be happy to learn if there is
> something viable that I missed.
Doug, I think that if you are going to make negative comments in
public about our products and service, it would be both sensible and
courteous not to base your views on something which may or may not
have happened about 15 years ago. If you are indeed happy to learn if
there is something viable that you might have missed, please feel free
to download either our zero-cost APLX for Linux, or our time-limited
but full-featured Windows or Mac demo versions, and give them a try.
Richard Nabavi
MicroAPL Ltd
kai
> it. The experience was not pleasant. The code was buggy, and the
> support was poor. I had to re-write their SLT conversion program myself
> before I could even begin. Once bitten, twice shy. I haven't paid any
> attention to their offerings since.
Hmmmm.
Is it really a good idea to make those comments decades later? Your
comment will live forever thanks to Google. Well, almost.
I used APL68000 very intensivly in the eighties. Cannot report
anything regarding support since I was never in need for this. The
interpreter was stable and fast.
I looked into APLX recently. I had no chance to use it in a real
project but it looked very promising. Has not much to do with APL68000
anyway. It is like comparing APLSV with APL2.
Nancy Wheeler
The internals of Workstation APL2 are not tied to EBCDIC, or to
mainframe file handling concepts.
APL2 on all platforms uses the shared variable design model for
asynchronous data sharing between its processes. Some of those
processors are undoubtedly what you are thinking of when you say
auxiliary processors - interfaces to things like databases, files,
graphics, and GUI. The workstation auxiliary processors are written
specifically for workstations, although some of them use the same syntax
as their mainframe counterparts. We also provide synchronous call
interfaces to external programs written in APL2 or other languages, and
to things like COM and Tcl/Tk.
IBM's price structure is similar to what you quoted for the other
vendors, although a price like that would include the first year's
service contract. A tradeup price is available to licensees of Version
1 workstation APL2 products.
Nancy Wheeler
APL Products and Services
IBM
Doug White
I'm doing this on my own time, on my own nickel, and unless I see a lot
of protests from folks OUTSIDE the company, I'm not going to consider
your products. If they wanted my business, the company should have
thought of that 15 years ago. You don't win repeat business & customer
loyalty by selling a buggy product and then supporting it poorly.
Welcome to the marketplace. Yes, that was a long time ago, and the fact
that you are still in business is an indication that (hopefully) things
have improved. Do I want to play guinea pig to see if that is the case?
Not really. I don't have time to do the work I have already decided to
tackle, and the last thing I want to do is waste time on an APL
vendor that doesn't treat their customers with more respect. MicroAPL
may be wonderful, with superb support. I haven't seen anyone supporting
that case here.
I would have been OK with the occasional bug, but what really frosted me
was the attitude I dealt with when I reported them. I tried hard to come
up with simple examples to invoke the problems, and to document them
carefully. No "Thank you for pointing this out", no "We'll try to fix
that in the next release". In many instances, I don't think I even got
the courtesy of a reply. That spoke of a corporate culture I had/have no
wish to deal with. Corporate cultures don't tend to change overnight,
which is why I am leery of going down that road again. It was
particularly annoying in contrast with the excellent support I got
regularly from STSC at that time.
If _users_ think I should reconsider MicroAPL's products, I'm willing to
listen. I already explained that I have no interest in a Linux APL. If
people feel strongly that the Windows version is A) well written, B) well
documented, and C) well supported, I will at least compare it to Dyalog,
APL2, APL+Win, etc. Unless it has compelling features or benefits, I
plan on taking my business elsewhere.
Doug White
Doug White
>Doug,
>
>The internals of Workstation APL2 are not tied to EBCDIC, or to
>mainframe file handling concepts.
>
>APL2 on all platforms uses the shared variable design model for
>asynchronous data sharing between its processes. Some of those
>processors are undoubtedly what you are thinking of when you say
>auxiliary processors - interfaces to things like databases, files,
>graphics, and GUI. The workstation auxiliary processors are written
>specifically for workstations, although some of them use the same syntax
>as their mainframe counterparts. We also provide synchronous call
>interfaces to external programs written in APL2 or other languages, and
>to things like COM and Tcl/Tk.
So, if I want to do custom graphics operations, do I need to pass shared
variables to an auxiliary processor, or can I call Windows graphics
functions directly using something like []WIN system functions? Or is it
all the same sort of operation under a different name?
It's been a very long time since I had to deal with shared variables. I
had to remove a lot of shared variable operations when I ported some IBM
mainframe code to STSC's PC APL's. Fortunately, most of it was entirely
unneccessary and was easy to fix, but it left me with the impression that
SV's encouraged (or at least permitted) sloppy programming.
I'd be interested in comparison's of how the various APL's handle things
like executing Windows graphics operations. I know roughly how APL+WIN
does it, and I _think_ I understand IBM's approach, but I have no clue
how Dyalog deals with this.
Thanks!
Doug White
David Liebtag
As Nancy Wheeler said, APL2 generally uses shared variables for asynchronous
components. Primarily for historical reasons, we also still use shared
variables for some conceptually synchronous operations (like some flavors of
file IO.)
Basically, we support shared variable interfaces for:
Network communication
Graphics
GUI screen access (dialogs, listboxes, edit fields etc.)
Old 3270 style (formatted field) screen access
Some types of file IO
Database access
Stack processing
Issuing commands to the host environment
Running multiple APL2 interpreters
We provide cover functions for many of these operations so users often do
not need to fiddle with shared variables if they don't want to.
We also provide synchronous interfaces for file IO and calls to other
languages. Most of our Unix customers use these facilities to call Java
and/or Tcl to access those languages libraries for GUI screen IO.
You can call operating system APIs either using a synchronous interface or
on WIndows from our GUI processor (using shared variables) so you can use
the API in the context of either the APL2 interpreter or GUI processor
(which run in separate processes.)
If you want to try it out, you can download a free time-limited
demonstration version for Windows at www.ibm.com/software/awdtools/apl;
select the Trials and Demos link. Our documentation is available at the
Library link.
David Liebtag
IBM APL Products and Services
Nancy Wheeler
In APL2, for graphics, you can do it either way. You can use our own AP
207, and pass requests using its syntax through shared variables, or you
can call Windows graphics API's directly from APL2. You can call
Windows API's two ways - using Associated Processor 11 which is our
general interface to external routines, or using AP 145, the Windows GUI
AP. As an example, there are demos of calling the OpenGL package in the
DEMO145 supplied workspace.
Which of these you would want to do depends on what you want to
accomplish and on what platforms. Certainly graphics packages like
OpenGl are much more sophisticated than what is provided by AP 207. But
AP 207 allows you to code something entirely in APL2, that's portable
across Windows and the Unix systems we support.
On APL2 systems where the shared variable interactions were not truly
asynchronous, (VM, DOS, and some of the older MVS AP's) it's true that
the programmer could get away with things like skipping return code
references, spec'ing multiple requests without intervening waits, etc.
On the workstation systems of today, where the processors are actually
running in separate processes, that kind of coding falls apart fast.
However, for most of the AP's, cover workspaces are provided to assist
the APL programmer, removing much of the need for low-level shared
variable interaction and enforcing proper access control.
If you want to learn about how APL2 does interfaces, I would suggest
having a look at the APL2 User's Guide, which tells you all the gory
detail about this type of stuff for Workstation APL2. Look at the
introductory sections on Associated Processors and Auxiliary Processors
and then under each of those sections, and the sections "Supplied
External Routines" and "Suppplied Workspaces" you will find the detail
on each of the processors and routines we supply.
You can get the book on-line at our web site:
http://www.ibm.com/software/awdtools/apl
Click on "library" for the books and "Trials and Demos" for our
time-limited demo version.
Nancy Wheeler
APL Products and Services
IBM
AAsk
> of protests from folks OUTSIDE the company, I'm not going to consider
> your products. If they wanted my business, the company should have
> thought of that 15 years ago. You don't win repeat business & customer
> loyalty by selling a buggy product and then supporting it poorly.
> Welcome to the marketplace. Yes, that was a long time ago, and the fact
> that you are still in business is an indication that (hopefully) things
> have improved. Do I want to play guinea pig to see if that is the case?
> Not really. I don't have time to do the work I have already decided to
> tackle, and the last thing I want to do is waste time on an APL
> vendor that doesn't treat their customers with more respect. MicroAPL
> may be wonderful, with superb support. I haven't seen anyone supporting
> that case here.
Doug, I strongly believe that you are making a catastrophic error in
judgement here. APLX is a clean and resilient APL provided by a
company that spends more time planning/designing new features than in
actually building those new features.
I took part in the beta trials of V3 and then of V4 (albeit to a
lesser extent) and I know not only how short the development cycle was
but also how robust the new features were.
Like you, I use APL+Win.
AAsk
Stephen Taylor <editor@vector.org.uk>
> Keywords:
You might find helpful Beau Webber's review of APLX v4 at
http://www.vector.org.uk/archive/v233/webber.htm
Stephen Taylor
edi...@vector.org.uk
http://www.vector.org.uk/
http://aplwiki.aplteam.com/
Stephen Taylor <editor@vector.org.uk>
...
>
> I'd be interested in comparison's of how the various APL's handle things
> like executing Windows graphics operations. I know roughly how APL+WIN
> does it, and I _think_ I understand IBM's approach, but I have no clue
> how Dyalog deals with this.
>
You can see on the APL Wiki at
http://aplteam2.com/aplwiki/moin.cgi/SolitaireGame
the complete code for the game of Solitaire. It's written as a class,
which might be more of a jump into the future than you want; but one
doesn't have to use classes to write GUI in Dyalog.
(You can download and run the script in Dyalog 12, or even paste it
from the web page into the editor.)
You should be able to get a fair idea of how the GUI is built and
callbacks set and processed. I'd be glad to answer questions about it.
Stephen Taylor
s...@dyalog.com
Doug White
In article <9fb8310d-d287-42c7...@25g2000hsx.googlegroups.com>, AAsk <AA2...@lycos.co.uk> wrote:
>..... and no one makes the case for APL+Win in this forum either!
That's one of the reasons I'm looking around. I certainly haven't been
impressed by their shift in business focus post-Manugistics. I've sent
them a few questions over the years about things like what it would cost
to upgrade my Version 3 license to the latest version. I think I've only
gotten replies to about half of my queries. The impression I have is
that they are a dwindling operation that is focussing their efforts on
big corporate accounts. If that's what it takes to stay afloat, I can't
fault them for it, but I miss the days when they were willing to work
with smaller customers.
Doug White
Doug White
OK, that got my attention. I have a couple of questiosn for APLX users:
There is a LOT of web/HTML/.NET stuff that I will probably never have
much use for. Does it get in the way?
They now have a far more complex product than APL68000, which I had
issues with in the past. So:
1) How good is the documentation
2) How bug-free is the code?
3) How good is the support?
If I don't want to mess with Linux, the price is still pretty steep for
an individual non-commercial user.
Thanks!
Doug White
Doug White
>On Jun 3, 12:08 am, gwh...@alum.mit.edu (Doug White) wrote:
>>
>> I'd be interested in comparison's of how the various APL's handle things
>> like executing Windows graphics operations. I know roughly how APL+WIN
>> does it, and I _think_ I understand IBM's approach, but I have no clue
>> how Dyalog deals with this.
>>
>
>You can see on the APL Wiki at
>
>http://aplteam2.com/aplwiki/moin.cgi/SolitaireGame
>
>the complete code for the game of Solitaire. It's written as a class,
>which might be more of a jump into the future than you want; but one
>doesn't have to use classes to write GUI in Dyalog.
>
>(You can download and run the script in Dyalog 12, or even paste it
>from the web page into the editor.)
>
>You should be able to get a fair idea of how the GUI is built and
>callbacks set and processed. I'd be glad to answer questions about it.
Yikes! I'll start with a simplified version my original question
"Whither APL?".
There are (occasional) APL operators scattered about, but 90% of this is
unrecognizable to someone who has been stuck working with the APL of old.
Upon further examination, I think I must have a font issue, because there
are lots of question marks where I would expect "lamp" comment symbols.
Is there a simple way to convince Firefox to display this correctly?
Thanks!
Doug White
mps...@windstream.net
> Yikes! I'll start with a simplified version my original question
> "Whither APL?".
>
> There are (occasional) APL operators scattered about, but 90% of this is
> unrecognizable to someone who has been stuck working with the APL of old.
> Upon further examination, I think I must have a font issue, because there
> are lots of question marks where I would expect "lamp" comment symbols.
>
> Is there a simple way to convince Firefox to display this correctly?
>
> Thanks!
>
> Doug White
Doug, I am another long time apl user who finds many things
"unrecognizable" with APL today. I feel your pain. Hang in there.
And thanks for you input. I'm learning stuff I need to know from this
discussion. I still think apl is a great tool. And the systems are
real good mostly performance wise, I believe.
Marvin Smoak
kai
Doug, two questions to this:
1. Which operating system do you use?
2. Is the "APL385 Unicode" font installed on your system?
Kai
Be...@kentfolk.com
>>
> >You might find helpful Beau Webber's review of APLX v4 at
>
> >http://www.vector.org.uk/archive/v233/webber.htm
>
> OK, that got my attention. I have a couple of questiosn for APLX users:
Hi Doug,
Answers below :
>
> There is a LOT of web/HTML/.NET stuff that I will probably never have
> much use for. Does it get in the way?
Not at all - don't use it, you do not see it.
>
> They now have a far more complex product than APL68000, which I had
> issues with in the past. So:
>
> 1) How good is the documentation
Excellent off-line manuals - I used to print them out as ring-bound
books.
I still read the upgrade documentation very carefully, but :
Now I mainly use the on-line help - right click on a construct and
select help - excellent.
Also most features have simple example code that you can run, and then
hack - many of my functions and applications based on the newer
features started that way.
See : http://www.lab-tools.com/instrumentation/StereoPanorama/ which
was initially just based on example code to display an image (needs
updating - APLX now can use calls on ImageMagick to do really fancy
graphics operations).
>
> 2) How bug-free is the code?
APLX seems to be totaly robust - A few small bugs crept in with the
Beta version of V4, but were dealt with immediately - I run multi-
hundred MByte workspaces, sometimes simultaneously, some dating back
decades, just usually suspending at night, until XP keels over from
lack of resources (suspect IE7 ?). I have not had a problem with the
current version in the months I have been running it. With version 4 I
did do a )copy into empty clean workspaces - first setting )symbols,
with some of my decases old workspaces, to make sure I had clean
copies.
>
> 3) How good is the support?
Excellent - make a good suggestion (well I belive that including
things like Regular Expression parsing is a good idea) and with luck
you may get it at the next upgrade.
More simply - something not clear from the documentation, an answer
usually within hours (occasionally day or two).
>
> If I don't want to mess with Linux, the price is still pretty steep for
> an individual non-commercial user.
I agree but so are todays' prices for music and beer, and I can't do
without either (and I would have much less time for either of those
without APLX).
>
> Thanks!
>
> Doug White
cheers,
Beau Webber
Stephen Taylor <editor@vector.org.uk>
An article on the Vector site
http://www.vector.org.uk/archive/display.htm
offers advice on browser viewing problems.
I don't know if you find this encouraging, but I returned to APL in
2001 after a 15-year break from programming. One can catch up. And I
enjoy the writing better than I ever did before. Not only is the
development environment better, the language is even more expressive.
Enjoy!
Stephen
Doug White
>> Is there a simple way to convince Firefox to display this correctly?
>
>Doug, two questions to this:
>
>1. Which operating system do you use?
Win XP, SP2
>2. Is the "APL385 Unicode" font installed on your system?
Not unless it got installed while I wasn't looking.
I found the one on the Vector site, and installed it. That works MUCH
better. I can't say I can read the code very well, but it is much more
recognizable as being APL than yesterday.
Thanks!
Doug White
Doug White
Thanks! I got the Unicode font installed, and it looks a lot more
familiar now.
Doug White
Ibeam2000
and works more or less the same way form composition does. It's quite
easy and yields good results. In general, you open a form, draw
lines, draw text, fill a pattern, and so on. You can set different
fonts, line thicknesses, and dashing patterns. Best of all, if you
want the graph to appear on say a Word document, you do the same thing
but write to a metafile object instead, then link the metafile to the
document when done.
Alternatively, a higher quality approach would be to write APL code to
generate Post Script. It's a little bit of a learning curve to be
able to produce Post Script but is no harder than driving a plotter at
the device level. (HPGL comes to mind) If you don't have Post Script
printers, there are a lot of software products which deal with Post
Script, notably recent versions of Word have a built-in EPS (extended
post script) converter, Ghost Script, and so on. By definition, using
Post Script from APL is system independent, as all you are doing is
writing a text file. Post Script itself can be fairly human readable.
Lastly, OpenGL is the end of the rainbow, or close to it, when it
comes to graphics. OpenGL is a forerunner of Microsoft DirectX.
(DirectX is a good example of Microsoft marketing practice, it
duplicates the functionality of OpenGL and bundles in features to play
sound, read the mouse and keyboard, etc). Evidently there are 2D
instructions for OpenGL suitable for doing more usual charting, but
the problem is what to do with the picture once you have it on the
screen - probably you can extract the bitmap and print and save it,
but for dealing with graphics as part of a document, usually you have
better results with vector graphics. I don't thing OpenGL will dump
out a metafile, but have never used this part.
For 3D graphics, OpenGL requires you to create a 3D mesh, wrap a skin
around it, set lighting sources, set a camera location, move the
camera position, move the object, and so on. All of this is handled
by the OpenGL API, from APL, you need to know how to call the
functions, usually with something like []NA. Except for the
particulars in calling external library functions from APL, OpenGL
would be APL system independent.
J.B.W....@kent.ac.uk
> Under Dyalog APL, line-based graphics is based on their Windows model
> Best of all, if you
> want the graph to appear on say a Word document, you do the same thing
> but write to a metafile object instead, then link the metafile to the
> document when done.
>
> Alternatively, a higher quality approach would be to write APL code to
I have found the postscript approach most useful - I have a graph
drawer with a script driven digram drawer (2d/3d - just looks at the
data structure it is given) - that has a number of output formats
including metafile, but the only ones I have bothered to turn on in a
while are the screen and postscript ones.
If you want graphs in MS Word then I reccomend importps - there is a
free download to test it, but you need to pay a few pounds for the
full version - or get pstoedit for a whole set of tranformations :
www.geocities.com/wglunz/importps/
www.pstoedit.net/pstoedit
Best installed as part of ghostscript and ghostview/gsview (both
free), if you want to have postscript viewers etc. :
pages.cs.wisc.edu/~ghost/
www.ghostgum.com.au/
In general publishers like postscript graphs, and I find that I have
no grief from them, they appear in my papers (which I prepare in
Latex) just as I intended them. Also, pstoedit transforms them to pdf
so they are easy to share with people who do not have postscript
tools.
cheers,
Beau
ddooner
My background is also engineering (mechanical) where the ability to
conveniently use complex numbers can be prized. My core focus is
building a software package for gear design. To date, I gauge my package
to be somewhat involved with geometry and rating. As you describe, I too
want to make my efforts available for use as I think I have a new, useful,
and valuable approach to a classical and mature subject.
My original development was with classical APL (Harris). I used APL to
help develop and demonstrate some mathematical principles. I continued
development over the years and now have many APL functions (500). With
numerical results being my overarching objective, I never ventured outside
the workspace or interfaced with other packages. In order to make my
efforts available for use today, I need to extend my programming abilities
beyond classical APL. Over the past years, I have worked on a GUI to help
showcase my results (over 300 functions). I am using APL2 for
development. APL2 is available without cost for teaching and research
since I am with a university. I am very satisfied with the product and
the service has been terrific. To illustrate my satisfaction, I purchased
a personal license to continue GUI development! Like you, on my own nickel
(teacher's salary). I anticipate that you can generate your entire package
with APL2 and make available for distribution (without user costs) using
runtime APL2.
As for Matlab, I am amid Matlab fanatics (professors and students). C is
the default required programming language for engineering students in the
university I am with, yet many students default to Matlab for engineering
homework/research assignments whereas some students use Excel, Mathcad, or
Mathmatica (ok, shows the level of assignment). In fairness to Matlab, the
language is advertised in American Society of Engineering Education and
American Society of Mechanical Engineers; I anticipate likewise for other
engineering disciplines. Matlab seminars are given regularly on campus
each semester.
I feel APL has a lot to offer engineers today and in the future. I would
like to see the APL community grow and I am willing to orient students
towards APL. Being results driven, I do not mandate any language and
allow students to decide individually the language of choice to ascertain
results. Granted, I do make some unnecessary comments on language of
choice when students struggle. Wise or not, APL is my choice of languages
for coding. As you know, you can lead a horse to water but you cannot make
it drink.
David
--
Message posted using http://www.talkaboutprogramming.com/group/comp.lang.apl/
More information at http://www.talkaboutprogramming.com/faq.html
ddooner
Doug White
In article <e381dd49-d6de-4abd...@a1g2000hsb.googlegroups.com>, J.B.W....@kent.ac.uk wrote:
>On Jun 7, 6:48=A0am, Ibeam2000 <Ibeam2...@gmail.com> wrote:
>> Under Dyalog APL, line-based graphics is based on their Windows model
>>=A0Best of all, if you
>> want the graph to appear on say a Word document, you do the same thing
>> but write to a metafile object instead, then link the metafile to the
>> document when done.
>>
>> Alternatively, a higher quality approach would be to write APL code to
>> generate Post Script. .....
>
>I have found the postscript approach most useful - I have a graph
>drawer with a script driven digram drawer (2d/3d - just looks at the
>data structure it is given) - that has a number of output formats
>including metafile, but the only ones I have bothered to turn on in a
>while are the screen and postscript ones.
>
>If you want graphs in MS Word then I reccomend importps - there is a
>free download to test it, but you need to pay a few pounds for the
>full version - or get pstoedit for a whole set of tranformations :
> www.geocities.com/wglunz/importps/
> www.pstoedit.net/pstoedit
>
>Best installed as part of ghostscript and ghostview/gsview (both
>free), if you want to have postscript viewers etc. :
> pages.cs.wisc.edu/~ghost/
> www.ghostgum.com.au/
>
>In general publishers like postscript graphs, and I find that I have
>no grief from them, they appear in my papers (which I prepare in
>Latex) just as I intended them. Also, pstoedit transforms them to pdf
>so they are easy to share with people who do not have postscript
>tools.
I haven't had to use it in a while, but I believe "pstoedit" isn't
compatible with Office 2007. The IT nazis at work decided that we should
all "upgrade" to Office 2007. That broke at least a half dozen things I
do regularly to get my work done. Productivity as a whole has dropped
considerably while folks hunt for commands in the new menu structure.
Doug White
Doug White
vess_...@hotmail.com
opportunity to demonstrate APL to the engineers, but I have been in
software, sales, banking, financial modeling and entrepreneurship for
decades, and the engineers no longer want me nor give a glance at my
resume.
Go figure.
It is hard for me to grasp. A Space Shuttle Designer like myself on
unemployment for years, and years ........
Meanwhile, I have started on my own new project! A book! "APL for C#
Programmers" One chapter written. Hard work! LOL. Stay tuned.
Vess Irvine
STSC (APL*Plus guys) alumni.
jk
<vess_...@hotmail.com> wrote in message
news:ae66c004-d8dc-48f5...@j22g2000hsf.googlegroups.com...
[...]
> Go figure.
>
> It is hard for me to grasp. A Space Shuttle Designer like myself on
> unemployment for years, and years ........
>
> Meanwhile, I have started on my own new project! A book! "APL for C#
> Programmers" One chapter written. Hard work! LOL. Stay tuned.
Hi Vess,
That's hard.
Go in something people understand. E.g. chewing gum. Sold by the
billions for two quarters a piece - make a dime on each ... (like Nico
Mak did with his WinZip stuff)