Ultra Project

[Matthew Tuck]

DataHunter wrote:

> I despise contrived complexity. Programming languages should make simple
> tasks simple, and more complicated tasks more complicated. That sounds
> somewhat obvious, but I have observed that this isn't always the case. C
> and string handling come to mind, as do Visual BASIC and (insert just
> about anything here).

OK, what don't you like about the string handling?  Is it the string =
pointer to character array idea, the lack of functionality, or something
else?

I think Visual BASIC has various "legacy" features that hark back to
BASIC.  You won't find many languages written today that allow variables
to be used with declaration, for example.  You may be talking more about
the library side of the language here though.

It's a case in point in what happens when you take a language and modify
it over and over again - it turns out a mess, through the necessity to
be backwards compatible with previous versions.

Look at all the general-purpose languages in use today - FORTRAN, COBOL,
Pascal, Ada, C++, Java, BASIC, etc.  They all have several
dialects/versions!

> I have a love-hate relationship with C. It's powerful, and pretty simple
> to learn, but its string handling leaves a lot to be desired. I haven't
> played too much with C++, but I suspect that I'd have the same complaints
> about it.

It's basically the C language with object-orientation, exceptions and
generics tacked on, along with a few miscellaneous features.  These
features are all important, but in my opinion there are a few features
of C which could be nuked or refined after these are added (procedural
parameters come to mind).  It's better than C to use, for sure.

> Visual Basic is hardly basic, and the requirement of all those DLLs is
> ludicrous, if compared to, say, PowerBASIC or Delphi.

Is this an implementation issue?

> > (c) any suggestions for improving programming languages that you might
> > have.

> No ideas on this, as yet. C, Perl, and PowerBASIC do just about anything
> I've ever needed to work on.

The issue here is not always about functionality, and it's a big trap to
fall into to assume this.  While very important, so is readability,
portability, maintainability, allowing faster development, prevention of
bugs, etc.

> AFA the project, I'm not sure the world needs yet another programming
> language, but that shouldn't stop us; hasn't stopped anyone else ;) .
> What platform will be targeted initially ? What will the language
> specialize in, or be geared toward ? Will it be interpreted ? Compiled ?
> Will it, like Java and VB, be usable as a script in a web browser ?

Yes, there are lots of languages and I hear that sometimes, but what is
the problem?  It shows a thriving field, with lots of ideas.  Creating a
language for the sake of it is dubious - creating a language when you've
got something to say is good, and I've got a notebook full of things to
say, but that's for another day ...

As far as platform is concerned, of course we will try to develop the
front end of the compiler as target platform-independent as possible. 
In terms of the back end, it is certainly going to be heated.

The Java Virtual Machine might be a choice since it is
platform-independent, and runs in browsers.  C is a popular choice in
non-commercial compilers since it can itself be compiled to different
platforms, but we'd probably have to write some sort of library for each
operating system we interface with, whereas the JVM idea would be
open-ended as it would require no work from us to be used on a new
platform, rather work from others ...

Win32 might be something to consider, and then you've got MacOS, Win16
and Unix (assuming we can write it for all UNIX's).  If we're going to
go native, I don't think anyone, being selfless, would disagree Win32
would be the first choice, but how many we should support would be an
interesting question.

This also brings up an interesting point - how to resolve disputes? 
Some sort of voting system, but who can vote, and is the value of each
vote equal to all others or dependent on involvement, experience or
knowledge?

Maybe rather than individual votes, we would let the day to day
questions be answered by an elected person/people (on an equal vote
basis by some definition of a voter) and allow overruling if desired by
the members and votes to be submitted for important issues.

What will the language specialise in?  Another heated issue.  Well, I
want it to be general-purpose, and I have a personal intense belief in
object-oriented programming - I've seen the advantages it has over
traditional imperative programming, and I understand it well.

But there are other paradigms of course.  One of my personal "crusades"
is the integration of functional programming into an object-oriented
language.  Logic/constraint programming is also useful, but I believe it
can be integrated at the library level, as can database (SQL)
functionality.  This might not have been what you meant - if not,
elaborate.

The compiled/interpreted question is interesting again.  I think
interpreting source files went out of vogue a long time ago, so we can
safely ignore it as a quick and dirty way to get a language
implementation going, which we might use it as, but for nothing beyond
that.

If we were compiling for the JVM, then certainly that will be
semi-interpreted.  Otherwise, I think compilation is still best, unless
we want to develop another Java style VM if the old one doesn't suit us,
but supporting that on all platforms would be a killer!

By supporting web browsers such as Java and VB, are you referring to
JavaScript and VBScript?  If so, I think no, we don't want 100 languages
being supported in a browser - standards are important here.  If not,
then you're probably talking about VB as in ActiveX, and I would say
Java would be the choice here - platform-independence.

At the moment I don't see that we necessarily should try to design a
language that will be "used".

Firstly, since languages that are a success tend to be so for bad
reasons (e.g. first released that does something, promoted by an
influential organisation, etc.), and rarely, if ever through
technological superiority.

Secondly, if a language is used, we would be inclined to have to improve
on it, which is basically the situation I was mentioning above with C++
and VB, as well as various iterations of the old fogeys FORTRAN and
COBOL.  The ideal situation from a language design, if maybe not a
compiler designer or vendor point of view would be to throw features out
if they don't work.  Anything else might hold the language design part
of the project back.

Of course, if use came about, that would be fine - of course I think we
should develop tools that are usable - I hope to one day switch my
programming to a language and tools that we develop.  But trying to
achieve this might not be such a good idea.  I realise that it probably
might be a powerful idea for many people to get a language you
contributed to used by millions - but the chances are slim.  Many more
languages have contributed to the design of popular languages 10-20
years into the future than have been popular themselves, and that would
be a reasonable initial aim.

> I think I may be able to help get a mailinglist. I can probably let you
> know by Monday.

That would be great.  As the project expands, managing a CC list will be
impossible.  Any new member would have to be announced to everyone to
add to their list.  Then there's the fact that just joining a mailing
list would be a lot less intimidating to people than mailing me.

> I've done something like this in Perl (and there are Perl implementations
> for Windows 95/98/NT). If you elaborate a bit more, I may be able to work
> on it.

Yes, this sounds like the sort of thing that Perl would be good for. 
I'm not sure what you don't understand, but I'll try to elaborate.  I'll
assume you have a rudimentary understanding of raw HTML.  If not, choose
view source in your browser on a web page and you should be able to
understand from examination.

Basically I have a bunch of text files in one directory.  I also have a
HTML file which is used as a template for the style of the final
generated files (fonts, sizes, headers, footers, etc.).

The HTML file has a tag that is "<HEREBODY>".  This is a place holder to
put the text from each of the text files.  For each text file, it gets
merged with the HTML template to generate a HTML file.  Basically the
HTML file defines the style of the page, so I can make all the final
HTML files look a certain way by just editing the template and rerunning
the utility.  The text in the text file replaces the "<HEREBODY>" tag.

Each text file obviously has a file name, which would be used as a
title.  This would be put in the part of the HTML file that says
"<HERETITLE>".

The title would be used as well for establishing hyperlinks between the
final HTML files.  For example, if in file "A", the title of file "B"
appears, i.e. the text "B", then clicking on "B" gives you a link to
file "B".

So if I was viewing a file on say dead code elimination and it mentioned
data flow analysis, which I also had a file on, I could click on a link
to go there.

Efficiency is not a major concern - at least at first.


And if some or all of that made no sense to anybody, please pipe up, as
discussion is vital!

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/