NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/amiga/misc/16875

Internet Message Format | 1992-11-15 | 7.6 KB

Xref: sparky comp.sys.amiga.misc:16875 comp.sys.amiga.advocacy:29164
Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!apple!decwrl!contessa!mwm
From: [e-mail] (Mike Meyer)
Subject: Re: Programming
Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.advocacy
Distribution: world
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
Keywords:
Summary:
Message-ID: <[e-mail]>
Date: 15 Nov 92 12:22:01 PST
Organization: Missionaria Phonibalonica
Lines: 169

In <[e-mail]>, [e-mail] (Robert Fentiman) wrote:
> In article <[e-mail]> [e-mail] (Mike Meyer) writes:
> >These sound like things you want to write games, or to do
> >presentations. They also aren't unique to AMOS; any serious multimedia
> >or presentation tool has those capabilities.  I'd be surprised if most
> >of those aren't better for building presentations than AMOS. Guess
> >what that leaves AMOS most suitable for?
>
> LOTS of stuff.  I HIGHLY doubt that multimedia or presentation tools
> have the versatility of AMOS.  How many multimedia programs let you
> write spreadsheets and databases.

Most of them.

> I suggest you find someone so you can look at the AMOS manual.

Well, since I don't know anyone locally who uses AMOS, I have to ask
on the net. You're handy. Want to mail me a copy of yours?

> >Utilities can? System-friendly, AUISG-compliant utilities? The
          ^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^
> >evidence indicates otherwise.
>
> Database, Spreadsheet, Video-Titler, etc...

What utilities you can write is immaterial. Almost any multimedia tool
can do most or all of those. What matters is the stuff you ignored; the
stuff I underlined.

If AMOS is so all-fired easy, it should be *TRIVIAL* to write a
utility (any utility; you choose it) that meets those criteria.

> >I'd be surprised if it's really super-simple compared to all other
                                ^^^
> >languages.
>
> Then obviously, you haven't even ATTEMPED to look at the contents of an
> AMOS program (in other words, since you haven't programmed in it, you
> are NOT qualified to judge if it is simple or not).

You're wrong - I have read AMOS code. It's a modern BASIC with lots of
gaming extensions. If that's radically wrong, let me know.

In the meantime, are you qualified to judge *ALL* other languages?
There are LOTS of languages that make assembler or the FORTRAN family
(Pascal,C,Algol,etc.) look painful; they share features with the BASIC
family. There are languages that let you do the equivalent of your
LOADIFF example with 0 lines of code (click on insertion point; click
on "loadimage"; use file requester to select the file; done).

> I have programmed
> in AmigaBASIC, C, Pascal, AmigaDOS scripts, UNIX scripts, and AMOS
> definiely IS EASY.

Ignore the last question - if that's the limit of your experience, you
aren't qualified to judge if AMOS is easy. Try AmigaVISION, CanDo,
SAS, the Director, Visual Basic, enough Scheme to understand
continuations, and SmallTalk. Then tell me that AMOS is
"super-simple".

>  The things amos does teach is modularity

It does? Then the people who wrote the code I looked at are poor
students.

> Since you haven't esatablished you PROOF (as you have VERY little experience with AMOS)

All I ask is that someone show that someone state for certain that you
can disable the buggy AMOS behavior. That's pretty easy, isn't it.

> >> C is a good language,
> >
> >Giggle. Oh well - I guess that's to be expected if you think that
> >typical AMOS behavior is acceptable.
>
> I suppose that comment is to be expected for a person who is closed
> minded that ALL languages have advantages over others.  So exactly what
> DO you think is a good language?

Sorry, I *know* that all languages have advantages over others. AMOS
is pretty clearly OK for writing games. Unfortunately, it apparently
has bugs that nobody knows how to work around, which makes it
unsuitable for anything else. C is OK as a portable assembler; there
are better languages that fill the "high-level assembler" slot (Turing
and Euclid come to mind), but they don't cover the "portable" half as
well.  Mostly, they're better because they don't have the syntactic
warts that C has.

As for what I think is a good language, I'll tell you what I *want* in
a language. Let's start with a clean, regular syntax, because that's
least important. However, the programmer needs to be able to extend
the syntax, and a clean syntax helps a lot there. Likewise, the
programmer should be able to add data types and operations on them
that are indistinguishable in use from the built-in types and
operations. There should be built-ins for manipulating extensible
collections of data, preferablly in an ordered fashion. It should have
a garbage collector, so you don't can't make allocation errors.  You
should be able to created code/data objects that use the same code
with different objects as a primitive operation. The type system
should *not* be tied to machine objects; I personally prefer dynamic
typing until something clearly superior emerges. There are probably
others I forgot.

Now, which languages have you worked with that meet those
qualifications? None in the list you gave earlier, certainly.

> However it is the best I've seen.  Tell me a better one (this is NOT a
> rhetorical question).

Posted elsewhere.

> Do they have the same graphics, sound, and
> animation capability with the same ease.

I don't know, but I suspect the answer is "yes".

> To play a MOD file in amos, you type Music "<music name>".

What? No point-and-shoot? And you call this simple?

> Are they limited to a compiler or an interpreted environment?

Some yes, some no.

> Do they support CDTV?

All of them can be used on CDTV.

> Are there any professional programs written in these languages (for
> amos, the award winning Fun School (?), from the Fun, 2, 3 series of
> educational software (another non-game use of amos))?

Yes, there are. And their professional programs *behave*
professionally - they don't shut down intuition control, and they
don't interfere with the operation of other programs. The
"professional" AMOS programs I've seen don't manage that.

> When you 'LoadIFF "pic"' and get your pic, that is a proper result.

When doing so interferes with the operation of other programs on the
system (except for sliced ham and similar hacks), it is *not* the
proper result.

> The techniques are the same as ANY form of BASIC

That's a pretty strong mark against AMOS. Any BASIC? No structured
control constructs? Remote code instead of subroutines, no functions,
single-letter variable names, types determined by magic characters in
the file name? Those are the techniques of SOME BASICs. I hope AMOS is
actually more like a modern BASIC than that (in fact, I'm sure I saw
some of those things in the code I read).

> addresses and copper lists without having to worry much about them).
> Are you disputing B.A.S.I.C. ("Beginners All-Purpose Symbolic
> Instructional Code)            ---------
> -------------       as not being good for learning programming, the
> purpose of the language?

Yes, I'll argue that BASIC is not good for learning programming. If
you want, I'll even dig ou the citations that refer to BASIC as a
childhood disease (Wirth, among others), because it gives people bad
habits. Since AMOS has made it to the '70s in terms of language design
(i.e. - it's a modern BASIC), we're talking about different bad
habits. And they probably aren't wired into the language, they're
wired into the package.

    <mike