Why is the homebrew scene on the Amiga not as impressive...

[Mrs Beanbag]

Originally Posted by Samurai_Crow

I've used AmosPro, C++ and Assembly. My biggest complaint about AmosPro is that you have to write in Assembly to be able to write an extension for the language. It's not OOP but rather, it's a separate programming paradigm called extensible programming.

in fact you might not have to write in Assembly... i've never seen it done, but it's certainly possible to embed machine code in an AMOS procedure. The compiler does this when you produce a compiled AMOS program (as opposed to an executable). I don't know how it is actually implemented but if i could find out all sorts of options might be possible. Although it would be a lot more useful if you could include one AMOS program from another (without having to actually copy and paste the entire thing). Complete lack of code-sharing is one of AMOS's drawbacks.

Also it would be nice if the syntax for procedure calls were the same as for built-in/extension functions. There are a lot of odd design decisions like that in it.

btw AMOS isn't an "Extensible Programming Language". It has an extensible interpreter, but that's not the same thing. You can't extend the language from within the language itself, and the things you can do in an extension are quite limited. The best thing AMOS could possibly get is a way to extend it by providing more data types. You only get integers, strings and floats. Composite data types are really a basic essential in modern programming.

I've thought about ways to rewrite AMOS to address these issues while maintaining compatibility of Ascii-exported programs. Having such a monolithic programming environment has its drawbacks. The other thing i encountered recently is the problem that there are only 26 slots for extensions, but there are a lot more than 26 different extensions out there. Something more like a Python module would be much better, so at the start of the program you could IMPORT the extensions that you used.

Originally Posted by Samurai_Crow

OOP has been done to death and is fairly usable but being able to add commands to the language itself is just as useful as using a cryptic bunch of punctuation mark tokens in C++ designed to limit the number of keystrokes necessary to create common pieces of code.

It keeps being done because it is very useful, but i really don't know what you mean by cryptic punctuation marks. There's nothing particularly cryptic about using a dot to access object members, and "limiting keystrokes" barely scratches the surface of why code re-use is a Good Thing. Who in the Amiga community hasn't complained about code bloat on Windows?

It doesn't just save typing. It makes it easier to read, understand and maintain, and structure makes it easier to reason about. If you want something so simple as a bunch of sprites wandering around, each one has an X co-ordinate and a Y co-ordinate and an image number, and you'd really prefer to store those in three separate arrays? Because that's what we've got to do without any composite data types. The type system also guards against programmer mistakes.

Also you can add commands to pretty much any language, especially C++, it's called a library. Pretty much none of the high-level functionality of C++ is built in. You can't add control structures, but then you can't do that with an AMOS extension, either.

Originally Posted by Samurai_Crow

Using intelligent alternate-text for icons could make a graphical source code more readable to a blind person or somebody who doesn't use English as their mother-tongue.

"Alternate-text" sums up the problem right there, treating blind people as second-class users. They have to use the back entrance.

[copse]

Originally Posted by Mrs Beanbag

"Alternate-text" sums up the problem right there, treating blind people as second-class users. They have to use the back entrance.

If it were easy to solve, we'd have done it. No-one reasonable wants to exclude the disabled. So we compromise without reducing everyone's experience to the lowest common denominator.

Look at games that are designed for the console and the PC. They get limited to what the console players can handle, and what the console platform allows, and the PC users get a sub-par experience.

The way to ameliorate these sorts of problems is time and money. But who has it in sufficient quantities?

[copse]

Originally Posted by Samurai_Crow

I've used AmosPro, C++ and Assembly. My biggest complaint about AmosPro is that you have to write in Assembly to be able to write an extension for the language. It's not OOP but rather, it's a separate programming paradigm called extensible programming.

I see you've posted over at ultimateamiga forums, on further AmosPro related development efforts. Is there an open source repository where everyone can help out?

[Thorham]

Originally Posted by Samurai_Crow

Personally, I think any text based language teaches bad habits.

Like what?

Originally Posted by Samurai_Crow

I want to write a graphic language based on icons like AmigaVision and its flow editor.

That sounds horrible

Originally Posted by appiah4

I never got the hate for BASIC. It works. And it's easy to teach and learn.

Once you get used to assembly language, C, and some newer stuff like C#, Lua and others, and you come back to things like Amos, you're not going to like it anymore.

In fact, when I came to the Amiga from the C64, I started with BASIC (AMOS), and within months moved on to assembly language because it's just so much more powerful and faster.

[Mrs Beanbag]

Originally Posted by Thorham

Once you get used to assembly language, C, and some newer stuff like C#, Lua and others, and you come back to things like Amos, you're not going to like it anymore.

My experience exactly. AMOS, to its credit, provides a really convenient environment for tinkering about in, and that's what makes it easy. The actual language itself is not that great. It suffers from a complete lack of abstraction. It doesn't teach you programming. It teaches you AMOS Programming. It teaches Bad Programming. Sure, it works. But you try that line with your boss if you work for a real company. If anything i think it makes it harder to learn other languages, once you've got used to AMOS, you look at C++ and see all the curly braces and asterisks and whatnot and your eyes start to glaze over. You'd be better just learning C++ in the first place, it's really not that difficult. But you don't get screens and bobs and sprites and tracker mods out of the box.

In fact, when I came to the Amiga from the C64, I started with BASIC (AMOS), and within months moved on to assembly language because it's just so much more powerful and faster.

It's not the speed that did it for me, sure it's not the fastest, but i found that when you do really start to master it, you find yourself fighting against the language itself. When recently i thought about rewriting my map editor, i thought maybe i'd just do it in AMOS again, but i wanted to be able to load in an arbitrary number of maps simultaneously, so i thought, well just put them in a linked list.

Umm. Err. Ah.

Maybe i could use banks and have lists of bank numbers stored in strings or something. But... yeah...

So i'll probably do it in Asm instead, but that means creating an entire environment for it.

[Thorham]

Originally Posted by Mrs Beanbag

So i'll probably do it in Asm instead, but that means creating an entire environment for it.

Do it in C. Writing your main software in ASM is fine, but C is great for utilities such as this. Simply use SASC 6.58 and write it to be OS friendly. It doesn't produce the best code possible, but it's easy, compiles reasonably fast and it's proper C89. Saves lots of time, and you don't have to wrestle with Amos' deficiencies.

[zerohour1974]

To be honest if we need to find out how to expand AMOS speak to Francois Lionet of Clickteam after all he created it.

[Dunny]

Originally Posted by Mrs Beanbag

BASIC is terrible!

Sure it gets you started, but it also encourages a lot of bad habits.

You. Me. Outside. Now.

[Samurai_Crow]

Originally Posted by copse

I see you've posted over at ultimateamiga forums, on further AmosPro related development efforts. Is there an open source repository where everyone can help out?

Most open source repos don't allow you to use a custom license as AmosPro has. (Non-OSI approved licenses are frowned upon.)

On UltimateAmiga, I am a moderator. If you wish to join the team just run it by the team members. There's a hidden forum for AmosPro 3 related documents.

Speaking of AmosPro 3, more powerful data structures are definitely in order and being planned.

[JudasEZT]

Theres gonna be a Amos Pro 3 ?

That woulve be cool.. as I think is a wonderful tools pack for programming.. and really really fun.

[Samurai_Crow]

AmosPro 2.1 will come first with bug fixes so find all the bugs you can. Then come the features.

[Mrs Beanbag]

i think i know of a few bugs but don't remember if they were AMOS 1.3 or AMOS Pro, will have to try. One was that when using Gr Writing to draw in XOR mode to do "rubber banding", the Box command used to leave pixels from the corners all over the screen, unpredictably.

I could "fix" the music extension to play tracker modules properly since i already wrote my own extension for that

tbh i think AMOS 3.0 should be a complete rewrite, i know it's a big project but there's too much legacy.

also do you know if there is a way to load a different 8x8 font? It came with an 8x8 font editor, but there doesn't seem to be any way to use a different one.

[copse]

Originally Posted by Samurai_Crow

Most open source repos don't allow you to use a custom license as AmosPro has. (Non-OSI approved licenses are frowned upon.)

On UltimateAmiga, I am a moderator. If you wish to join the team just run it by the team members. There's a hidden forum for AmosPro 3 related documents.

Well, they're the guys doing the work, if they want to do it that way, it's up to them.

These days, having a public git repository, and the ability to submit pull requests and an integrated issue tracker, make development so much easier. And helps attract new developers. It's a pity that's been decided against, I think I saw some complicated system of tracking changes based on Excel spreadsheets.

That said the last repo that had OSI licensing restrictions was Google Code, these days github or bitbucket and most others don't care what license you use and let you have private repos and public repos and the way they make money is from commercial efforts who need support.

From what I read there compiling amos pro is pretty simple, just get devpac2 and change a few options, and you can get it to compile byte for byte identical.

[JudasEZT]

Originally Posted by Samurai_Crow

AmosPro 2.1 will come first with bug fixes so find all the bugs you can. Then come the features.

Cool! I will look into ultimateamiga forum to look if I know more bugs.
The most annoying fault of AmosPro is next:
- In DualPlayfield mode, Screen Offset command steps 16 pixels when moving horizontally.

That prevented me of doing a RastanSaga clone =(

[Samurai_Crow]

The music extension and dual playfield bugs are already fixed, the latter of which is in the latest beta already as well as some documentation bugs.

After checking the forum for hidden ones, I found that many hidden ones are empty and waiting for use.

[JudasEZT]

Originally Posted by Samurai_Crow

The music extension and dual playfield bugs are already fixed, the latter of which is in the latest beta already as well as some documentation bugs.

After checking the forum for hidden ones, I found that many hidden ones are empty and waiting for use.

Those are great news!

[Samurai_Crow]

@Mrs Beanbag

If you want less legacy, try Hollywood 6.0. It has so little legacy that it currently doesn't support the Amiga chipsets at all!

A friend and I tried to make a new compiler as a sequel for Amos codenamed "Mattathias" that would support custom operators and be able to build extensions for itself. It would be basically a self compiled Ruby substitute. The two of us could not finish it even though we tried for 8 years. Thankfully we now have access to the AmosPro source code so we don't have to try that again!

[Mrs Beanbag]

ok, well, once bitten...

AMOS really is an impressive feat for one man, i must admit, hats off to Francois for such a comprehensive product. Rather too comprehensive, i might add. So many features i never found a use for in all my years of using it.

i do intend to write my own language at some point, and i intend to make a library for it to assist migration of projects from AMOS. if any of that ever happens, you are of course welcome to that source code, too. but i'm still umming and ahhing over the syntax. for about 8 years.

[Lonewolf10]

Originally Posted by Mrs Beanbag

also do you know if there is a way to load a different 8x8 font? It came with an 8x8 font editor, but there doesn't seem to be any way to use a different one.

For use in the editor or in program? I think the default font is stored in the APSystem directory in an .abk file or something like that... though I rarely change fonts. In recent AMOS projects (my own tools, previously mentioned in this thread) I just used a 3x5 font, with Plot used to draw it onscreen!

[Mrs Beanbag]

Originally Posted by Lonewolf10

For use in the editor or in program? I think the default font is stored in the APSystem directory in an .abk file or something like that... though I rarely change fonts. In recent AMOS projects (my own tools, previously mentioned in this thread) I just used a 3x5 font, with Plot used to draw it onscreen!

In the program... the one used by the "Print" command.

Using plot would surely be very slow!

If i were to do it manually i would store it in a screen and use Screen Copy to copy each character. But i fee like i'd be re-inventing the wheel here.

I did find the default 8x8 font, i could of course just edit that but then it would be used by ALL my projects, it's not very convenient if i have to rename files every time i want to run or compile a different program.