@database AMOSFuture.html
@remark Converted with HTML2Guide ©1997 Mark Harman
@wordwrap

@node MAIN "AMOSFuture.html"
@{"b"}The Future of @{"i"}AMOS@{"ui"}?@{"ub"}  

While we may be concerned about the future of our favourite platform, for many an AMOS coder, there is the problem of this language's future.  

The problem? As you surely know, AMOS was stopped being developed a few years ago, as a result, it is now quite out of date. And as far as the future is concerned, things can only get worse. PowerPC will be the biggest problem (as great as PPC is); firstly, the AMOS Pro editor won't run on PPC, without emulation. And also of course, any programs you write and compile will be for 680x0 machines, and not PPC based systems.  

Unlike other types of programs, such as a paint package, it is much harder to change from one language to another. But if you wanted to, what could you choose? The favourite choice for many has been Blitz. Like AMOS, it is based on Basic, and it supports the OS and AGA as standard - and it is still being developed. But... I've tried learning Blitz, and I just don't like it. I think the biggest reason is the rather poor editor, nowhere near as good as AMOS'. Also the language itself isn't that easy - and I have heard others say similar things. Before I upset many a Blitz coder, let me say, I'm not saying that AMOS is better than Blitz (or vice versa), it's just that I've learnt AMOS, I like AMOS, so I'll be damned if I have to learn an almost completely new language just because my choice is no longer being developed. (You see, they may both be BASICs, but otherwise they are quite different). As for other languages, their is C/C++, and this would be a great choice for future support (especially with StormC++), but it's a pretty bad state of affairs if you have to learn C when you'd rather learn something easier. This is even more true with Assembler.  

Of course, extensions come to the rescue, and have greatly enhanced AMOS, like... OS Devkit, which was used for Vision ;) - but don't forget the likes of J Windows and GUI Extension, as well as many other different extension. Unfortunately, there is no AGA extension (at least, not one which works properly). There is reason to believe such an extension would be impossible, due to the vast number of instructions that would need to be changed. Remember, it isn't just a new Screen Open command we need, everything, such as Plot, Wind Open, Cls, Colour, Rainbow, etc, would quite possibly need a new version. You'd be better of rewriting AMOS itself...  

So how about it? I mean, there's nothing in principle preventing AMOS as a language coping with AGA. Imagine AMOS Pro v3 (or perhaps AMOS Pro+?), with support for the OS, and AGA as standard, as well as support for graphics cards, AHI, data structures, etc, like in C, and a built in compiler that compiles to both 680x0 (including specific processors and FPU options) and PPC code.  

But Europress and Francois have left us long ago. According to the AMOS mailing list, Europress will only sell the source code at a ridiculously high price (a four figure number - rules it out for anything but commercial interests). There was also a rumour there that Francois would release it into the PD, which would obviously be great news, but surely there's another option?  

Ask yourselves, AMOS coders, why would you like to see such an improved AMOS? Many reasons; so you don't have to learn a new language (just various new commands, which follow a similar syntax and format to the old AMOS), so all your old programs work, because you like AMOS. Perhaps central is your belief that the AMOS language itself is excellent - easy, and possibly an example of who programming should be. It has just fallen foul of lack of development - where would Blitz be without AGA support?  

Now supposing there was a programmer, somewhere, who decided to write a new programming language. It would be loosely based on BASIC, but would of course be very modern, allowing on the programming side concepts such as data structures, unions, object orientated programming (if you want to use them, that is), and on the capabilities side, AGA, OS, RTG, AHI support, etc. But, it just so happens that it bears an uncanny resemblance to AMOS. In fact, all existing AMOS programs will work on it, without modification (or perhaps just minor changes). Of course, there are loads of new commands, but they all follow a similar format, and way of working that AMOS has always done. Am I repeating myself here? Yes, because this might as well be that AMOS v3, or whatever, I was talking about. It wouldn't be called AMOS of course, but would that matter? At the end of the day, do we @{"i"}need@{"ui"} the AMOS source code to write a new version, after all, much of it would need to be rewritten anyway for a proper updating. I wonder how far copyright extends to cover actual languages, after all, AMOS is only based on BASIC, whose to stop someone providing such a new language?  

I just hope someone will produce such a new language - I will certainly be eager to use it. But I have been reading on the AMOS mailing list of someone who is producing a new 'AMOSlike' programming language - maybe this be as I have described. I hope so. 


	----------------------------------------
 
Maybe you have noticed a parallel here? The AmigaOS, although a great operating system, has lacked development, and has fallen behind greatly in terms of the hardware it will running. And at the moment, Amiga Tech/Int. have made no efforts to port it. But suppose someone (or rather, some company!) produced a new operating system that just happened to have a high degree of source code compatibility with existing Amiga programs (of course, being PPC based, you can't have binary compatibilty), and just had this uncanny resemblance to the Amiga, but with loads of new features - and running on decent hardware. In fact, it might as well be AmigaOS 4, but of course, they couldn't call it that. They'd need a different name - how does pOS sound? 

And indeed, the same would be true of whatever Phase 5 may come up with ;)   
 
 
@endnode