APL - Alive and Well!
Morten Kromberg
1. Some APL vendors never successfully made the transition from the
mainframe to the PC.
2. Some APL programmers with grey or white hair only see others with
the same hair colour, and do not know any of the many young APL
programmers who joined the community recently
3. Unlike in 1980, it is very hard to find a consulting job where all
you need to know is how to programme in APL.
4. It is almost impossible to interest Computer Science departments in
APL.
5. If you work in a traditional software department you are unlikely
to be allowed to start a new project in APL: Software engineers still
don't think APL looks like anything they learned at school and that it
is "broken" (the fact that they can't deliver software on time, on
budget and to spec is only just starting to shake their faith that
they are doing the right thing).
Over the past few weeks, we have seen a number of people post messages
to comp.lang.apl, expressing the belief that APL is dying, due to
various combinations of the above. Fortunately, it is simply not the
case: APL and other array languages are well established in certain
niches. The value of solutions based on these technologies is measured
in billions of dollars per year, and their existence is NOT
threatened.
It IS a hard time to be an APL programmer. I think it is fair to say
that most of us once chose APL because it offers a very high level of
abstraction, allowing us to very quickly turn ideas involving data
manipulation into executable code. But today, the platforms upon which
we are expected to deliver software are changing rapidly, and we
expected to take interest in the very issues that we picked APL in
order to avoid getting snarled up in. In particular, user interfaces
and databases now require extensive (layers of) toolkits, and these
layers are shifting under our feet. XAML, Silverlight, Virtual
Machines of one description or another. ODBC, JDBC, ADO, ADO.NET. We
are expected to embed APL software in browsers which are not allowed
to use local storage, even though this is obviously a bad idea for
software which is used to analyze huge amounts of data. Remember CICS?
It's the same story all over again: Traditional web development
techniques are another example of mainstream technology trying to beat
APL into a mould which was created for lightweigh transactional
systems. Keep your data in an SQL database, look at one record at a
time...
Architectures get more and more complex. If you are a computer
scientist or software engineer, rewriting the software every few years
in order increase the beauty of the code IS what you love - why you
chose the job. If you are an APLer, chances are you find all this
depressing. Fortunately, while the higher layers of tools are still in
a state of flux, the lowest levels of the new infrastructures ARE now
stabilizing. We should soon see tools and interfaces from vendors that
allow APLers to integrate solutions with popular platforms without all
of us having to go out and learn the details of the latest advances.
The big APL vendors of old, staffed by people who loved APL and often
had the same problem-oriented (rather than technology-oriented)
attitudes, were slow to realize the impact of the technology shift.
Consulting, timesharing and licensing revenues dropped sharply as the
PC took over from the mainframe. Almost no marketing has been done
since the late 1980's, and no new educational materials have been
produced - with the notable exception of those written for J. The
traditional vendors were caught in a negative feedback loop, from
which several did not pull out.
Accelerating the decline was the fact that much of the early revenue
was a function of a huge but fundamentally temporary business in the
1970's and 1980's, where all large companies were building their own
software for just about every purpose. APL was one of the best tools
on the market for this pioneering work. However, the production of -
and competition in the market for - the "shrinkwrapped" software which
replaced most of the APL systems written in this period is a different
game entirely: Key factors are a cheap and easily recruited/fired
workforce, documentation, procedures, and marketing. I think that most
APLers that I know would not want to work in these jobs, which the
industry is trying to turn into outsourceable "unskilled" jobs, even
if APL was an acceptable technology to these businesses.
We can argue about whether this or that system which was converted
would have been cheaper to maintain and more useful if the technology
had remained APL. I have personally witnessed many extraordinarily bad
business decisions to replace APL systems, made by management teams
with absolutely no understanding of what they were doing (some of whom
are now back in the fold as customers, I am happy to report). But in
many situations, the business logic which caused managers to replace
the use of APL by more "predictable" workforces and technologies are
"sound business decisions". It is in the nature of APL to be used as
an "executable specification language": APL is often used as much to
discover the specification as to implement the system. Having an
executable spec makes "agile" interaction with the user much easier
than with many other technologies.
In many businesses (the financial industry being the prime example),
the specifications never quite settle down. Fortunately, APL
interpreters are highly efficient and capable platforms, which support
the use of APL in high volume production applications. Although APL is
dynamic and interpreted, APL-coded solutions in this market often
perform better than traditional solutions. I believe that this is
because the layered approach of traditional software development tends
to drive the development in the direction of reuse of overly general
components, which need to be bent a bit too much and therefore perform
badly. Too many layers in an object hierarchy lead to inefficient
code, even after compilation.
So yes: There ARE many large APL (based) businesses which have died -
but the APL family of languages will not die unless they are one day
replaced by something MORE CAPABLE in the areas where APL is strong.
This is quite simply because it provides unique value in a number of
situations. The market that these situations represent is rapidly
growing, and very poorly served by other technologies, so there is
significant room for growth for APL, J, K and other new dynamic and
array-oriented software development methodologies. The mainstream
software industry is only just starting to shift its focus from
administrative systems to analytical software, and we have a 40-year
head start. If you look at trends in modern programming languages,
they are heading in OUR direction: Dynamic languages, Type inference
in languages like C#, growing use of "Reflection" (inspecting types
and doing different things depending on what was passed to you), all
of these are signs that mainstream technology is waking up to the fact
that if you want to write code quickly, and especially if it needs to
do anything analytical, you need the kind of flexibility that APL
already has.
This would be a VERY BAD TIME to start moving the language towards
where everyone else is now!
This message is too long already, so I'll better try to wrap up. I
admit that:
a. The golden age of cushy (mainframe) consulting jobs will not return
b. Trying to sell APL in head-to-head competition with Java and C# for
traditional "software construction" projects is almost impossible
c. APL is pretty useless in a Computer Science department. It is not
the goal of these institutions to teach the art of extracting
specifications or the construction of working software so APL has
little to offer them (OK, I admit have a chip on my shoulder: I
dropped out of CS pretty early on after discovering that only 15-20%
of the marks were given for arriving at a working solution).
However, unless you specifically want to achieve one of the above
three "goals", there is no reason to despair. The market for turning
complex ideas into working software is growing rapidly, and all the
brilliant ideas that Ken Iverson and the early APL developers put into
the language are more relevant than ever before.
Today, the successful (growing) users of APL seem to be entrepreneurs
(or entrepreneurial businesses) with novel ideas that they want to
bring to the market ahead of the competition, or before conditions
change. If you want to be an "APL Consultant" (internal or external),
you must learn how to wrap APL as components to be embedded in - or
communicate with - mainstream components. You must learn about SQL and
XML and other emerging technologies, and how to help the "Domain
Experts" who have the ideas and the skill to write APL for the
application core.
In rare cases, one person can do all of the above (for a while), but
generally we need to build teams combining domain- and technical
experts. The vendors must do what they can to make the jobs of both
these groups easier, and also explain the mechanics to managers who
need to understand how to make this work.
At Dyalog, we firmly believe that we can safely ignore the decline of
the APL market which followed the "unnatural blip" in the 70's and
80's (even though some old APL systems are still in their final death
throes). It is a false signal with respect to the fundamental value of
the technology. The truth is that APL is actually still ahead of its
time. It is our good fortune that we never had a mainframe business,
as it means that for us, APL has been always been growing - and that
growth now seems to be accelerating. We believe that we can further
accelerate the growth through:
i. Working hard to improve integration with platforms (Microsoft.Net,
Mono, perhaps Java). We've been working hard for the last several
years, with the addition of the .Net interface, Object Orientation and
finally Unicode support in v12.0, we feel we have made big steps in
the right direction. Although it is one of the fundamental values of
our product that people who are not software engineers have a complete
package which allows them to build all the components of an
application, we must also support large organizations who want to
build multi-layered, and "multi-tiered" applications using a
combination of teams skilled in APL and other technologies.
ii. Producing new books, training materials, "code patterns" - and
provide new tools for sharing code between APL users. Expect to see
the first results of this work to appear during 2008.
iii. Cultivating contacts in the dynamic/agile programming
communities, where we believe we will soon see the first openings for
marketing APL directly to developent teams (as opposed to going via
the users first).
We don't think it will be long before we'll be back in the business of
"cold calling" certain types of development teams to sell APL as a
modern technology. We are already working to start new academic
programmes using APL (it is too early to say when we will succeed with
this, but we are optimistic).
So hang in there! If you have good ideas, we'd love to hear them. But
PLEASE, PLEASE don't post messages proclaiming that "APL is dead" to
comp.lang.apl. We have shipped hundreds of educational and non-
commercial licenses over the last 18 months. Some of these new users
might be reading this news group! Don't be surprised if these people
do not contribute to comp.lang.apl. As things are today, if they
should ever read more than a few messages on this forum, they need to
be made of stern stuff to stay with us!
If you can only see grey- or white-haired APL developers and would
like to see some new APL users, come to the Dyalog User Meeting in
Denmark, October 12-15th 2008. More information about this even will
soon appear at http://www.dyalog.com/dyalog_08.htm.
Morten Kromberg
Dyalog Ltd.
Gosi
>
> Morten Kromberg
> Dyalog Ltd.
Brilliant!
The very first really positive article in a long long time.
I have marked my calender for a visit to good old Denmark in october.
Steve
for Array Programming Languages.
Dick Bowman
55998a...@w7g2000hsa.googlegroups.com:
> [... deleted ...] It is in the nature of APL to be used as
> an "executable specification language": APL is often used as much to
> discover the specification as to implement the system. Having an
> executable spec makes "agile" interaction with the user much easier
> than with many other technologies.[... deleted ...]
Indeed - I think something we all need to more positive about is letting
the projects we've created/prototyped be "productised" and to move on to
the next opportunity.
Dick Bowman
I'm wondering about "The APL SWAT Team".
Personally I've passed the grey/white hair stage and am beyond hair
categorisation.
Back in the olden days some larger organisations used the "Information
Centre" as a way to bypass the time-consuming practices of the
traditional IT department. Not sure whether they still exist, but I
think the concept has legs - contrast for example the processes needed
to get software integrated into the UK NHS IT infrastructure against the
practitioner's need to get something clinically important working "right
now".
I can see sense in Morten's argument about the many facets of IT
technology versus the "can only do it in APL" school, yet I think
there's a way ahead that caters for some of us fossils.
Personally I've no interest in spending my waking hours doing things
like writing DLLs and other low-level stuff. I'm happy to use them -
but I don't want to write them.
Equally I don't think I want to give intellectual credibility to tasks
like writing HTML - we have to think of these things as "givens", in the
same way that we can assume basic literacy (although that might be
generous in the case of some computer programmers I know).
What I'm alluding to is whether some larger organisations need a "SWAT
Team" who can move in, target hot-spot areas where the business/purpose
can be moved forward by some special projects, and be motivated to move
out/on to new projects and problems once the situation is stabilised
(there's a solution that can serve as a specification for production-
line code). Rather than try to grow roots and become the embedded
technology. "My APL system is being replaced" is good news because
there's something else for me to do.
And maybe there are independent SWAT Teams who act as gunslingers for
hire.
Naturally I think APL (as a rapid/agile development language) is central
to this - to make it work the APL specialist needs backup, either people
who can produce the interface stuff or (better) a good selection of pre-
written tools. Dyalog's SQAPL is a good example of this - it solves the
first-tier problem (I need to read from and write to SQL-based
databases), and I don't care how it achieves it (right now it uses ODBC
- a future SQAPL2 that uses .COM or .NET would be useful to me, but I
don't have to write it). Another example is the discussion on
strong/weak typing - I don't worry myself about that, but Dyalog Classes
let me define data (structures) that behave in controlled ways - seems
useful.
So, one thing I'm concluding is that we really ought to be creating for
ourselves the toolboxes we want for this sort of environment.
MikeJ
On May 11, 9:14 am, Morten Kromberg <mk...@dyalog.com> wrote:
> It DOES seem to be true that:
>
> 4. It is almost impossible to interest Computer Science departments in
> APL.
>
VERY TRUE, I tried for years.
However, the basic strengths of the Array oriented languages for
analytical computing is being
recognized by non-academic practitioners.
>
>
> So yes: There ARE many large APL (based) businesses which have died -
> but the APL family of languages will not die unless they are one day
> replaced by something MORE CAPABLE in the areas where APL is strong.
> This is quite simply because it provides unique value in a number of
> situations. The market that these situations represent is rapidly
> growing, and very poorly served by other technologies, so there is
> significant room for growth for APL, J, K and other new dynamic and
> array-oriented software development methodologies. The mainstream
> software industry is only just starting to shift its focus from
> administrative systems to analytical software, and we have a 40-year
> head start. If you look at trends in modern programming languages,
> they are heading in OUR direction: Dynamic languages, Type inference
> in languages like C#, growing use of "Reflection" (inspecting types
> and doing different things depending on what was passed to you), all
> of these are signs that mainstream technology is waking up to the fact
> that if you want to write code quickly, and especially if it needs to
> do anything analytical, you need the kind of flexibility that APL
> already has.
>
> This would be a VERY BAD TIME to start moving the language towards
> where everyone else is now!
>
BUT, it is a very good time for thinking about how to take the best of
the Array oriented
language ideas and incorporate them into toolkits for doing agile
computing.
Morten's remarks on this are on target.
I have spent a lot of time thinking about the "best" combination of
programming language
ideas and array oriented programming from both a theoretical and
practical viewpoint.
I do not see any magic combination that will sweep the programming
world emerging soon.
>
> c. APL is pretty useless in a Computer Science department. It is not
> the goal of these institutions to teach the art of extracting
> specifications or the construction of working software so APL has
> little to offer them (OK, I admit have a chip on my shoulder: I
> dropped out of CS pretty early on after discovering that only 15-20%
> of the marks were given for arriving at a working solution).
>
The software engineering side of computer science departments rarely
teach or do research on the sort of rapid prototyping and
evolutionary
application design that APLers have experience with.
My work on Q'Nial was an effort to get CS people interested in the
class
of language that supports such activities. I failed to gain very many
converts.
The key aspect that APL, J, K, and Nial have is the ability to achieve
a complex
result as a sequence of functional transformations on data structures.
Programming becomes the task of placing data into initial structures
and transforming
them by selecting the appropriate functions in the correct order.
This is not as simple as it sounds because:
- we may need more than one data structure
- we may need to retain (or simply name) intermediate results
- we may have to add functions not provided in the predefined set
- we may need to make choices between functions to apply
- we may need to repeat sequences of function applications
All of the array languages provide a way to meet the above needs.
The hard part is to teach students how to solve problems with this
functional paradigm.
It requires the mental ability to hold the data structure in one's
mind and to imagine how
particular functions will transform it. Some students are better at
this than others.
My guess is that most avid array language programmers do this quite
easily and find it
strange that others have difficulty doing it.
The efforts by Dyalog to improve educational materials and examples of
solving problems
using APL are important for achieving the goal of making the array
style of programming
more widespread.
I have been reading comp.lang.apl for the past year or so (since I
announced the Q'Nial open
source project). I think it is important to use it as a place to share
ideas about how to use
APL and J and news on related products.
Mike Jenkins
David Liebtag
> 1. Some APL vendors never successfully made the transition from the
> mainframe to the PC.
I can't resist paraphrasing Mark Twain, "Reports of the death of the
mainframe have been greatly exaggerated."
:-)
David Liebtag
Jack
> Morten Kromberg <mk...@dyalog.com> wrote in news:2fa86857-67d4-4400-bb5a-
>
> > [... deleted ...] It is in the nature of APL to be used as
> > an "executable specification language": APL is often used as much to
> > discover the specification as to implement the system. Having an
> > executable spec makes "agile" interaction with the user much easier
> > than with many other technologies.[... deleted ...]
>
> Indeed - I think something we all need to more positive about is letting
> the projects we've created/prototyped be "productised" and to move on to
> the next opportunity.
I completely agree.
Gosi
>
> 1. Some APL vendors never successfully made the transition from the
> mainframe to the PC.
>
> 2. Some APL programmers with grey or white hair only see others with
> the same hair colour, and do not know any of the many young APL
> programmers who joined the community recently
It would be very interesting to hear from those young APL programmers.
Why they started using APL,
how they heard about it,
how they use it?
Steve
wrote:
How feasible would it be for an entrepreneur to rent a virtual
mainframe (with APL2 and perhaps DB2 installed) on one of your big
boxes that uses few resourses at modest cost in the beginning, but
could scale seamlessly to large volume should business demand it?
With the right cost structure, this might be attractive to both IBM
and new startups.
# Steve
David Liebtag
I don't know; I'm not in the rent-time-on-a-mainframe end of the business.
Let me ask around and see if I can get you an answer.
David Liebtag
Gosi
wrote:
Would it not be possible to set this (APL2 and DB2) on a Linux machine
and then if it grows too big then just move it to another computer and/
or operating system?
micr...@microapl.demon.co.uk
I agree with everything you say, and our experience here at MicroAPL
is consistent with what you are arguing. Indeed, we launched APLX as
a whole new APL product range as recently as 2002, so we've put our
money where our mouth is!
The only big thing I would add is to emphasize the fact that it is
much easier now for different software environments to interact, than
it was ten or fifteen years ago. So our philosophy is not to try to
write APL interfaces or implementations for everything, but to
concentrate on providing easy-to-use (and preferably cross-platform)
interfaces to all the good stuff which is already out there. (This
ties up with the other recent comp.lang.apl thread about "software you
can't do without"). This is actually an opportunity for APL. Seven or
eight years ago, I was pessimistic about the feasibility of keeping up
with the Operating System vendors. There was just so much content in
Windows or MacOS, and it was added to so often, that implementing easy-
to-use APL 'bindings' (through system functions or APs or Quad-WI) was
clearly impractical. So I could see a scenario where lots of OS-
supported features which users would like to access could not
realistically be offered to the APL programmer.
Now it is much easier; in APLX, we can access almost any software or
library written in C#, Visual Basic, Java, Ruby, and potentially other
object-oriented languages, as well as accessing databases very easily
and supporting image manipulation etc etc. So we're no longer at a
disadvantage compared with, say, the C# programmer. In fact, it is as
easy to access Microsoft's .Net libraries from APLX or Dyalog APL as
it to access them from C# - arguably, easier, because you can play
with them interactively and there's less verbosity.
This is not to say that there isn't also a case for easy cross-
platform implementations of the more important external interfaces.
So, for example, you can use Microsoft's .Net classes for handling
regular expressions, but in APLX we also provide a cross-platform
string-search (and replace) system function, which provides an easier-
to-use alternative more than adequate for the vast majority of
applications.
The goal, as I see it, is to make things as simple as possible for the
APLer (who typically is not a computer professional and does not want
to wade through, say, Microsoft's massive .Net class hierarchy),
whilst providing the more general interfaces for the cases where the
APLer needs to go deeper.
So our roadmap with APLX is very much based on that principle -
interfaces to external software will continue to be a major feature
for us.
Richard Nabavi
MicroAPL
Gosi
Is it fair to say that all (most?) APL vendors have a growing user
base?
What is the platform where the APLs grow the most?
Is APL possibly growing on all platforms?
Jane Sullivan
<ea9d8284-fe6f-4f56...@x35g2000hsb.googlegroups.com>,
Gosi <gos...@gmail.com> writes
Doesn't Linux run on mainframes these days?
--
Jane Sullivan
Ted Edwards
> I can't resist paraphrasing Mark Twain, "Reports of the death of the
> mainframe have been greatly exaggerated."
Note that the same quote has been paraphrased as, "Reports of the demise
of OS/2 have been greatly exaggerated.
Ted
Steve
wrote:
> In message
> <ea9d8284-fe6f-4f56-a4a5-9c5dccd8f...@x35g2000hsb.googlegroups.com>,
Yes on both counts. You could do it all on Linux, but scalability
wouldn't be seamless. ISPs sell virtual machine accounts on fairly
powerful shared Linux boxes with specified resource allocations (CPU,
RAM, disc, network bandwidth). They ensure that your virtual machine
keeps running, but you administer your virtual machine. When you
outgrow your allocation you can increase it or move to a dedicated
box. If you outgrow that, you might move to multiple boxes, clustered
or distributed. You can run Linux VMs on mainframes, so you could
eventually move there.
What I was thinking of was more like Google's App Engine (http://
code.google.com/appengine/docs/whatisgoogleappengine.html), but base
upon APL rather than Python.
# Steve
Gosi
What is Dos/2?
David Liebtag
z/OS, but APL2 does not run on either of those platforms. We run on the
CMS/VM and TSO/MVS mainframe systems.
David Liebtag
IBM APL Products and Services
tom7777777
...The mainstream software industry is only just starting to shift its
focus from administrative systems to analytical software ...
a study
Gosi
wrote:
If you could clarify that please.
APL2 runs under Linux.
Linux runs under z/VM.
So either APL2 runs under Linux on z/VM or it does not.
I have a hard time seeing how APL2 would be excluded from Linux under
z/VM
David Liebtag
Different hardware platforms have different instruction sets. When you run
a compiler on a particular hardware platform, the compiler generates object
code that uses the instruction set of that hardware platform. Intel PCs and
mainframe systems have different instruction sets.
In order to run a compiled program on a particular hardware platform, you
must compile the program using a compiler that is designed to run on that
hardward platform.
The version of APL2 that runs on Linux is a written in C. So, it must be
compiled separately on each hardware platform. We have compiled it on Intel
PC's. We have not compiled it on z/VM. (We could, but we haven't.)
Does that make it clearer?
Gosi
wrote:
If you say so I take your word for it.
I thought that since APL2 runs under Linux that Linux would take care
of the hardware issues.
But as you say then if you need to you could.
I remember some time ago I got a 370/PC with VM running on it.
I could install APL2 on it and I did but had a hell of a problem
because I had no APL chars on the screen.
m...@privacy.net
05/14/2008
at 07:17 AM, Gosi <gos...@gmail.com> said:
...snipped...
>I remember some time ago I got a 370/PC with VM running on it. I could
>install APL2 on it and I did but had a hell of a problem because I had no
>APL chars on the screen.
Are you referring to a P/370 system? If so, that is my environment and I
can tell you that APL2 runs well and you have full APL support in the
PC/3270 terminal emulator for access to it. If you were using an ASCII
terminal emulator that is another story entirely. Although there are some
ASCII emulators with APL support most lack it. I have used the emulator
build into APL*PLUS/PC successfully, but I know of no other ASCII emulator
off-hand with APL support.
-- Dave
-----------------------------------------------------------
dhdurgee<at>verizon<dot>net
-----------------------------------------------------------
Gosi
> In <148af6cf-bcda-4c3c-b630-e00dc029c...@l42g2000hsc.googlegroups.com>, on
My experience with 370/PC card in it is from around 1986 and I am
pretty sure it has improved a lot since then.
I was very disappointed at the time because I thought I was getting a
personal mainframe with a complete set of options.
m...@privacy.net
05/14/2008
...snipped...
>My experience with 370/PC card in it is from around 1986 and I am pretty
>sure it has improved a lot since then.
>I was very disappointed at the time because I thought I was getting a
>personal mainframe with a complete set of options.
OK, I think I see where you are coming from. The 370/PC was before the
P/370 and the P/390 and had more limited functionality.
David Liebtag
> of the hardware issues.
Conceptually, operating systems are standardized sets of services for doing
system level things like reading and writing files and registering and
waiting for types of events. Some of these things are hardware related and
Linux does indeed handle them identically on all hardware platforms.
However, CPU instructions are at a lower level than the operating system.
For example, most CPUs support some kind of instruction for copying bytes
from one location to another. But, the actual instructions processed by
different CPUs may be different binary values. As a made-up example, on one
system the copy-bytes instruction may be four bytes containing the value
0x12345678 followed by 2 four byte addresses followed by a four byte length.
On another system the copy-bytes instruction may be eight bytes containing
the value 0x8765432112345678 followed by 2 eight byte addresses followed by
an eight byte length. The compiler is responsible for converting the call
to the C runtime library's memcpy routine into the binary instruction that
is appropriate for the target system. If you compile on the system that
uses the two byte 0x5734 instruction, the resulting binary module will not
run on the system that expects to see the four byte 0x34126756 instruction.
At a real world level, the biggest difference between Linux on Intel PCs and
Linux on z/VM is that Intel machines use ASCII and z/VM uses EBCDIC. This
means that they use different byte values to encode characters. For
example, in ASCII, blank characters are encoded as the binary value 0x20; in
EBCDIC blanks are 0x40. I'm pretty sure you can run Linux in ASCII mode on
z/VM. But, since many files on z/VM already contain EBCDIC data, it may be
more useful to run it in EBCDIC mode. So, if you compile a program, like
APL2, to run on Intel PCs and to use ASCII, if you tried to run it on z/VM
in EBCDIC mode (which you can't because the intrsuction sets are different)
the program would almost certainly get very confused because all the input
data that it is written to accept in ASCII would arrive in EBCDIC. These
are the kinds of issues that one has to consider when porting to various
hardware platforms.
Don't you love being an APLer so you don't have to worry about this crap?
:-)
Gosi
wrote:
So one of the biggest obstacle (ASCII vs EBCDIC) should be eliminated
once everything is Unicode - right?
It is not just APL that has(/had?) characterset problems.
I have been fighting codepages/characters/fonts kind of problem for a
very long time and have been/am looking forward for Unicode to solve
them for decades now.
I do not know how many utilities I have to change codes between
codepages.
J, Dialog and APL2 all have support for Unicode so the APL community
is yet again long way ahead of everyone else.
David Liebtag
> once everything is Unicode - right?
Yes, but I doubt that will happen anytime soon.
Think about your PC, or Mac,,,, I'll bet that most of your text files are
ASCII, not Unicode. This is true on most systems; plain text files are
almost always saved using the hardware's native codepage. On Intel,
PowerPC, and Sparc this is ASCII. On IBM mainframes, it's EBCDIC. Not only
that, but which ASCII and which EBCDIC codepage is used to encode the data
usually depends on the geographic region in which it was encoded.
Unicode is good for moving data between systems. But there simply is not
yet any overriding reason for everyone in the world to convert all their
text data to Unicode. If you were a CIO, would you recommend that your
company rewrite all your software to use Unicode? As long as there legacy
software that uses native codepages (which is the vast majority of the
software in the world), there will be continuing use of ASCII and EBCDIC.
Finally, the codepage question is just one example of hardware differences.
There are others including IEEE versus 370 representations of floating point
data and big-endian and little-endian storage of data in memory. All of
these issues are surmountable. It's just a question of resources. But the
point is, they all make it impossible to run binary object code on all
hardware platforms.
Gosi
wrote:
Never say never.
Remember the 370/PC twenty years ago?
When I complained of APL2 not giving me what I wanted on it I was more
or less told I would never be able to run a complete mainframe on my
PC.
The mainframes then were not very big (internally that is) compared to
todays PCs.
What they did have and still do is a hell of a lot of better software
and operating systems than the PCs have had.
I wanted then and still do to have a seemless environment all the way
from the smallest to the biggest.
I think that Unicode is a very important stepping stone towards that.
I am sure you are right that this will take a long long time.
It probably was a huge mistake to introduce Dos and more or less
abandon everything that was known about good practice in programming.
We are still suffering from that mistake today.
What would have happened if we had just got scaled down/cheaper
mainframes back then?
jk
"Gosi" <gos...@gmail.com> wrote in message
news:2a5c1ee7-2d0b-4673...@s50g2000hsb.googlegroups.com...
On May 14, 4:31 pm, "David Liebtag" <DavidLieb...@vermontel.net>
wrote:
> > So one of the biggest obstacle (ASCII vs EBCDIC) should be
> > eliminated
> > once everything is Unicode - right?
>
Now I remember ... I worked on a "type ball" terminal using Time Sharing
from Elsevier Neth, the developers, or refiners of ADI*PLUS (Gijsbrandt,
Noordwijkerhout 1980?). Then we turned to VAX/VMS - good choice by the
way - (on advice of some High&Mighty) and I had to translate from
EBCDIC
to ASCII. I wrote an APL routine for that. Foggy foggy past ...
David Liebtag
> mainframe (with APL2 and perhaps DB2 installed) on one of your big
> boxes that uses few resourses at modest cost in the beginning, but
> could scale seamlessly to large volume should business demand it?
> With the right cost structure, this might be attractive to both IBM
> and new startups.
Steve,
I talked to someone who is knowledgeable in this area (actually my brother
who also works for IBM) and got an answer for you.
The short answer is,,, Yes. That is definitely possible.
IBM, and many IBM business partners, offer time on mainframes. However,
although IBM and our partners do sell raw machine time, what IBM really
offers is the expertise to help manage businesses and their information
systems. By leveraging IBM's and IBM's business partner's expertise,
companies can make more effective IT investments than just buying raw
machine time. We offer a wide range of business management "solutions".
These range from raw machine time, to hosted application software, to
complete outsourcing of the development, operation and management of
software and hardware systems. The correct solution depends on many things
including the client, the industry, and the business model. Finding the
correct solution is part of what IBM can help you do.
In answer to your specific question though, if you're just talking about
buying raw machine time, it's probably not a very good business proposition
either for you or for IBM. Machines are cheap. If you just want to run a
single application or two, like APL2 and DB2, you're probably better off
just buying a machine with the correct size to fit your current needs. (Of
course, we can sell you machines too. :-)
Having said all that, if you want to pursue it, I would be pleased to help.
You can write me and I will have someone in your area contact you directly.
Steve
wrote:
Thanks, David.
That tells me that IBM isn't offering what I had in mind, which is
neither purchase of raw machine time, nor IBM services expertise as
currently packaged. I'm thnking of an APL version of Google AppEgine
(http://code.google.com/appengine/) targeted at APL developers who
have an idea for a web application, but don't have the skills, time,
or inclination to set up a web front end, storage, backup, 24x7 uptime
support for the application they know they can write in APL.
This may not make business sense for IBM/APL2, and it remains to be
seen if Google's venture will be successful, though I suspect it
will. It provides a very low barrier to entry for development and
initial deployment (essentially zero cash), making it easy to try out
business ideas that may be wacky, or might be a gold mine. There are
a lot more Python programmers than there are APL programmers and it
should contribute to their ad revenue based business model. Of course
there are a lot more Java programmers than Python programmers, but
Java is far less suited to rapid application development by a small
team (maybe of one) than Python or APL.
I do think this is a potential opportunity for an enterprising APL
vendor.
Regards,
Steve
David Liebtag
But, you're right. IBM does not offer a Google AppEngine type product with
APL2 support. If you want to build a business like that, I'm sure we could
bundle the machine and software components you'd need to run it. :-)
Gosi
> I'm thnking of an APL version of Google AppEgine
> (http://code.google.com/appengine/) targeted at APL developers who
> have an idea for a web application, but don't have the skills, time,
> or inclination to set up a web front end, storage, backup, 24x7 uptime
> support for the application they know they can write in APL.
>
> This may not make business sense for IBM/APL2, and it remains to be
> seen if Google's venture will be successful, though I suspect it
> will. It provides a very low barrier to entry for development and
> initial deployment (essentially zero cash), making it easy to try out
> business ideas that may be wacky, or might be a gold mine. There are
> a lot more Python programmers than there are APL programmers and it
> should contribute to their ad revenue based business model. Of course
> there are a lot more Java programmers than Python programmers, but
> Java is far less suited to rapid application development by a small
> team (maybe of one) than Python or APL.
>
> I do think this is a potential opportunity for an enterprising APL
> vendor.
This is interesting.
"App Engine provides a runtime environment that uses the Python
programming language. Other programming languages and runtime
environment configurations are being considered for future releases."
APL should be considered for future releses.
Google is basically now starting with zero users and aims at having
millions in a short time.
And all for free, language, support and storage.
Hard to compete against such options and probably better to join in if
possible.
Steve
wrote:
Darn! You would ask me to put my money where my mouth is.
# Steve
David Liebtag
I am delighted by your response.
Thanks.
David Liebtag
Curtis A. Jones
wrote:
> > I thought that since APL2 runs under Linux that Linux would take care
> > of the hardware issues.
> Don't you love being an APLer so you don't have to worry about this crap?
I do indeed! Just blew a few minutes once again trying to see if I
could persuade Internet Explorer here in my SJSU office to render APL
from UTF-8 in another topic. Curtis
phil chastney
>
> I remember some time ago I got a 370/PC with VM running on it.
what was that like, performance wise?
I've got a lot of respect for VM, and the story that it was lashed
together by engineers to meet their immediate needs, instead of going
through a "proper" design-and-build process just chimed perfectly with
what I believe to be true and good
/phil
Gosi
VM is still my favorite platform.
REXX, CMS and APL2 is a hell of a combination.
phil chastney
> <snip>
>
> So one of the biggest obstacle (ASCII vs EBCDIC) should be eliminated
> once everything is Unicode - right?
were you thinking of going with ASCII-based Unicode or EBCDIC Unicode?
> It is not just APL that has(/had?) characterset problems.
>
> I have been fighting codepages/characters/fonts kind of problem for a
> very long time and have been/am looking forward for Unicode to solve
> them for decades now.
>
> I do not know how many utilities I have to change codes between
> codepages.
life should be a little easier now because, from Day One, Unicode aimed
to provide complete round-trip conversion for all existing 8-bit
standards, so conversions from Code_A to Code_B can now be done via Unicode
there's a shedload of codecs out there to do that sort of thing -- I
think many of them come from ICU ( http://www.icu-project.org/ )
> J, Dialog and APL2 all have support for Unicode so the APL community
> is yet again long way ahead of everyone else.
"catching up fast" might be more appropriate
phil chastney
so true
I remember trying to write a REXX routine which called XEDIT under CMS
to provide data editing facilities to an APL*Plus program interfaced to
Oracle
I had a semi-circle of manuals laid out on the floor around the desk
but a day or two's hard work had it sorted (I could manage a day or
two's hard work in those days -- I needed the money)
like most database projects, it wasn't the technical aspects that gave
the most problems -- it was other people
/phil
Jack
I remember those days more or less fondly, at least in the mid 80's.
Then somebody got the bright idea of putting a "terminal concentrator"
between the users and the mainframe. This meant that the system
response time increased from about .15 seconds to about .30 seconds.
Thus my fingers were hitting keys before the system was ready to
accept the inputs. Drove me nuts. The PC fixed all that.
Jack
Gosi
http://en.wikipedia.org/wiki/VM/CMS
"Early releases of VM continued in open source, and today are
considered to be in the public domain. "
"VM remained an important platform within IBM, used for operating
system development and time-sharing use; but for customers it remained
IBM's "other operating system". The OS and DOS families remained IBM's
strategic products, and customers were not encouraged to run VM. Those
that did formed close working relationships, continuing the community-
support model of early CP/CMS users. In the meantime, the system
struggled with political infighting within IBM over what resources
should be available to the project, as compared with other IBM
efforts. A basic "problem" with the system was seen at IBM's field
sales level: VM/CMS demonstrably reduced the amount of hardware needed
to support a given number of time-sharing users. IBM was, after all,
in the business of selling computer systems."
"In the early 1980s, the VM group within SHARE (the IBM user group)
sought a mascot or logo for the community to adopt. This was in part a
response to IBM's MVS users selecting the turkey as a mascot
(hilariously chosen, according to legend, by the MVS Performance Group
in the early days of MVS, when its performance was a sore topic). In
1983, the teddy bear became VM's de facto mascot at SHARE 60, when
teddy bear stickers were attached to the nametags of "cuddlier
oldtimers" to flag them for newcomers as "friendly if approached". The
bears were a hit and soon appeared widely"
It was common tosay that VM had two people behind it while MVS had
5000.
So how could VM be comparable or even better?
Similarly Rexx is basically a one man job.
http://en.wikipedia.org/wiki/Mike_Cowlishaw
"As such, REXX is considered a precursor to Tcl and Python."
phil chastney
I'm not sure that the original assertion is correct
and I'm not sure that the article you quoted relates to Morten's assertion
the piece about PriceWaterhouseCooperAndTheRestOfTheWorld reported what
some people perceive about the relative importance of Data Warehouses
and SOA -- but both of these are delivery methods, and part of the IT
infrastructure
I thought Morten was talking about software that supports actual
business activities
mind you, I'm not sure I understand Morten's original assertion, because
my experience has been that analytical software was at least as
important as administrative software: Materials Requirements Planning,
project control, dedicated mainframes running the company's linear
programs -- all commanding resources in excess of those needed to run
the company payroll
there again, I may be mistaken . . . /phil
Bob Cain
> I do think this is a potential opportunity for an enterprising APL
> vendor.
There has always been great opportunity for an enterprising APL vendor. There
probably always will be. :-)
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
Gosi
> This is quite simply because it provides unique value in a number of
> situations. The market that these situations represent is rapidly
> growing, and very poorly served by other technologies, so there is
> significant room for growth for APL, J, K and other new dynamic and
> array-oriented software development methodologies. The mainstream
> software industry is only just starting to shift its focus from
> administrative systems to analytical software, and we have a 40-year
> head start.
One positive thing is that there have recently been a lot of positive
postings to c.l.a
There are more postings to c.l.a this month than in many years.
I think it is great to see how the interest is picking up and it looks
like APL is on a path to find its right place.