Ultimate Language feature list

Ultimate Language feature list

[MSG]

I do all my development in C++.  Not necessarily because I want to, but
because I keep looking (and looking) for alternate languages/environments
and they ALWAYS come up short.  I've decided that the language/environment
for me hasn't been created, so I'm starting a list of features that I
like/require.  It's drawn from good languages (I don't consider C++ a "good"
language", neither is Java).  If anyone would care to contribute, please
feel free.  Who knows, maybe with enough interest we can create a
language/environment we REALLY like and that works easily on any platform,
allowing you to use a sophisticated  language and still access platform
specific features for truly fantastic and stable applications.

I hope a posting like this doesn't cause a flame war.  I'm just sharing my
feelings and hoping that some interest will spark -- to what end, I'm not
sure.

Michael Scott Garnett
michael@pickles.org

#1 Verbosity.  C++ and Java's cryptic syntax is cute and fun, but not
useful.  Our Language (OL -- come up with a good name) should be verbose
like Ada and Eiffel.  Semicolons optional like Eiffel (except where
ambiguous).
#2 Completely OO.  No free floating subroutines.  The only construct higher
than a CLASS is an Organizational Unit (like an Eiffel cluster).
#3 Object-Dot-Feature syntax.  No Ada95esque subprograms which take class
arguments (like C++ friend functions).  I am torn between Object-Dot-Feature
and Object SPACE feature syntax (like Smalltalk).
#4 Reference Objects as a default with the ability to expand an object or
class to full form (like Eiffel EXPANDED types)
#5 Garbage Collection.
#6 Construction and Finalization
#7 Predictable Finalization for stack-based objects (either reference or
expanded).  When the immediately enclosing scope terminates, the
finalization is called THEN. This is VERY important for reliable external
resource management (OK, C++ did this right).
#8 Polymorphism as the rule.  Let the compiler figure out which routines are
not overridden and use static calls where appropriate (a la Eiffel).
#9 Named arguments.  Either like Ada or like Smalltalk (object moveTo: here
usingPath: aPath).
#10 Array and record aggregates (like Ada).
#11 Multiple inheritance like Eiffel, NOT C++.
#12 STRONG typing and constraint/program checking in the compile and runtime
like Ada.  Options to remove such features in a "finalized" version is very
much necessary.
#13 Ada-style tasks.  Using Object-as-task, like the proposed Eiffel
extension "separate".  Ada's SELECT mechanism.  Protected types (like
Ada95), Java almost got this right.
#14 EASY access to other languages/calling conventions.  Any CLASS's
features my be effected by external other-language routines. The includes an
easy way to link to C++ libraries.  Such special classes can specify that
for "THIS" an other-language-notion be used. Such classes would lack
"variables", being limited to routines only.
#15 Generics.  Not templates.
#16 Intrinsic types (like Integer) as objects, but completely replaced in
generated code by native types (like Eiffel).
#17 Ada's float types (delta, digits).
#18 Range specifications (like Ada).  Checked at compile time and run time.
#19 Discriminated record/class types (like Ada).  Checked at compile time
and run time. (maybe not necessary with inheritance)
#20 An easy with to extend and re-expose/hide features of parents.  Like
Eiffel.
#21 Distributed computing.
#22 Pre- and post-conditions (from Eiffel).  Including support for the "old"
keyword.  The closest thing to Z (pronounced Zed - a formal method) that
I've seen.

Re: Ultimate Language feature list

[Mark K. Gardner]

On Wed, 13 May 1998 07:47:11 -0400, MSG <michael@pickles.org> wrote:
>I do all my development in C++.  Not necessarily because I want to, but
>because I keep looking (and looking) for alternate languages/environments
>and they ALWAYS come up short.  I've decided that the language/environment
>for me hasn't been created, so I'm starting a list of features that I
>like/require.  It's drawn from good languages (I don't consider C++ a "good"
>language", neither is Java).  If anyone would care to contribute, please
>feel free.  Who knows, maybe with enough interest we can create a
>language/environment we REALLY like and that works easily on any platform,
>allowing you to use a sophisticated  language and still access platform
>specific features for truly fantastic and stable applications.

I too have spent considerable time looking for the "ultimate language". In
the process, however, I have come to understand a few things. 

1) My ultimate language is likely not your ultimate language. While I agree
with some of the features you require, I disagree with some and would add
yet others. 

2) My ultimate language depends on what the task at hand is. In other words,
my ultimate language is not a single language but a set of languages which
are "ultimately suited" for the task at hand.

3) My ultimate language(s) change with time. I very seldom solve the same
problem twice. New problems require new solutions, which make different
features desirable.

4) Ultimately (pun intended), the language must be used by enough people for
good-quality implementations to exist on the platforms you use. This implies
that it must meet enough of the expectations of enough people to see wide
spread usage or be mandated by some governing body, such as your
employer.

5) Finally, if I spend too much time looking for my ultimate language, I
will not get enough done to justify the effort spent in finding it. Some
have called this, to paraphrase, "the best is the enemy of good enough".
While no language has all the features I desire (and none of the ones that I
despise), I have a toolbox of "good enough languages" that allow me to do my
work while continuing to look for something better.

While #5 is perhaps the most important lesson of all, I believe all of the
above decrease the probability (and desirability) that I will ever find an
ultimate language. That is not to say I would advise you to stop looking.
But I would not waste an inordinate amount of time in the search. 

[By all means, please post an announcement when you have found, created,
begged, borrowed, or even stolen the ultimate language! :) ]

Mark

-- 
Mark K. Gardner (mkgardne@cs.uiuc.edu)
University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
-- 

Re: Ultimate Language feature list

[John McCabe]

>#1 Verbosity.  C++ and Java's cryptic syntax is cute and fun, but not
>useful.  Our Language (OL -- come up with a good name) should be verbose
>like Ada and Eiffel.  Semicolons optional like Eiffel (except where
>ambiguous).
>

I'm not convinced about semi-colons being optional (except where 
ambiguous), it just confuses things like Pascal where you don't need a 
semi-colon if the next statement is an "End", or is it that you can't 
have a semi-colon where the next statement is an "End"? Certainly got me 
confused - haven't used Pascal since April 1993 though.

How about:

1) functions that return multiple values like Occam2 e.g:

	x,y = func1(a,b)

2) Prioritised task entries like the PRI PAR construct in Occam2


3) Indentation levels as part of the language syntax as in Occam2.


Unfortunately I don't have an Occam2 manual to hand (and I haven't used 
it since around December 1992), but I believe it had some very nice, 
useful, easy to use constructs, and the Transputer Development System, 
with its folding editor, was something else (at the time). All it needed 
really was user defined types, timeouts on channel outputs and a better 
image!

Still, one way or another, Ada appears to have pretty much everything 
Occam had but in a much more flexible (and sometimes complicated) manner.

-- 
Best Regards
John McCabe

=====================================================================
Any opinions expressed are mine and based on my own experience. They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Ultimate Language feature list

[Charles Hixson]

Here's my features (at the end), plus some notes (interspersed):

MSG wrote:
> 
> I do all my development in C++.  Not necessarily because I want to, but
> because I keep looking (and looking) for alternate languages/environments
> and they ALWAYS come up short.  I've decided that the language/environment
> for me hasn't been created, so I'm starting a list of features that I
> like/require.  It's drawn from good languages (I don't consider C++ a "good"
> language", neither is Java).  If anyone would care to contribute, please
> feel free.  Who knows, maybe with enough interest we can create a
> language/environment we REALLY like and that works easily on any platform,
> allowing you to use a sophisticated  language and still access platform
> specific features for truly fantastic and stable applications.
> 
> I hope a posting like this doesn't cause a flame war.  I'm just sharing my
> feelings and hoping that some interest will spark -- to what end, I'm not
> sure.
> 
> Michael Scott Garnett
> michael@pickles.org
> 
> #1 Verbosity.  C++ and Java's cryptic syntax is cute and fun, but not
> useful.  Our Language (OL -- come up with a good name) should be verbose
> like Ada and Eiffel.  Semicolons optional like Eiffel (except where
> ambiguous).
Verbosity has it's points, but so does compactness.  Zipf's laws rules
here.  Frequently used features should be v. short, e.g. {} is better
than Begin End

> #2 Completely OO.  No free floating subroutines.  The only construct higher
> than a CLASS is an Organizational Unit (like an Eiffel cluster).
Object Orientation is the correct solution for certain classes of
problems, so the lanugage should support a totally object oriented
style.  It shouldn't insist on it.  Byte arrays use up enormous amounts
of storage when each byte is an object.

> #3 Object-Dot-Feature syntax.  No Ada95esque subprograms which take class
> arguments (like C++ friend functions).  I am torn between Object-Dot-Feature
> and Object SPACE feature syntax (like Smalltalk).
What about context specifier?  3 + 5 vs. "3" + "5" vs. 3.0 + 5
These can all be understood by a person, a compiler might reason: given
a number, the operation + probably means addition, so check for the next
argument.  If types are staticly determined, then this is either
ambiguous or determined at compile time.  The question is what to do if
it is ambiguous at run time.  Note that the semantics is the same as
object-dot-feature.  Ideally, syntax should be flexible, and I don't
know what's practical.

> #4 Reference Objects as a default with the ability to expand an object or
> class to full form (like Eiffel EXPANDED types)
This is good.

> #5 Garbage Collection.
This is v. important.

> #6 Construction and Finalization
This needs to be elaborated, Final means something different in Java
than it does in Eiffel, e.g.

> #7 Predictable Finalization for stack-based objects (either reference or
> expanded).  When the immediately enclosing scope terminates, the
> finalization is called THEN. This is VERY important for reliable external
> resource management (OK, C++ did this right).
Predictable or controlable?

> #8 Polymorphism as the rule.  Let the compiler figure out which routines are
> not overridden and use static calls where appropriate (a la Eiffel).
Yes.

> #9 Named arguments.  Either like Ada or like Smalltalk (object moveTo: here
> usingPath: aPath).
Good, although I've rarely used that feature when it was available. 
Still, it facilitates indirect object style constructions.

> #10 Array and record aggregates (like Ada).
YES!!! Nobody else has (except, poss. PL/1) that I've encountered has
done arrays as well.

> #11 Multiple inheritance like Eiffel, NOT C++.
Yes, especially the rename and redefine constructs.

> #12 STRONG typing and constraint/program checking in the compile and runtime
> like Ada.  Options to remove such features in a "finalized" version is very
> much necessary.
Strong typing should be available, and when used should allow compiler
optimizations.  However, a more perfect language would also allow
"on-the-fly" constructions and evaluations (ala Lisp, Snobol, etc.)

> #13 Ada-style tasks.  Using Object-as-task, like the proposed Eiffel
> extension "separate".  Ada's SELECT mechanism.  Protected types (like
> Ada95), Java almost got this right.
I wish that I understood this better.  It sounds good, but I don't know
the details of what it means.

> #14 EASY access to other languages/calling conventions.  Any CLASS's
> features my be effected by external other-language routines. The includes an
> easy way to link to C++ libraries.  Such special classes can specify that
> for "THIS" an other-language-notion be used. Such classes would lack
> "variables", being limited to routines only.
Yes.

> #15 Generics.  Not templates.
Yes.

> #16 Intrinsic types (like Integer) as objects, but completely replaced in
> generated code by native types (like Eiffel).
As long as they DO get replaced, or at least can be.  Possibly some
constructions could require that object style information be carried
after compilation, but certainly arrays of intrinsic type shouldn't
require that each of their members be a separate object.
#16b:  Homogenous arrays:  In a homogenous array, all members of the
array are of EXACTLY the same type (whether or not it is intrinsic), so
indirect references, etc. are not needed, and storage (etc.) can be
optimized.

> #17 Ada's float types (delta, digits).
Yes.

> #18 Range specifications (like Ada).  Checked at compile time and run time.
Yes.

> #19 Discriminated record/class types (like Ada).  Checked at compile time
> and run time. (maybe not necessary with inheritance)
I'm unsure of this one.  Inheritance seems to me to be a better choice.

> #20 An easy with to extend and re-expose/hide features of parents.  Like
> Eiffel.
No (and yes).  One needs the private type as well as the protected
type.  Possibly there could be a Discrete type that was by default
hidden, but which the descendants of could Peek at?

> #21 Distributed computing.
Yes, but what does this mean (beyond separable threads (or tasks)?)

> #22 Pre- and post-conditions (from Eiffel).  Including support for the "old"
> keyword.  The closest thing to Z (pronounced Zed - a formal method) that
> I've seen.
Yes.

#23 Pattern Matching primitives and forms.  A bit up in the air here,
since I'm not sure the best way to blend it in.

#24 Built in database (not an add-on).  This could be a compiler option,
but needs to be an integral feature of the language, not a JDBC style
add-on.

#25 Good random-access I/O capability.  At least for homogenous files
(see homogenous arrays, above) this should be easy.  I would like
something better, however.  Something that doesn't assume that
everything on the disk can fit into RAM, too.

#26 Support for property lists.  This could probably be done via a
library, but it should be a part of the language definition, so that it
is a transportable feature.


-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

Re: Ultimate Language feature list

[adam]

Well, as long as we're talking about what language features we want,
here's one I've always wanted: The ability to deal with sequences of
objects.  I don't mean a list of objects where you have to create an
array or linked list in memory that contains all the objects; I mean
the ability to write code that talks about sequences of objects even
though the program only generates one at a time.  So I'd like to be
able to write a function like this:

        -- Integer_List is a "traditional" linked list of integers
    function Nonzero_Elements_Of (List : Integer_List)
                 return sequence of Integer is
    begin
        List_P := List;
        while List_P /= null loop
            if List_P.Data /= 0 then
                return List_P.Data;
                    -- Note: this RETURN would return one integer but
                    -- would NOT terminate the function; eventually the
                    -- caller would return to this point in the function
                    -- to get more
            end if;
            List_P := List_P.Next;
        end loop;
    end;

and the caller would have primitives available to test for the end of
the sequence, get the next element of the sequence, etc.; or you'd
have constructs like:

    for Int in Nonzero_Elements_Of (My_List) loop
        ...
    end loop;

which would set Int in turn to each element returned by the function;
or you'd have ways to deal with the whole sequence, e.g. you could
pass the function result of Nonzero_Elements_Of as an "in" parameter
to another procedure that declares a "sequence of Integer" as a
parameter.  Etc.  Of course, there would be no requirement that a
sequence be finite.

Well, I can dream.  Naturally, this dream has come up again since I'm
involved in another discussion involving how to implement an iterator.

                                -- Adam

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: Ultimate Language feature list

[Mats Weber]

I made a proposal for extension of Ada 83 which includes the following features:

> #3 Object-Dot-Feature syntax.  No Ada95esque subprograms which take class
> arguments (like C++ friend functions).

> #6 Construction and Finalization

> #8 Polymorphism as the rule.  Let the compiler figure out which routines are
> not overridden and use static calls where appropriate (a la Eiffel).

> #13 Ada-style tasks.  Using Object-as-task, like the proposed Eiffel
> extension "separate".  Ada's SELECT mechanism.

It's available at
<http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html>
if you are interested.

Re: Ultimate Language feature list

[Eugene Mayevski]

Charles Hixson wrote:
> 
> Here's my features (at the end), plus some notes (interspersed):

These all features are good, but they can be also an extension of the existing language 
like Eiffel, which is now the newest and the most comfortable for development (I mean
language,
not the compilers and IDE's).

> Verbosity has it's points, but so does compactness.  Zipf's laws rules
> here.  Frequently used features should be v. short, e.g. {} is better
> than Begin End

This can be expanded in IDE. If you take a look to the Delphi 3.0 IDE, there's 
a CodeInsight feature - you press some key combination and select the language construct
from 
the list. It's cool, and better, than to shorten the language constructs. 

> style.  It shouldn't insist on it.  Byte arrays use up enormous amounts
> of storage when each byte is an object.

Byte arrays and built-in types can be optimized by compiler (as they usually do :).

> What about context specifier?  3 + 5 vs. "3" + "5" vs. 3.0 + 5
> These can all be understood by a person, a compiler might reason: given
> a number, the operation + probably means addition, so check for the next
> argument.  If types are staticly determined, then this is either
> ambiguous or determined at compile time.  The question is what to do if
> it is ambiguous at run time.  Note that the semantics is the same as
> object-dot-feature.  Ideally, syntax should be flexible, and I don't
> know what's practical.

This object-dot-features - for whom they will be useful? Not for programmer as 
the object itself can be passed as the routine parameter. 

> > #6 Construction and Finalization
> This needs to be elaborated, Final means something different in Java
> than it does in Eiffel, e.g.

Disposing of objects, may be. Constructors and Destructors work good in 
Inprise's (former Borland) Pascal.

> > #11 Multiple inheritance like Eiffel, NOT C++.
> Yes, especially the rename and redefine constructs.

Redefines or overrides? There can be two cases:
1) descendant's method must be used when the call to ancestor's one happens.
2) descedant's method must be used only when direct call happens. 

> > #13 Ada-style tasks.  Using Object-as-task, like the proposed Eiffel
> > extension "separate".  Ada's SELECT mechanism.  Protected types (like
> > Ada95), Java almost got this right.
> I wish that I understood this better.  It sounds good, but I don't know
> the details of what it means.

Parallel execution. Multithreading. When you create an object like a new task. 
TThread in Borland's OWL and VCL libraries. You create an object, tell him 
"run" and it starts running parallel to your main thread.  
Yere the advanced synchronization is required too, that doesn't depend on OS
that the program works on.

> > #20 An easy with to extend and re-expose/hide features of parents.  Like
> > Eiffel.
> No (and yes).  One needs the private type as well as the protected
> type.  Possibly there could be a Discrete type that was by default
> hidden, but which the descendants of could Peek at?

Well, Eiffel concept (the feature can be seen by defined range of other classes) 
is a good approach. 

> > #21 Distributed computing.
> Yes, but what does this mean (beyond separable threads (or tasks)?)

Actually, distributed computing is made by OS. Language only must have an opportunity
to support multithreading in a clever manner, and OS will distribute the threads
execution.

> #23 Pattern Matching primitives and forms.  A bit up in the air here,
> since I'm not sure the best way to blend it in.
> #24 Built in database (not an add-on).  This could be a compiler option,
> but needs to be an integral feature of the language, not a JDBC style
> add-on.
> #25 Good random-access I/O capability.  At least for homogenous files
> (see homogenous arrays, above) this should be easy.  I would like
> something better, however.  Something that doesn't assume that
> everything on the disk can fit into RAM, too.

This all is done by libraries. That's not a language feature. 

> #26 Support for property lists.  This could probably be done via a
> library, but it should be a part of the language definition, so that it
> is a transportable feature.

#27 Properties. When you define property as the way to read and write the feature. 
In Delphi: property Width : integer read GetWidth write SetWidth default 5;

GetWith may be a feature or a function, and SetWidth can be a feature or a procedure.
Default values must be set by creator routines. 
Properties must be overridable (that is missing in Delphi), so that I can override the
property
Width in descendants like 
  property Width : integer read NewGetWidth write SetWidth default 2;

#28. RTTI that I can access from my code. So that I can ask the class "who are you" and he
will return me
his name as string. I can ask the generic object for the list of the property names it
has, 
and I wanna ask this object to write the property names and their values to the stream and 
to read it later from the stream. I wanna get access to the VMT - (that is needed by the
language 
to be open to developers). 

#29. Standartized libraries. The library must be compiled to some pseudo-code. Then at the
link stage it will be
compiled to machine instructions and after that linked. That allows the libraries to be be
independent on 
architecture and OS (in most cases) and noone can modify copyrighted libraries. And there
will be no need to 
compile the library for 25 architectures, 123 OS, 1250 IDE's and compiler manufacturers. 

#30. Class features and Class properties. So that I can access them when no objects of
this type is created.
This means that they are stored in RTTI info and are changable in run-time. 

#31. IDE. Smart IDE with CodeInsight, Code Completion, visual designer. Good IDE,
intuitive, useful.
The best I have seen is Delphi and C++Builder IDE. 

That's all can be easily done, if started :).
Who's gonna start a new language? ;)

-- 
Bye!
Bugsy Wabbit      E-Mail:  mailto:Eugene_Mayevski@usa.net
		           http://www.ig.com.ua/wabbit
                           ICQ: 9409786
                  FidoNet: 2:463/209

Re: Ultimate Language feature list

[Rainer Joswig]

adam@irvine.com writes:

> Well, as long as we're talking about what language features we want,
> here's one I've always wanted: The ability to deal with sequences of
> objects.

Well, read Abelson and Sussman's classic book "Structure
and Interpretation of Computer Programs". What you are
looking for is called "streams".

Common Lisp has a library called "series" which
does these things and is able to compile it
to efficient code. For a description
of "Series" see "Common Lisp the Language, 2nd Edition"
by Guy L. Steele Jr.:
http://www.lavielle.com/~joswig/cltl2/clm/node347.html#SECTION003400000000000000000

This stuff is a decade old now.

Another thing worth looking for is the STL for C++.

Re: Ultimate Language feature list

[John English]

Rainer Joswig (joswig@lise.lavielle.com) wrote:
: adam@irvine.com writes:
: > Well, as long as we're talking about what language features we want,
: > here's one I've always wanted: The ability to deal with sequences of
: > objects.

: Well, read Abelson and Sussman's classic book "Structure
: and Interpretation of Computer Programs". What you are
: looking for is called "streams".

Or possibly Icon-style generators?  I've always thought that this
was a nice idea...

Here's another wish: closures.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Ultimate Language feature list

[Michael F Brenner]

It is interesting that the original feature list is dynamic
(garbage collection, etc.) and as opposed to static, and is
therefore an ideal system to use for non-realtime systems.
Several of the features in the list would be unusable for
satellites that must continually fly for dozens of years.

It is good to post preferences in language features, so that
growth continually evolves.

Re: Ultimate Language feature list

[Charles Hixson]

This is where language appendixes are important:  They allow one to
define the standard form that features should take were they present,
but frequently do not demand that all implementations support them. 
E.g., database semantics NEED to be defined, but many applications have
no use for them.

Michael F Brenner wrote:
> 
> It is interesting that the original feature list is dynamic
> (garbage collection, etc.) and as opposed to static, and is
> therefore an ideal system to use for non-realtime systems.
> Several of the features in the list would be unusable for
> satellites that must continually fly for dozens of years.
> 
...

-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

Re: Ultimate Language feature list

[John McCabe]

mfb@mbunix.mitre.org (Michael F Brenner) wrote:
>It is interesting that the original feature list is dynamic
>(garbage collection, etc.) and as opposed to static, and is
>therefore an ideal system to use for non-realtime systems.
>Several of the features in the list would be unusable for
>satellites that must continually fly for dozens of years.

There are features of all languages that some might consider as 
"unusable" for satellites. In fact I know from experience that in the 
early days of Ada 83 usage in space, there were quite a few codes of 
practice that forbade the use of generics, tasking, access types and so 
on. Anything "dynamic" seemed to be considered a bad thing.

My personal opinion is that this is ridiculous. It is possible to use 
dynamicism and still be safe and reliable, it just requires more 
discipline from the programmer and, in some cases,  a clear understanding 
of how a feature is implemented by your choice of compiler.

-- 
Best Regards
John McCabe

=====================================================================
Any opinions expressed are mine and based on my own experience. They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Ultimate Language feature list

[Nick Roberts]

My pet ideal language (called 'Babbage', I don't know if this is original),
has the following essential features:

* the 'core' is a byte-code interpreter (like JVM but lower-level and more
general-purpose (very like P-code I suppose)), with the well-known attendant
advantages;

* the syntax is totally flexible, based on prefix, infix, and postfix
operators (a bit like Prolog), with primitives only for literals (numeric,
character, set, and vector);

* in particular, there is no special syntax for code (e.g. a sequence of
statements is simply implemented as a vector literal, and parallelism is
achieved simply as a set literal);

* only very low-level constructs are implemented directly (e.g. 'set value',
'jump', 'read value', 'add', 'subtract', etc.), and are directly equivalent
to byte-codes;

* a language of any level of power can be built up from these simple
components (e.g. the functionality of LISP, Prolog, SmallTalk, and better,
all in one);

* in particular, (interpreted) Babbage programs would have the (ready)
ability to modify themselves as they execute, giving rise to many
interesting possibilities (e.g. program self-healing via the Internet,
program end-stage development/refinement by tame users, intelligent
'learning' self-improving programs);

* each programmer can build exactly his/her favourite 'language' and
environment (this needn't be a disaster: conformity could be imposed as
required, to the extent required, in specific circumstances);

* suitable subsystems can be compiled native, and the compiler can (very
conveniently!) be written in Babbage.

Also, the intention is for the native character type to be Unicode, so that
many (or most?) symbols which have to have clumsy equivalents (e.g. * for
multiplication, / for division, as well as 'executional sequence' (a plus in
a circle), 'executional parallelism' (I don't know), and any number of
others) can all eventually be replaced by the proper symbols.

I think it is perhaps interesting to note that, as I have it at the moment,
this language tends towards very concise names. This is partly because the
language is modelled somewhat on mathematical notation (which tends towards
extreme 'conciseness'!), and partly, I think, because if you take real care
with your nomenclature, you can achieve conciseness while still avoiding the
pitfalls of ambiguity and confusion. I haven't yet solved the problem of
name spaces (i.e. name clashes!).

[Oh, and in case you're wondering, ThoughtWing Babbage will be available at
a retailer near you anytime Real Soon Now!]

PS: There was a language called 'POP' once. Has this language since died a
death?

PPS: Dubious claim to fame: Professor Popler, the great maths genius, after
whom the above language was named, lives near me!

--
Nick Roberts
ThoughtWing Software, Croydon, UK
ThoughtWing@dial.pipex.com

MSG [ Michael Scott Garnett michael@pickles.org ]
wrote in message <6jc18b$lug$1@news.eclipse.net>...
|I do all my development in C++.  Not necessarily because I want to, but
|because I keep looking (and looking) for alternate languages/environments
|and they ALWAYS come up short.  I've decided that the language/environment
|for me hasn't been created, so I'm starting a list of features that I
|like/require.
[...]

Re: Ultimate Language feature list

[Chris Miller]

I always understood that the "ultimate" language was, by definition, an
interpreter for the English language !.

Chris Miller
chrismil@ozemail.com.au

Re: Ultimate Language feature list

[Fergus Henderson]

Have you considered Sather?
It satisfies most of these requirements.

"MSG" <michael@pickles.org> writes:

 >#1 Verbosity.  C++ and Java's cryptic syntax is cute and fun, but not
 >useful.  Our Language (OL -- come up with a good name) should be verbose
 >like Ada and Eiffel.  Semicolons optional like Eiffel (except where
 >ambiguous).
 >#2 Completely OO.  No free floating subroutines.  The only construct higher
 >than a CLASS is an Organizational Unit (like an Eiffel cluster).
 >#3 Object-Dot-Feature syntax.  No Ada95esque subprograms which take class
 >arguments (like C++ friend functions).  I am torn between Object-Dot-Feature
 >and Object SPACE feature syntax (like Smalltalk).
 >#4 Reference Objects as a default with the ability to expand an object or
 >class to full form (like Eiffel EXPANDED types)
 >#5 Garbage Collection.
 >#6 Construction and Finalization
 >#7 Predictable Finalization for stack-based objects (either reference or
 >expanded).  When the immediately enclosing scope terminates, the
 >finalization is called THEN. This is VERY important for reliable external
 >resource management (OK, C++ did this right).
 >#8 Polymorphism as the rule.  Let the compiler figure out which routines are
 >not overridden and use static calls where appropriate (a la Eiffel).
 >#9 Named arguments.  Either like Ada or like Smalltalk (object moveTo: here
 >usingPath: aPath).
 >#10 Array and record aggregates (like Ada).
 >#11 Multiple inheritance like Eiffel, NOT C++.
 >#12 STRONG typing and constraint/program checking in the compile and runtime
 >like Ada.  Options to remove such features in a "finalized" version is very
 >much necessary.
 >#13 Ada-style tasks.  Using Object-as-task, like the proposed Eiffel
 >extension "separate".  Ada's SELECT mechanism.  Protected types (like
 >Ada95), Java almost got this right.
 >#14 EASY access to other languages/calling conventions.  Any CLASS's
 >features my be effected by external other-language routines. The includes an
 >easy way to link to C++ libraries.  Such special classes can specify that
 >for "THIS" an other-language-notion be used. Such classes would lack
 >"variables", being limited to routines only.
 >#15 Generics.  Not templates.
 >#16 Intrinsic types (like Integer) as objects, but completely replaced in
 >generated code by native types (like Eiffel).
 >#17 Ada's float types (delta, digits).
 >#18 Range specifications (like Ada).  Checked at compile time and run time.
 >#19 Discriminated record/class types (like Ada).  Checked at compile time
 >and run time. (maybe not necessary with inheritance)
 >#20 An easy with to extend and re-expose/hide features of parents.  Like
 >Eiffel.
 >#21 Distributed computing.
 >#22 Pre- and post-conditions (from Eiffel).  Including support for the "old"
 >keyword.  The closest thing to Z (pronounced Zed - a formal method) that
 >I've seen.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Ultimate Language feature list

[Jussi Santti]

Mark K. Gardner wrote:
> 
> [By all means, please post an announcement when you have found, created,
> begged, borrowed, or even stolen the ultimate language! :) ]

Ultimate language, in general, may be quite far away.
The features list, I think,  aims at a system programming language.
For a still more specialized language, machine oriented language
or portable assembler we not only have a list but the "ultimate" language: C.

Jussi
> 
> Mark
> 
> --
> Mark K. Gardner (mkgardne@cs.uiuc.edu)
> University of Illinois at Urbana-Champaign
> Real-Time Systems Laboratory
> --

Re: Ultimate Language feature list

[Nick Leaton]

MSG wrote:

> #10 Array and record aggregates (like Ada).
> #19 Discriminated record/class types (like Ada).  Checked at compile time
> and run time. (maybe not necessary with inheritance)

Please explain these a little more.

-- 

Nick

Re: Ultimate Language feature list

[Franck Arnaud]

Chris Miller:

> I always understood that the "ultimate" language was, by 
> definition, an interpreter for the English language!

Why English then? Many human languages, existing or thinkable, are
better. English is some sort of C++ of human languages, not very well
designed, lots of legacy constructs and inconsistencies, pathetic
standardisation, etc, but it is popular and widely used.

Re: Ultimate Language feature list

[Stephen Bull]

Chris Miller wrote:

> I always understood that the "ultimate" language was, by
> definition, an
> interpreter for the English language !.
>

Ugh! I hope this was not a serious suggestion: natural language
is far too ambiguous to be a useful implementation language.

--
-----------------------------------------------------------------------------

 Stephen Bull  Praxis Critical Systems  20 Manvers Street  BATH
BA1 1PX  UK
               +1225 466991 (switchboard)  +1225 469006 (fax)
          Views expressed are not necessarily those of my
employer
-----------------------------------------------------------------------------

Re: Ultimate Language feature list

[Fergus Henderson]

In comp.lang.ada and comp.lang.eiffel,
adam@irvine.com writes:

 >Well, as long as we're talking about what language features we want,
 >here's one I've always wanted: The ability to deal with sequences of
 >objects.  I don't mean a list of objects where you have to create an
 >array or linked list in memory that contains all the objects; I mean
 >the ability to write code that talks about sequences of objects even
 >though the program only generates one at a time.  So I'd like to be
 >able to write a function like this:
 >
 >        -- Integer_List is a "traditional" linked list of integers
 >    function Nonzero_Elements_Of (List : Integer_List)
 >                 return sequence of Integer is
 >    begin
 >        List_P := List;
 >        while List_P /= null loop
 >            if List_P.Data /= 0 then
 >                return List_P.Data;
 >                    -- Note: this RETURN would return one integer but
 >                    -- would NOT terminate the function; eventually the
 >                    -- caller would return to this point in the function
 >                    -- to get more
 >            end if;
 >            List_P := List_P.Next;
 >        end loop;
 >    end;

I think you just reinvented Sather's `iterator' language construct.
Of course, some of the syntactic details are different, e.g. if I recall
correctly, this sort of iterator `return' is spelt `yield' in Sather.
But the basic concept is pretty much the same.

 >Well, I can dream.

You can do better than dream -- the Sather compiler is freely available,
so you can download it and try it out! ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Ultimate Language feature list

[Tarjei T. Jensen]

Nick Roberts wrote:
> 
> My pet ideal language (called 'Babbage', I don't know if this is original),
> has the following essential features:

You are too late. The name has already been used for a programming
language. It was described in a celebrated article in Datamation around
15-20 years ago.


Greetings,

-- 
// Tarjei T. Jensen 
//    tarjei@online.no || voice +47 51 62 85 58
//   Support you local rescue centre: GET LOST!

Re: Ultimate Language feature list

[John Volan]

Stephen Bull wrote:
> 
> Chris Miller wrote:
> 
> > I always understood that the "ultimate" language was, by
> > definition, an
> > interpreter for the English language !.
> >
> 
> Ugh! I hope this was not a serious suggestion: natural language
> is far too ambiguous to be a useful implementation language.

Indeed, as has been proven in any number of cautionary tales involving
genies-in-a-bottle and magic wishes.  What comes to mind is a fantasy
short story of recent years (can't remember the title or author) in
which a well-meaning but fatally tongue-tied protagonist attempted to
resolve all human conflict but instead unleashed a world-wide ecological
disaster by uttering the fateful words:

        "Let there be pease on earth."

At which point the porridge rains began... :-)

-- 
Signature volanSignature = 
  new Signature
  ( /*name:      */ "John G. Volan",
    /*employer:  */ "Raytheon Advanced C3I Systems, San Jose",
    /*workEmail: */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail: */ "johnvolan@sprintmail.com",
    /*selfPlug:  */ "Sun Certified Java Programmer",
    /*twoCents:  */ "Java would be even cooler with Ada95's " +
                    "generics, enumerated types, function types, " +
                    "named parameter passing, etc...",
    /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i, " +
                    "so loading them throws DontQuoteMeError. :-)" );