Conference turris::languages

	I know nothing about KOALA except that my group has gotten a
few programs written in KOALA from Academia.  It's nice to be able to
compile them...
		<_Jym_>

At the time Koala was done the ability to do windows from the language
was it's chief feature. And theoretically it was going to allow the same
code to run on vax or 11. Nice dream. Lately they seem to have turned it
into a wps language. Wps+, I believe (a little knowledge is a dangerous
thing?), is on vms, pro, microrsx, and working on a cpm version.

I worked for the group for some short period of time. I couldn't believe
it was implemented either.

From what I understand, the original versions of the graphics products
(OFFISLIDE??) we written in KOALA.  I used the original version of OFFISLIDE
and was impressed with its functionality. Then I found out that they were
converting it to BLISS to get some real editing speed out of it, and when we
got a field test version of DECslide (one of the earlier ones), it had about
half the OFFISLIDE functionality in it, and I don't know if it ever got back
in.  

If this isn't doing the job twice....?!@@*&%#

Rick

Re .3:

DECslide is NOT the BLISSed  version of  OFFISLIDE.   They are  2 separate
entities.  Actually, the current version of DECslide is written in PASCAL.

- Paul

I apologize if I got my DECblatz's mixed up.  I may have mistook DECplot and
DECgraph for the other two.  In any event. the event did happen.

- Rick

I have heard, from a heavy KOALA programmer, that he considers the language
great as a prototyping language but that real products should be written
in something else.

Commercial sites use Datatrieve-like things for prototyping applications and
then write the final applications in COBOL.  We should probably use
KOALA for A/D work and then BLISS or C for the product.

Why SCAN?

  I don't know what Anton Chernoff's Digicalc (?) was implemented in, but it
  might have been Koala, since he was in the OFIS group back then.  I haven't
  used it myself, nor have I used DECalc, but I heard it said that DECalc
  compared poorly with Chernoff's Digicalc, and that DECalc was a whole an-
  other implementation.  Maybe this was the wheel that was reinvented?

No problem with A/D work, but when you look at commercial programming, once
someone develops something that runs using DTR, the MIS group is stuck with
it.  Just try and get some finance type to fund a rewrite of the system just
put in with DATATRIEVE for the sake of machine resources.  He will tell you
to go get more hardware, or the MIS group will be too bogged down to consider
it until 1999.

Point.  Midnight hacks and prototypes often become corporate products, despite
our rhetoric about doing it right when we have time.

Rick

re 0:
----

KOALA was definitely intended to fill a gap, and that gap still exists 
to some extent. DEC has NO language whose source code is 
transportable. BLISS is fine for VAX and the 11s and 36-bit systems, 
but ONLY if you are very careful to use the common subset. BLISS won't 
help you if you need to generate code for an 8086 or a 68000 or any 
other processor on which we might need to develop software. (Please 
don't respond here to the advisability of doing that.)

KOALA (and the OBM) was intended to provide (with total source code
compatibility) high-functionality screen handling, communications,
file handling, and document processing. I've probably left a few out. 

As an historical note, KOALA development was begun when the "KO" group 
was established. It was not intended as a corporate replacement for 
any implementation language. However, it was deemed to be the best way 
to develop a new set of products for multiple (unspecified) target 
systems.

I will let others comment on what KOALA's future should be.

re: .1
------

The "academics" liked the language for a few reasons. Software 
development with KOALA is extremely fast, because of both the OBM (a 
set of predefined statements and runtime support) and KOALA's 
extensibility. Also, a group of academics were (maybe are) doing some 
advanced development for DIGITAL using KOALA.

re: .2
------

The compatibility is more than a dream. It's simply a goal that hasn't 
been realized totally yet. The problems are primarily 
performance-related --- and they are clearly solvable.

As for KOALA becoming a WPS language, it is currently being used to 
develop WPS products. It is, however, no more a WPS language than 
BLISS is a DATATRIEVE language.

re: .3
------

The first implementation of KOALA generated P-code. The performance of 
the VAX interpreter left a lot to be desired. The current performance 
of KOALA (VMS) compares favorably to any other VMS language. (No, I 
won't supply any figures.)

Yes, one of the products mentioned was based on an original KOALA 
version (using the interpreter). Native mode KOALA wasn't there in 
time to ship the KOALA version.

re: .8
------

Chernoff's DIGICALC was indeed written in KOALA. Its performance is 
(was?) a better than any other version known.

re: .9
------

Indeed. It's hard to get rid of a dog prototype if it works at all.

However, it is not true that KOALA's purpose is prototyping. On the 
other hand, it is understandable that it has been used for 
prototyping, because of the ease of developing working software 
quickly.

Bob

Invented to fill the gap of total compatibility across systems by starting
from scratch with a language that didn't run anywhere?  Do you guys believe in
Santa Claus too?
			-Kevin

re: .11

First, "you guys" now refers to a group that no longer exists, its members
having scattered to the four winds.

As for Santa Claus, he was a very useful invention, bringing a great deal
of joy to lots of people. Some consider KOALA a very useful invention too.
And, a KOALA kit is available. (It's harder to find Santa.)

Bob

Anton had the first version of Digicalc running in about 2 weeks.
From scratch.  I was across the aisle from him at the time, and
we brainstormed several of the later features.  I was doing the
first Income Tax form for it, and needed various features, which
he could get implemented within a day.

The code was just about unreadbale, though.  He didn't bother
with comments.  Not a fault of the language.

DECplot was not in KOALA; it was in Pascal.  DECgraph is in BLISS,
and is a complete re-implementation from scratch.  Nothing was kept
but the basic concepts.

The absence of a Bliss compiler for ISP foo is not a fault of the
language.  It only says we haven't got around to doing the foo
backend yet.

KOALA lets you define new types, and the operators for them.
But so does ALGOL-68.  KOALA has a nice behind-the-scenes
storage allocator, and it has dynamic strings.  BASIC is about
the only other language we have with dynamic strings (plus
MUMPS, of course).

A good feature of using a powerful but goofy language for
prototyping is that it makes it harder for over-zealous
product managers to make you ship the prototype to customers.
I use DSM and FORTH, myself.  The REAL versions are always in
Bliss.

Paul Dickson, ex-Bliss front-end guru

If you want to prototype something, 1) don't invent a new language to write
the prototype in as that simply has to be counter-productive, 2) do it in
APL if possible.

When you're prototyping something, typically your major goals are:

	1) Write it quickly
	2) Experiment with algorithms
	3) Demonstrate and tune functionality
	4) Don't worry about speed (nor even reliability)

To me these goals strongly suggest APL.   Studies have demonstrated that
programs can be developed as much as 10 TIMES FASTER in APL than in 
FORGOL (my term for FORTRAN and its various flavors (Pascal, ada, PL/I,
C, etc.).

It's unfortunate that we don't use APL for prototyping much here at DEC.
Some groups here have and had phenomenal success (to the embarrasment of
other "competing" groups).   IBM uses it extensively for prototyping.
I've heard figures as high as 30% for estimating the percentage of APL usage
internally at IBM.

	db

Re .13:

Algol-10/20 has "real strings" too.  None of this garbage with fixed length
strings, like Fortran-77.  None of the garbage of copying pointers by
default in assignments, so that the user has to copy data by hand when
a copy is really wanted.  I was impressed to hear that Koala had apparently
done strings "the right way".

[If anyone wants to start an argument about strings, I will participate].

Re .14:

Did you catch Jacob Schwartz's lecture on prototyping in SETL at NYU?
They are able to do things like a (slow) Ada system with less human
rosources, and with far fewer pounds of source code.

Schwartz did not seem to want to characterize SETL as an unusual language
with heavy applicitive leanings.  He called it a kind of Algol with sets
a couple of times.  It certainly has much richer data and control
abstractions than APL, and they are not badly integrated, either.  I
don't know whether it qualifies as the kind of Diamond that APL
purports to be, but it is no lump of coal either.
				/AHM