Re: Vector themed issue: How to wear sheepskin

On Aug 31, 7:50*am, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> Gosi wrote:
> > On Aug 30, 6:57 pm, neit...@marshlabs.gaertner.de (Martin Neitzel)
> > wrote:
> >>> any ISO APL2 (not the best name, incidentally)
> >> Luckily, the standard naming scheme for standard revisions would rather
> >> call it "ISO APL-bis", avoiding the ambiguity Gosi already fell prey for.
>
> >> * * * * * * * * * * * * * * * * * * * * * * * * * * * * Martin
>
> > I did mean APL2
>
> then you don't need ISO, surely?

We are hardly going to have any meaningful ISOAPL so why not
acknowledge the fact that we do have (at least) two very different
APLs that are never going to merge.

They have not been able to go together for 30 years and go
increasingly in different directions.

So ISOAPL2 and ISOSAX (and possibly ISOJ) would replace ISOAPL if
there is going to be any ISOAPL.
Most APLs are more or less APL2 or in that direction.
It is confusing at best to think of all APLs to be one at the core.
At least that core is very small compared to the rest.

Gosi wrote:
> On Aug 31, 7:50 am, phil chastney
> <phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
>> Gosi wrote:
>>> On Aug 30, 6:57 pm, neit...@marshlabs.gaertner.de (Martin Neitzel)
>>> wrote:
>>>>> any ISO APL2 (not the best name, incidentally)
>>>> Luckily, the standard naming scheme for standard revisions would rather
>>>> call it "ISO APL-bis", avoiding the ambiguity Gosi already fell prey for.
>>>> Martin
>>> I did mean APL2
>> then you don't need ISO, surely?
>
> We are hardly going to have any meaningful ISOAPL so why not
> acknowledge the fact that we do have (at least) two very different
> APLs that are never going to merge.
>
> They have not been able to go together for 30 years and go
> increasingly in different directions.
>
> So ISOAPL2 and ISOSAX (and possibly ISOJ) would replace ISOAPL if
> there is going to be any ISOAPL.
> Most APLs are more or less APL2 or in that direction.

I think that's a pretty fair summary of the situation

I doubt if there will be another ISO standard -- there's no point -- so
dialectic differences are something that will still need to be explained
away, and that's the way of the world

/phil

Dick Bowman <dick@dickbowman.org.uk> wrote:
> The direct beneficiaries of a designed standard would be the users -
> gaining the freedom to move their code from one vendor's product to
> another. There might be benefit further down the line from a general
> market growth - but I can't really see the vendors rushing into any new
> initiative that might take away their current USPs.

I think your last sentence concerning why the vendors aren't going to
make an initiative is a bit of fear, uncertainty, and doubt.

First off, there aren't that many vendors, where would the customers
go, except between them? I would assume the value encapsulated within a
vendor's implementation about equals the other's vendor's implementation's
value, otherwise customers _already would have moved_ to the best one.

Second, if all of the vendors agreed to the standard and implemented it,
then there is no reason (other than extreme licensing cost improvement or
whatever) for customers to move away from a system that already works. The
current customers are still going to have their codebase and they aren't
going to change it to meet the standard, because they don't have to.
The standard exists for new customers, not ones that already exist. It
is up the the vendors to make themselves attractive to new customers.

Third, how could one possibly believe that increasing awareness and
general market growth of APL could be anything other than exactly what is
needed? If more people use the language, more people will use a vendor's
product, if some customers shift a bit between implementations, new
customers will replace them.

Later,
-pete

Peter Keller wrote:
> phil chastney <phil.hates.spam@amadeus.munged.eclipse.co.uk> wrote:
>> the problem was, and is, generalised arrays: arrays of arrays
>
> If this is the proverbial elephant in the room, then, for the purposes
> of the ease of the user of APL pick the one that is best, or collaborate
> and create s superset, and everyone moves toward it. Get the vendors
> into a room and don't come out until a solution has been found.

a superset of the _facilities_ (the semantics) would be possible, I
suppose, but what about the syntax? -- what do you do when a
particular symbol is used by different vendors to represent different
functions?

offend everybody equally, perhaps, then everybody's customers have to
rewrite existing code?

I can't see that happening

OTOH, you could, perhaps, simplify the competing definitions, because
enclose and disclose are not normally required at the programmer level

the 'map' function much loved of functional programmers provides a case
in point: APL, too, has a map function, but it is subsumed into the
rules of function application, and damn few APL programmers are aware of
its existence

it's such a shame that enclose and disclose weren't similarly subsumed
into the rules of application

whether it is still possible to do so, without damaging existing syntax,
is another matter -- it's been a while since I looked at this closely

/phil

I think Pete has this exactly right. In fact, it chimes with
something we've been talking about recently with the APL Wiki people -
namely, how to have a site which includes examples which are, as far
as possible, compatible with all the main APLs.

Two points in particular:

1) Yes, this has to be driven by the vendors, with help from
interested users. The full ISO standard business is just too
cumbersome and expensive.

2) There is already a very large subset of 'second generation' APL
features (i.e. stuff not in the original ISO standard) which is common
to most of the modern APLs. The old generalised-array wars are over,
in that most vendors are APL2-compatible in this respect. All the
main actively-promoted APLs are now largely compatible with the core
APL2 language standard, although they each have a lot of proprietary
extensions. In the specific case of APLX, we have a near 100%
compatibility with APL2's language spec (apart from complex numbers).
Dyalog and APL+Win also implement large subsets of the same spec (with
their own extensions of course).

This is not to say that there aren't a lot of important differences,
and important omissions in some APLs. For example, everyone other
than IBM implements component and native files (⎕FTIE ⎕NTIEetc) in a
pretty-much compatible way. GUI programming varies considerably -
there's little compatibility, except between APLX and APL+Win.
Structured-control keywords are largely compatible across APLs, but
not implemented by IBM.

However, the fact that there are big differences in some areas is not
a reason not to try to agree on common approaches on things where we
do have a lot in common. The first thing that needs to be done is (as
Pete says) to document what the main APLs already DO have in common.
That in itself would act as an incentive to vendors. If you're the
only vendor not to include some feature, then, provided it's not too
hard to implement, that's a big incentive to add it.

Richard Nabavi
MicroAPL Ltd

microapl@microapl.demon.co.uk wrote:
> 2) There is already a very large subset of 'second generation' APL
> features (i.e. stuff not in the original ISO standard) which is common
> to most of the modern APLs. The old generalised-array wars are over,
> in that most vendors are APL2-compatible in this respect. All the
> main actively-promoted APLs are now largely compatible with the core
> APL2 language standard, although they each have a lot of proprietary
> extensions. In the specific case of APLX, we have a near 100%
> compatibility with APL2's language spec (apart from complex numbers).
> Dyalog and APL+Win also implement large subsets of the same spec (with
> their own extensions of course).

The Scheme standard, IMHO, is created by the vendors almost as an ideal
of what scheme should be, while being as close to what is commonly
implemented. Often some vendors don't implement edge case aspects of it,
like complex numbers, and they state that as such. After some quality
time, usually with open source developers helping, they move their
implementations to implement closer and closer to the standard. This is
the whole point of not making it ISO or whatever, the vendors basically go
at their own pace to converge towards what they agreed upon. It doesn't
immediately have to conform, so the work can be, and is in practice,
amortized over time.

> This is not to say that there aren't a lot of important differences,
> and important omissions in some APLs. For example, everyone other
> than IBM implements component and native files (?FTIE ?NTIE etc) in a
> pretty-much compatible way. GUI programming varies considerably -
> there's little compatibility, except between APLX and APL+Win.
> Structured-control keywords are largely compatible across APLs, but
> not implemented by IBM.

Stuff like GUI programming and whatever should probably be left out of
the standard. The standard should start simple and just be a language
and standard library, if one exists at all, definition. Even in Scheme,
something as simple as file io was left intentionally vague. The point is
that as the vendors create interesting proprietary extensions, the best
of the best are often picked for the next standard revision. Vendors
have the option to remain stagnant, but everyone in the scheme culture
wants to see the language get mainstream, so they do the work and move
themselves closer to the new standard.

It is almost as if the mere *existence* of a vendor agreed upon standards
document is enough for new customers to simply want to follow it because
"it is good practice to follow standards". If they need something outside
of the standards, then fine, it is localized to what they need it for
and can put a cost on how to move their code to another vendor if it
becomes necessary. Unless there is a grave catastrophic failure of the
vendor or a desire for a feature they absolutely require immediately,
they will never move.

> However, the fact that there are big differences in some areas is not
> a reason not to try to agree on common approaches on things where we
> do have a lot in common. The first thing that needs to be done is (as
> Pete says) to document what the main APLs already DO have in common.
> That in itself would act as an incentive to vendors. If you're the
> only vendor not to include some feature, then, provided it's not too
> hard to implement, that's a big incentive to add it.

Making this document is free and easy for those skilled in APL. It can be
the seed of something much better. The more vendors that put their name
on it, the more popular it'll be. For the first revision, the vendors
have to do nothing other than say "We confirm to this standard." because
they already do! Free publicity!

As for APL functions that are complementary in nature between two APL
vendors, it is simple as a command line flag or checkbox to implement
conformity to the standard. Things don't have to change for customers
unless they themselves initiate the change. For new people, they simply
run the implementation with the appropriate flag for the standard they
want to use, and it just works. Also, as long as the standards evolve
every 5-10 years or so with new language features or standard libraries
being added that came from the spawing pits of customers and users,
customers perceive the language is "alive", which is extremely important
for an entire host of reasons.


Once you get to the stage where useful non-vendor specific tools can
be written in APL conforming to the standard on a unicode compliant
editor, good things will happen. As a participant in the open source
community, I've noticed that people who spend their (valuable) free
time writing a piece of code want to see it live on and will work to
make that happen. If it is tied to the dialect of a single vendor,
they get somewhat ansty because if that vendor keels over, all of their
spent free time was for nothing. If the code was written to a standard,
then they know "with a bit of hammering" they can make their code work
with another vendor, they will, and the code will live on to be added to
the growing pile. In fact, open source people (in the realms of scheme)
often port their codes to the top 5 vendors because they want the code
itself to be widely used and know that since they followed the standard,
it isn't much work to do. This helps the vendors by allowing them to
have reams of libraries/applications to offer to new users, who, in turn,
will write more libraries/applications, making the language more useful,
more entrenched, more needed in the nices the users put them into.

Thank you.

-pete

On Sep 1, 4:24 pm, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:
> micro...@microapl.demon.co.uk wrote:
> > 2) There is already a very large subset of 'second generation' APL
> > features (i.e. stuff not in the original ISO standard) which is common
> > to most of the modern APLs. The old generalised-array wars are over,
> > in that most vendors are APL2-compatible in this respect. All the
> > main actively-promoted APLs are now largely compatible with the core
> > APL2 language standard, although they each have a lot of proprietary
> > extensions. In the specific case of APLX, we have a near 100%
> > compatibility with APL2's language spec (apart from complex numbers).
> > Dyalog and APL+Win also implement large subsets of the same spec (with
> > their own extensions of course).
>
> The Scheme standard, IMHO, is created by the vendors almost as an ideal
> of what scheme should be, while being as close to what is commonly
> implemented. Often some vendors don't implement edge case aspects of it,
> like complex numbers, and they state that as such. After some quality
> time, usually with open source developers helping, they move their
> implementations to implement closer and closer to the standard. This is
> the whole point of not making it ISO or whatever, the vendors basically go
> at their own pace to converge towards what they agreed upon. It doesn't
> immediately have to conform, so the work can be, and is in practice,
> amortized over time.
>
> > This is not to say that there aren't a lot of important differences,
> > and important omissions in some APLs. For example, everyone other
> > than IBM implements component and native files (?FTIE ?NTIE etc) in a
> > pretty-much compatible way. GUI programming varies considerably -
> > there's little compatibility, except between APLX and APL+Win.
> > Structured-control keywords are largely compatible across APLs, but
> > not implemented by IBM.
>
> Stuff like GUI programming and whatever should probably be left out of
> the standard. The standard should start simple and just be a language
> and standard library, if one exists at all, definition. Even in Scheme,
> something as simple as file io was left intentionally vague. The point is
> that as the vendors create interesting proprietary extensions, the best
> of the best are often picked for the next standard revision. Vendors
> have the option to remain stagnant, but everyone in the scheme culture
> wants to see the language get mainstream, so they do the work and move
> themselves closer to the new standard.
>
> It is almost as if the mere *existence* of a vendor agreed upon standards
> document is enough for new customers to simply want to follow it because
> "it is good practice to follow standards". If they need something outside
> of the standards, then fine, it is localized to what they need it for
> and can put a cost on how to move their code to another vendor if it
> becomes necessary. Unless there is a grave catastrophic failure of the
> vendor or a desire for a feature they absolutely require immediately,
> they will never move.
>
> > However, the fact that there are big differences in some areas is not
> > a reason not to try to agree on common approaches on things where we
> > do have a lot in common. The first thing that needs to be done is (as
> > Pete says) to document what the main APLs already DO have in common.
> > That in itself would act as an incentive to vendors. If you're the
> > only vendor not to include some feature, then, provided it's not too
> > hard to implement, that's a big incentive to add it.
>
> Making this document is free and easy for those skilled in APL. It can be
> the seed of something much better. The more vendors that put their name
> on it, the more popular it'll be. For the first revision, the vendors
> have to do nothing other than say "We confirm to this standard." because
> they already do! Free publicity!
>
> As for APL functions that are complementary in nature between two APL
> vendors, it is simple as a command line flag or checkbox to implement
> conformity to the standard. Things don't have to change for customers
> unless they themselves initiate the change. For new people, they simply
> run the implementation with the appropriate flag for the standard they
> want to use, and it just works. Also, as long as the standards evolve
> every 5-10 years or so with new language features or standard libraries
> being added that came from the spawing pits of customers and users,
> customers perceive the language is "alive", which is extremely important
> for an entire host of reasons.
>
> Once you get to the stage where useful non-vendor specific tools can
> be written in APL conforming to the standard on a unicode compliant
> editor, good things will happen. As a participant in the open source
> community, I've noticed that people who spend their (valuable) free
> time writing a piece of code want to see it live on and will work to
> make that happen. If it is tied to the dialect of a single vendor,
> they get somewhat ansty because if that vendor keels over, all of their
> spent free time was for nothing. If the code was written to a standard,
> then they know "with a bit of hammering" they can make their code work
> with another vendor, they will, and the code will live on to be added to
> the growing pile. In fact, open source people (in the realms of scheme)
> often port their codes to the top 5 vendors because they want the code
> itself to be widely used and know that since they followed the standard,
> it isn't much work to do. This helps the vendors by allowing them to
> have reams of libraries/applications to offer to new users, who, in turn,
> will write more libraries/applications, making the language more useful,
> more entrenched, more needed in the nices the users put them into.
>
> Thank you.
>
> -pete

Thanks to Pete, and.... all, for this discussion. It interests me
very much.

I have many opinions on how APL might evolve and benefit more folks;
too many to state any of them now. I believe now that apl is moving
toward openness. And I feel that it is good movement.

I recently started a blog where I'll put some of thoughts and my
experieces/obversations with APL. My post for today:

"September 1, 2008
Moved the new system to my desk today.
Filed under: Uncategorized — mpsmoak @ 6:02 pm Edit This

Recent linux fedora with the planet-ccrma music/video package, using
kde, firefox, … About to install aplx.

There’s an very interesting conversation going on at comp.lang.apl
newsgroup. Good discussion of standards and open source, and the needs
of users and vendors.

See posts 75 99 at comp.lang.apl, the topic is “Vector themed issue:
How to wear sheepskin”

To me, it is moving toward open-standard and open-source. (J is, I
believe. How J deals with user needs is documented. And the source is
available at a fee. )

Think I’ll point them to:

http://www.sutor.com/newsite/blog-open/?p=2508

in particular points 6 and 7."

Bob Sutor says in his resume (or somewhere) that one of his first
programs in High School was in APL.

Again thanks for the discussion.

The blog at mpsmoak.wordpress.com. Just started it a few days ago.

Marvin Smoak aka Marv

>
>
> I also think the link to other skills (domain knowledge) is important.
> Many of our customers are recruiting many people each year to write
> APL - they generally find that they get the best results by hiring
> smart kids who know the business (finance, chemistry, whatever) and
> quickly teaching them APL. You can teach an actuary APL in rather less
> time than you can teach a most programmers statistics. This generally
> gives you someone who is a good inquisitive programmer, and the team
> then needs to be seeded with a small number of people who can sew up
> the sheepskin: People who understand APL (and how the APLers think),
> but are stronger on the software engineering side. This recipe seems
> to work well for a number of our customers and one of the things we
> need to do is describe to managers "how to run a professional software
> development unit which includes APL developers". But the number of
> domain experts required is generally an order of magnitude greater
> than the number of "APLers who are also software engineers".
>
> We hope that we will be able to engage computer clubs and schools in
> the future. However, our current feeling is that a complete set of
> modern training materials which address the interests of a new
> generation of potential APLers must be developed, before there is much
> chance that we can attract people via the internet. We have a new APL
> Tutorial (700 pages!) written by Bernard Legrand in the works, it will
> become available in the next few months, and we will continue to
> invest in materials steadily in the years to come.
>
> With luck, we'll be able to help continue to generate excitement in
> the years to come!
>
> Morten

Morten, You are quite right that there needs to be a bridge between
inquisitive programming and software development programming. I too
suspect that the computer science department is not a good place to
promote APL, after all, they see their goal as developing theoretical
bases for computing, and training for software development. But where
do you introduce APL in the college curriculum without incurring the
wrath of the computer science department? I am delighted to hear of
your forthcoming tutorial material and the student competition.
The main point of my too wordy comments was to ask how are future APL
knowledgeable people being trained. You are right that getting people
who are expert in other fields exposed to and using APL is an
excellent way to go. But let me raise a word of caution. I have
seen some of the APL code written by “other field “ folk who were
exposed to the rudiments of APL. It was not good APL. It often
consisted of hundreds of lines of branching/looping code buried in
niladic functions. Not that I am faulting them, after all, many of
them came from a Fortran, Basic, or other sequential programming
language background. Yes some came with no programming background at
all. This is what often happened when these very competent people
were told to go read up, self study, and learn APL. Maybe it doesn’t
matter if the result gets the job done. On the other hand, it
certainly doesn’t show off the strengths of APL. I have seen such
packages written for personal use migrate. Others saw that it was
good and useful to them too. Gradually the APL package became more
widely distributed until it came into the view of the IT folk who
could not maintain it and then ridiculed it.
I know all of you APL vendors are surrounding the core APL language
with many fine features to interact with the alien nonAPL world, but I
worry that these core features of the APL language are always being
assumed too much. Of course, I am old fashioned but I believe a
concentrated APL class presentation emphasizing the features and
strengths of APL is a strong approach. It worries me that those
coming into APL don’t get well grounded in its strengths; array
thinking, AND an understanding and use of the rich set of functions
and operators supporting it. I guess I would be more comfortable were
there a broad set of ways to learning APL; online tutorials, textual
self studies, textbooks, instructor lead classroom courses,
specifically focused tutorials, etc. I know Dyalog is trying and that
is great. All of the APL vendors support and surround the core APL.
I wonder if there could be a vendor neutral group that could develop
some basic core APL educational material. This certainly could be a
place where a college computer science department could step in. One
initial area would be the distribution of the APL idioms.
Ray Polivka

Peter, Thank you for your thoughtful and thought provoking comments.
I’m sure there will be plenty of comments. It is great to get
comments from someone looking into the APL world. I shall make some
of my personal comments to your seven points.
On point one, what sort of applications are of interest to the “main
stream” programmer? There are interesting and challenging problems in
banking and insurance applications besides paying pretty well.
Earlier in this blog on Aug 24th I discussed “inquisitive” programming
verses software development programming. Perhaps you had in mind
inquisitive type programming. It is basically personal problem
solving. It is a fine way to learn what a programming language can
do. I believe that is what you were doing creating a tic-tac-toe
programming. Perhaps you are not aware that the APL community
produces two quarterly APL publications: Vector – the excellent
publication out of England, and Quote Quad from the ACM’s Special
Interest Group on APL. Unfortunately the ACM shut down SIGAPL so I
don’t know the future of Quote Quad. I mention Quote Quad since in
the last three issues I posted a problem for the readership to solve.
If you wish to try some APL problem solving look at them and their
solutions. I believe those Quote Quads are online. If they are not,
I can provide you copies. In fact I can offer you additional
challenges. I have taught APL for many years. As a result I have
been collecting problems and exercises. The original purpose of them
was to offer the student who had finished an introductory APL course
additional APL practice. Would problems and their solutions like this
be of interest to programmers like yourself?
On point two, yes APL is dense, but that is the nature of APL. It is
no different than reading a sheet of Mozart’s music or a Chinese
newspaper. You have to learn the language. How do you introduce APL?
Actually there are two parts to that question. They are “how do you
introduce APL for those who wish to learn about it?” verses “How do
you introduce APL for those who wish to use it?” .Over the years, I
have had the opportunity to coauthor three books on APL. They are
focused on those learning to use APL. I am still looking for the
“Holy Grail” of introducing APL to those who wish to know more about
it.
On point three, can you give me an example on what would draw folks to
APL? You mention “little pieces of cookbook-y software”. Each of the
vendors of APL provides public libraries full of interesting
functions. Also because of the conciseness of APL, there are
collections of idioms. For example IBM produced a 75 page document of
idioms. The Finnish APL community also produced an extensive list of
APL idioms. You speak of using APL+ I believe it is in a quiescent
form right now with no further development. At least three major APL
vendors make available “complete” trial versions. You should look
into them.
I will let others comment on point four. There are a multitude of
bridges to the outside world. However, let me make a distinction
here. I would expect your point four would be of interest to someone
who is comfortably knowledgeable with the language. If you really
don’t understand the language why bother to bridge anywhere.
On point five, why would you want to write a hash table if only to
illustrate it educationally. Then just implement the algorithm just
like you would with any another programming language. APL is more
than linear algebra. Again look in the vendor’s public libraries and
Vector for starters.
On point six, all APL vendors support ‘core’ APL language. If you
choose to program in core APL it will run on any of the vendors’ APL.
Ok, defined operators are not universal. I view the APL language
surrounded and supported by the APL system. This is vendor
dependent. These APL systems address the bridges to the outside
computer world.
On your seventh point, there is movement in that direction. Dyalog
APL is holding a student contest in conjunction with its forthcoming
Dyalog APL conference. Of course, money is a fine incentive, but so
is the pride of winning. That can lead to another more important
incentive; a job interview and a job. There are programming contests
about. I find it frustrating that they often restrict the programming
languages that can be used. I’m sure that the APL community could
judge any APL entries. I am still smarting from a past event. I
offered to work with a local high school computer club provided I
didn’t use or teach them APL. Why, it was too easy!
Now let me ask you, how did you come onto APL? What attracted you?
Peter I have been involved with APL for many years coming from a
background of programming in binary (for Illiac), assembler and
Fortran. Therefore I can’t speak for the vast assortment of other
programming languages. But I can say APL continues to be an
intellectual challenge and fun to use. Ray Polivka

Polivka@acm.org <Polivka@acm.org> wrote:
> On point one, what sort of applications are of interest to the ?main
> stream? programmer?

A HUGE one is games of any and all kinds. Understanding that this is a
large topic, let's take a look at some popular open source repositories
and see popular projects people are working on.

Ten most popular projects from Fresh Meat (http://freshmeat.net/),
a well-known place where open source authors distribute their work:
-------------------------------------------------------------------

1. MPlayer
MPlayer is a movie and animation player that supports a wide
range of codecs and file formats, including MPEG 1/2/4, DivX
3/4/5, Windows Media 7/8/9, RealAudio/Video up to 9, Quicktime
5/6, and Vivo 1/2. It has many MMX/SSE(2)/3Dnow(Ex) optimized
native audio and video codecs, but allows using XAnim's and
RealPlayer's binary codec plugins, and Win32 codec DLLs. It has
basic VCD/DVD playback functionality, including DVD subtitles,
but supports many text-based subtitle formats too. For video
output, nearly every existing interface is supported. It's
also able to convert any supported files to raw/divx/mpeg4 AVI
(pcm/mp3 audio), and even video grabbing from V4L devices.

2. Linux
Everyone should know what this is.

3. cdrtools
cdrtools (formerly cdrecord) creates home-burned CDs/DVDs with
a CDR/CDRW/DVD recorder. It works as a burn engine for several
applications. It supports CD/DVD recorders from many different
vendors; all SCSI-3/mmc- and ATAPI/mmc-compliant drives should
also work. Supported features include IDE/ATAPI, parallel
port, and SCSI drives, audio CDs, data CDs, and mixed CDs, full
multi-session support, CDRWs (rewritable), DVD-R/-RW, DVD+R/+RW,
TAO, DAO, RAW, and human-readable error messages. cdrtools
includes remote SCSI support and can access local or remote
CD/DVD writers.

4. Apache
An extremely popular web server.

5. gcc
The GNU C compiler suite.

6. VLC media player
VideoLAN Client (VLC) is a media player, streamer, and encoder for
Unix, Windows, Mac OS X, BeOS, QNX, and PocketPC. It can play most
audio and video codecs (MPEG 1/2/4, DivX, WMV, Vorbis, AC3, AAC,
etc.), has support for VCD, SVCD, and DVD (with menus), and can
read or dump streams from a network source (HTTP, UDP, DVB, MMS,
etc.). It can also act as a server and send streams through the
network, with optional support for audio and video transcoding.

7. PHP
PHP is a widely-used Open Source general-purpose scripting
language that is especially suited for Web development and can
be embedded into HTML. Its syntax draws upon C, Java, and Perl,
and is easy to learn. PHP runs on many different platforms and
can be used as a standalone executable or as a module under a
variety of Web servers. It has excellent support for databases,
XML, LDAP, IMAP, Java, various Internet protocols, and general
data manipulation, and is extensible via its powerful API. It
is actively developed and supported by a talented and energetic
international team. Numerous Open Source and commercial PHP-based
application packages are available.

8. TightVNC
TightVNC is a VNC distribution with many new features,
improvements, and bugfixes over VNC. It is optimized for faster
operation on slow network links such as modem connections,
provides more configuration options in the server, features
automatic SSH tunneling in the Unix vncviewer, and more. The
modified servers and viewers are fully compatible with the
original VNC software.

9. PostgreSQL
A very popular database engine.

10. MySQL
The other very popular database engine.

In my tounge in cheek opinion, it looks like the most popular things
at freshmeat concern themselves with watching/recording media, telling
people and writing about it (web servers, PHP), keeping track of
things, and tools which allow them to develop the aformentioned things.

From Source Forge (http://sourceforge.net/):
--------------------------------------------

Hrm, there is a vast amount of software in there. I'll give a sample
of popular stuff I find in various catagories. Most of these are written
in Java or C/C++.

[Game platform simulator for very popular older games]
1. ScummVM is a cross-platform interpreter for several point-and-click
adventure engines. This includes all SCUMM-based adventures by LucasArts,
Simon the Sorcerer 1&2 by AdventureSoft, Beneath a Steel Sky and Broken
Sword 1&2 by Revolution, and many more.

[Budget planing and forecasting]
2. Adaptive Planning express is an open source solution that allows midsized
companies and departments of large corporations to move beyond Excel
and automate budgeting and forecasting. Too busy? Try the free, hosted
version to get started in 2 minutes at http://www.adaptiveplanning.com

[Living quarter layout software]
3. Sweet Home 3D is an interior design Java application for quickly
choosing and placing furniture on a house 2D plan drawn by the end-user,
with a final 3D preview.

[Wow, this was written in LISP! A math package.]
4. Maxima is a fairly complete computer algebra system written in lisp
with an emphasis on symbolic computation. It is based on DOE-MACSYMA
and licensed under the GPL. Its abilities include symbolic integration,
3D plotting, and an ODE solver.

[Physics is always cool.]
5. Open Dynamics Engine is a free, industrial quality library for
simulating articulated rigid body dynamics - for example ground vehicles,
legged creatures, and moving objects in VR environments. It's fast,
flexible & robust. Built-in collision detection.

[Geneology]
6. PhpGedView is a revolutionary genealogy program which allows you
to view and edit your genealogy on your website. It has full privacy
functions, can import from GEDCOM files, and supports multimedia. It
also simplifies family collaboration.

[Security bookeeping]
7. Password Safe is a password database utility. Users can keep their
passwords securely encrypted on their computers. A single Safe Combination
unlocks them all.

[A popular thing due to the rise of social networking sites like Facebook,
LinkedIn, MySpace, etc]
8. Social Networks Visualiser (SocNetV) is an SNA tool for Linux. With
it you can draw a network or load an existing one (Pajek, Sociomatrix
or dot-formatted). It computes social network properties, centralities
and implements some layout algorithms.

[Analyzing webserver logs]
9. AWStats is a free powerful and featureful server logfile analyzer
that shows you all your Web/Mail/FTP statistics including visits, unique
visitors, pages, hits, rush hours, os, browsers, search engines, keywords,
robots visits, broken links and more...

[For the armchair astronomer]
10. Stellarium renders 3D photo-realistic skies in real time with
OpenGL. It displays stars, constellations, planets, nebulas and others
things like ground, landscape, atmosphere, etc.

> Perhaps you had in mind inquisitive type programming. It is basically
> personal problem solving. It is a fine way to learn what a programming
> language can do. I believe that is what you were doing creating a
> tic-tac-toe programming.

Sure, I use this method to learn a new programming language, but once
I learn it, I want to then develop software with it. Much like the
yin/yang symbol, you can't have one without the other. Scheme, like APL,
also has a workspace (called toplevel) and you can interactively type
in your stuff to check to see if it works and build up the solution.
In general though, you can't save your toplevel, you just store the
code into a file and load it later if you want to use it again. The two
languages really do share a lot in user experience.

> Perhaps you are not aware that the APL community
> produces two quarterly APL publications: Vector ? the excellent
> publication out of England, and Quote Quad from the ACM?s Special
> Interest Group on APL. Unfortunately the ACM shut down SIGAPL so I
> don?t know the future of Quote Quad. I mention Quote Quad since in
> the last three issues I posted a problem for the readership to solve.
> If you wish to try some APL problem solving look at them and their
> solutions. I believe those Quote Quads are online. If they are not,
> I can provide you copies.

I was slightly aware of Vector and Quote Quad, but I never realized
their importance until much later. While the information there is
highly valuable and pertinent, it is also not enough. I can go to the
web and find thousands of pages from unrelated people on how to do all
manner of things in C, and maybe three dozen for APL from Vector and
the vendor's sites. More users will produce more pages. They will
create content for free!

Think about it. Humanity writes encyclopedias (Wikipedia) for free and
for fun!

> On point two, yes APL is dense, but that is the nature of APL. It is
> no different than reading a sheet of Mozart?s music or a Chinese
> newspaper. You have to learn the language. How do you introduce APL?
> Actually there are two parts to that question. They are ?how do you
> introduce APL for those who wish to learn about it?? verses ?How do
> you introduce APL for those who wish to use it?? .Over the years, I
> have had the opportunity to coauthor three books on APL. They are
> focused on those learning to use APL. I am still looking for the
> ?Holy Grail? of introducing APL to those who wish to know more about
> it.

> On point three, can you give me an example on what would draw folks to
> APL? You mention ?little pieces of cookbook-y software?. Each of the
> vendors of APL provides public libraries full of interesting
> functions. Also because of the conciseness of APL, there are
> collections of idioms. For example IBM produced a 75 page document of
> idioms. The Finnish APL community also produced an extensive list of
> APL idioms. You speak of using APL+ I believe it is in a quiescent
> form right now with no further development. At least three major APL
> vendors make available ?complete? trial versions. You should look
> into them.

[rearrange]
> I have taught APL for many years. As a result I have
> been collecting problems and exercises. The original purpose of them
> was to offer the student who had finished an introductory APL course
> additional APL practice. Would problems and their solutions like this
> be of interest to programmers like yourself?

You bet that would be of interest! You are in a special position with
your combined APL and teaching knowledge. Most APL tutorials I see
basically just explain the language, but without much context as to why
the language and idiomatic constructions of it have meaning beyond naive
examples.

What I think is sorely needed is a book similar to this for APL:
http://mitpress.mit.edu/sicp/

Read the full text of it for a while from the beginning to see how it
introduces the Scheme language, and most importantly, what it means
to think in a functional manner. APL needs an analagous book to
teach the "way of thinking" of APL plus some of the common idiomatic
constructions. You said so yourself in this quoted portion from another
part of this thread:

You wrote:
> But let me raise a word of caution. I have seen some of the APL
> code written by ?other field ? folk who were exposed to the rudiments
> of APL. It was not good APL. It often consisted of hundreds of lines
> of branching/looping code buried in niladic functions. Not that I am
> faulting them, after all, many of them came from a Fortran, Basic, or
> other sequential programming language background. Yes some came with no
> programming background at all. This is what often happened when these
> very competent people were told to go read up, self study, and learn APL.
> Maybe it doesn?t matter if the result gets the job done.

If you write the imperative style in a functional language, you get the
exact same horribly written code.... The SICP book adresses this issue
directly by not even showing you how to do it imperatively--the nature
of the book is to say "Here's how it is perfectly done." and to show the
annotated implementations of sizable and real problems. People aren't
going to deduce how to think in APL, given the general method of Computer
Science schooling in a mainstream object oriented or imperative language,
just by being shown the operators and basic syntax--they need to be shown
the _correct method of thought_. The failure you mentioned happened when
the users "read up" in APL, they weren't reading the right things because
the right thing wasn't there! "Reading up" in scheme means reading SICP.

The Finnish APL idiom library is awesome (and I didn't even know about it
until right now since it didn't even occur to me APL would have so many
common idioms), but it is too condensed. The idioms need to be placed
into a graded and meaningful context, into a "story of implementations
of realistic problems" where the idiom shows the power of its use. You
could leverage your large set of problems/solutions to provide a graded
movement of the user through APL's expressive nature and provide example
for the appropriate use of idioms.

Standardization here would be a *fantastic* win especially if most or
all of the APL idiomatic constructions already worked in all the various
vendor implementations. If this is already the case, the vendors do
no work other than a few people writing the document, and everyone can
immediately claim comformity.

APL isn't alone with its idioms, perl has such a thing too:
http://dave.org.uk/perlwhirl/idiomatic.pdf

In thinking about it, it looks like there would be 3 parts to an APL
standards document:
1. Core Language
A. Rationale
B. Description
C. Available Operators
D. Functions
E. Interacting with the outside world, file i/o, etc
2. Standard library
3. Standard idioms
A. Dialog on appropriate use.
B. Big list of idioms

> I will let others comment on point four.
[snip]
> If you really don?t understand the language why bother to bridge anywhere.

In my experience, this viewpoint is not correct. The reason is that
suppose a really good C programmer already knows OpenGL and a few other
languages. They might come to APL and think, "Wow, I could totally
figure out all of those gradients to this crazy implicit surface
problem in 100 characters of APL instead of thousands of lines of C,
now, how do I graph the ones of interest to me?" and immediately want to
know how to use the bindings to OpenGL--like he had in other languages.
The hypothetical developer is pretty smart and could figure out any kind
of binding in a few hours or so. This is pretty common, really. Often
people want to bind against some well known GUI toolkit, or some other
kind of well-known library.

> On point five, why would you want to write a hash table if only to
> illustrate it educationally. Then just implement the algorithm just
> like you would with any another programming language. APL is more
> than linear algebra. Again look in the vendor?s public libraries and
> Vector for starters.

The problem here is that I have to look in the vendor's libraries and the
archives of an online magazine. The information is in the wrong place.

Typing in "C Hash Table" into google brings me to a first link here:
[Hrm, some of that is idiomatic C++ rendered into C, strange]
http://www.cl.cam.ac.uk/~cwc22/hashtable/

Noone cares about what vendor that code will work on, it'll work
everywhere. Also, notice it isn't hosted at a vendor site and is off some
random guy's website--ranked FIRST by google for such an important topic!

This "ask google for the answer" is so prelevant in modern geek culture
that it might as well be as second nature as breathing.

The real problem is that why do I have to look at a specific vendor's
public libraries when there should already be plenty of pages which
describes an idiomatic implementation of a hash table in a vendor
independent APL? That would be like searching through GCC's archives for
how to implement a linked list traversal in idiomatic C. The truth is
you look in the K&R ANSI C book, IIRC, book for how to do that, or any
random non-vendor specific textbook for C.

Basic Computer Science algorithms should not be buried in public libraries
of vendor implementations. They should be prominently displayed with
code that works everywhere because this is what people are going to need
to use right when they start coding something important in APL. The
idiomatic expression of those algorithms should be near to the first
thing a potential user finds as it relates the experience of APL to the
rest of the languages they already know.

> On point six, all APL vendors support ?core? APL language. If you
> choose to program in core APL it will run on any of the vendors? APL.

Then this Core APL, barring the arguments about conflicts operators,
should be the premise of a standardization document. The work is already
done--the commonality exists. Just write it down, stick your names on
it, and think about the next revision of Core APL which increases the
standard set of APL.

If there are conflicting operators, then the vendors pick one, causing
work for some vendors, not for others, and a command line flag implements
the standard. It seems natural to me that eventually all vendors would
have to put some work into being in conformance. The load is ultimately
shared.

> On your seventh point, there is movement in that direction. Dyalog
> APL is holding a student contest in conjunction with its forthcoming
> Dyalog APL conference. Of course, money is a fine incentive, but so
> is the pride of winning. That can lead to another more important
> incentive; a job interview and a job. There are programming contests
> about. I find it frustrating that they often restrict the programming
> languages that can be used. I?m sure that the APL community could
> judge any APL entries. I am still smarting from a past event. I
> offered to work with a local high school computer club provided I
> didn?t use or teach them APL. Why, it was too easy!

Directly, this comes to the topic of the conciseness of APL. You can
say a lot in a few characters. This isn't a problem or a bug in the
language at all, but a very great feature. The trick is to describe
how to write more and more complicated APL without having to resort to
powerful statistics or mathematics to pull examples from. Usually, this
is resolved by doing symbolic processing--example, reading entries of
CD titles from a flat file "database", sorting/displaying them, and
allowing the user to ask questions about what is in the "database",
and adding/deleteing from the database which can then be saved to disk.

There are a lot of things in that tiny project which don't require
powerful mathematics for the user to understand, yet they can still write
a fair amount of APL to do the job. These types of problems is what
easily introduces APL to people that are non-mathmeticians. However,
doing in the "APL method of thought" teaches them how to think like
mathmeticians, even if they don't realize it....

> Now let me ask you, how did you come onto APL? What attracted you?
> Peter I have been involved with APL for many years coming from a
> background of programming in binary (for Illiac), assembler and
> Fortran. Therefore I can?t speak for the vast assortment of other
> programming languages. But I can say APL continues to be an
> intellectual challenge and fun to use.

Actually, the thing that attracted me was the character set itself. As a
hobby I research programming language theory, design, and implementation.
This leads me to experiment with many languages and learn them enough to
understand why they happen to be so useful.

(A consequence of my hobby is I'm writing a scheme compiler, which is
why I happen to understand some of the general problems with APL since
the two langauges are in a reasonably similar position and I had to
understand Scheme's point of view before devoting 5 years of my life to
writing a compiler for it).

I wanted to see just how concisely I could write an algorithm and
thought of the Chinese, etc languages where symbolic (fixed width if you
squint) characters stood for entire concepts. How wonderful it would be,
I thought, if I could convert the reasoning of thousands of lines of
C into executable characters on a single sheet of paper--sort of like
compressing the representation of thought itself. I was going to try and
mix functional programming concepts (especially map, filter, reduce,
lexical closures, recursion, etc) with APL's array based processing
(possibly implementing a new dialect) because I thought it would make
for something very interesting--especially if one could design their own
glyphs representing functions and integrate them into the language. It
always bothered me that I had to write ascii function names for new
functions in APL--why throw away the one really special feature of the
language as soon as you try to extend it? I imagined a custom glyph
associated with the ascii name and you'd see the ascii name as a tooltip
with the mouse. I wanted sweet, sweet code density.

Of course, this is all pie in the sky nonsense which will probably go
nowhere, but it is the direct reason why I came to APL, and not to
something like J.

Hrm, this post is too long. I'm stopping the writing of it....

Thank you.

-pete