Web Page Update

[Matthew Tuck]

DataHunter wrote:

> Telnet crashed on me, so I lost the email I was composing ...
> This is what pine saved of it, and what I rewrote.

Coincidentally enough, the message you replied to also resulted from a
crash, but I was lucky enough to fetch it from one of the obscurely
named temporary files on disk.  I guess that says something about
writing long messages.

> Someone once told me that a large part of a modern program is devoted to
> string manipulation of some sort, be it getting information from the user,
> interpreting other forms of input, or creating output. I would think twice
> about writing such a program in C since I'd first have to create a
> suitable set of string routines.

I think you're overstating the problem here.  I have written various
programs in C before without any hassles.  Of course that doesn't mean I
didn't just grin and bear it without even realising it, especially
probably due to my lack of knowledge of Perl.

Good string handling is certainly important though, and it would be used
often enough to include a good string handling library.  I don't think
there's too much that should be done at the language syntax level to
support string handling than is already done in C, again, maybe, again,
because of my lack of Perl knowledge.  I'm wary of giving one data type
special priveleges over others, as it's my opinion that you get a more
general and simple language by providing general facilities to all types
and put special stuff in the library.

Also, it might be relevant here to say that I dislike it when the basic
types are a separate entity from the user-defined types.  By this I mean
they have special properties, the most common in OOP languages being
basic types are implemented as straight data and user-defined types are
implemented as pointers to data, each having different meanings, and the
other equally most common that the basic types don't descend from the
root class of the inheritance hierachy.

Have you heard of SNOBOL?  It's meant to be a string processing
language, although I haven't had the chance to have a look at it.  I'm
not sure how it'd relate to Perl.

> Granted, that's what C is about. You build what you need, and the language
> strives not to give you what you don't need (whereas other languages may
> include all the overhead of functions your program never uses). However, I
> think languages *need* string types/classes, to free the programmer to
> work on other parts of the program.

What do you mean here by "overhead of functions your program never
uses"?  As far as I can see this second, anything in the library won't
impact on efficiency if it's not run.  Unless you're talking about a
library which does certain unnecessary things in case you do an
operation you aren't going to do, in which case you've hit an
interesting issue.

The majority of this sort of stuff can be cleanly done in an optimiser. 
Sure, it may take a little longer, but then you don't need the full
optimiser until final compile, and you just saved time programming due
to the language's rich complexity.

I may be off the mark, but I don't think so, when I say a large number
of optimisations are not taken advantage of because of the object code
crew.  The object code crew take source files and compile them down to
object code, then link them together to form a program.  The trouble
with this is that a number of potential optimisations (the sort which we
were talking about above included) are only possible at link time when
you can see the whole program.  But they've already compiled the program
down to a level that makes it impossible.

The alternative is to store slightly processed source files, say an
abstract syntax tree or whatever if you know what that is.  The full
range of optimisations become possible and we do the compilation to
object code after linking these together.  So why isn't it done this
way?  The main reason I see is security - a higher level file is easier
to decompile to the original.  But I don't consider that enough
justification for losing all those benefits.  Another possible reason is
that these object code files are often standard on an OS, but then a
standard shouldn't and usually isn't followed when it is technologically
inferior, although this might give the programmer access to the OS
tools.


> So, in short, I guess it's a matter of functionality ;) .

Functionality is the main reason I like Java so much.  As you can
probably figure by now, I like large libraries.

> I have two 'problems' with Visual Basic. One is the fact that what used to
> be (at least to me) an intuitive language, has now become extremely
> complicated. Using databases in Visual Basic is all but impossible, and
> heaven forbid you should try to do anything remotely advanced in Visual
> Basic, such as socket connections. In theory, it is designed to be easy,
> and perhaps during my attempts I went about doing it wrong; anything is
> possible.

Things designed for beginners tend to get in the way of experts.

> My second 'problem' is the VB runtimelibraries, and, until VB 5, the way
> VB produced P-code rather than true compilation.. Delphi and PowerBasic
> don't require a 1.5 MB DLL to run programs. You can also create
> console-mode 32-bit applications in Powerbasic. VB has a minimum .EXE size
> of probably 500k, where PB has about a 40-100k minimum.

Java does a similar thing.  However, Just-In-Time compilers compile JVM
code into native code before running it.  Interestingly enough, I read a
tech paper last year that claimed this could be quicker that
precompiling, I'll fetch the reference if you're interested.  The basic
gist is that the uncompiled version is smaller than the compiled
version, so that with the widening gapp between memory and hard disk,
JIT is becoming more feasible.  This wasn't with the Java bytecodes
though, which the paper though were an unfortunate representation.  The
paper was called "Slim Binaries".

The separate distrbution is a problem of course, one which I'll have to
worry about when I start distributing my Java application.  It's not an
applet so it can't live off web browsers, which would remove the
problem.

> In some of those cases, such as C++, it seems (and I'm hardly an expert on
> the subject) that the dialects came about due to competing businesses
> trying to outdo one another.

That's pretty much always the way with competing standards, although the
only sibling to C++ I've heard of is Objective C, and Java is a child of
C++ rather than a sibling.

> AFA the differences between PowerBasic and Visual Basic, I guess that it
> is an implementation issue. One, Powerbasic had similar legacy issues to
> what Microsoft faced, in updating its own Visual Basic. Two, PowerBasic
> did it *much* better.

Examples?

> These issues certainly make sense. C and Perl are not the prettiest of
> languages, to say nothing of how they deal with the other issues.

Don't be afraid to elaborate.

> My point in saying that certainly isn't to say this is a bad idea. I am
> just curious to know what will attract users to use this language. I
> imagine, however, that will be the same as what attracts users to any
> other language.

Well you could list several, which I'll try to rank from what I think
are the most important to the least important:

(a) good tools are available
(b) you were taught it/recommended it/had to use it
(c) does what you want

> > 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 ...

> I like the 'compile to C' idea, if that's what you mean here. I am biased
> toward C, though ;) . I'm not a particular fan of Java, but it is popular
> enough, and the JVM is already available for many platforms.

Yes, C is pretty popular for the target language from what I've seen. 
The GCC interface is another option, but I'm not sure if this would
bring us within the realms of the GNU GPL, which might not be what we
want.  C isn't too good for programming code without bugs, but
compiler-generated code is another matter entirely.

The JVM gives us instant cross-platform ability, and also the facility
to write browser applets in our language .  There's no reason why you
couldn't do it in another language as far as I can tell, as long as you
output Java bytecodes, but there might be some problems with mixing the
applet security model and our language.  I'm not sure just what we might
want to do that won't be supported by the JVM.

> Win32 is indeed the most likely candidate for first choice; it would be
> hard to argue w/that. AFA which other OSs we should support, we should
> consider them based on our ability to replicate all or a large part of the
> features which will already be present in the Win32 edition.

I'm not sure what you mean here.  Are you saying we should tailor our
language so that it has Win32 features and only support it on other
platforms if it can?  Java has show we can squeeze a fair amount of
functionality with sacrificing cross-platform support.

> A House/Senate type voting system (one based on experience/knowledge, the
> other based on just being a member of the project) may be a good idea,
> there.

Maybe, but just what should go up for a vote?  In terms of making this a
free software project, the code should be able to be modified by anyone
and distributed or redistributed by anyone, this has worked well for
Linux.  But I think we need a "standard" distribution from which the
main amount of work would go into, which would be voted upon.

> "... the integration of functional programming into an object-oriented
> language ..." You mean the integration of C like functions into something
> like C++ ? I don't think I understand what you mean here.

Do you know what functional and logic programming languages are?  If
not, I'll get into that later.

> I've heard complaints about the Java VM; not providing enough control over
> objects, etc. I don't know how they apply to this project, should we
> decide to use the JVM.

Not sure why you're referred to here, I'm not a JVM expert by any
means.  Any references you might provide would be helpful.

> I meant the latter, as in ActiveX\Java, through the use of the Java VM, or
> a custom VM.

I think compile to the JVM is the best option at this stage - it's the
standard.


> > 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.
> 
> Sad but true of computer technology in general as well ;) .

Yes, I think it's important to keep an element of realism and realise
the effects of the project might not be readily apparent.

> AFA the perl thing, I should have some time this weekend to hammer
> something out. I've been ultra busy (no pun intended ;) ) getting ready
> for school and military duty (I'm a reservist).

No problem.  As far as the Perl thing, I've changed my mind as to the
nature of the file to insert, although I'll still accept the old program
if you find the previous easier, although I think they're of about the
same difficulty.

I'd now prefer it to be HTML.  Basically take whatever is in between the
<BODY> and </BODY> tags in the file to be inserted and insert that into
the template file.  This allows me to insert hyperlinks and stuff into
the individual files, where the links are to say an external site. 
Still do the manual hyperlinking between the files in the directory, but
of course you'd only do it outside of HTML tags.

If you don't have a lot of time, a version without the manual
hyperlinking would be fine to start with.

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