Programming On Pandora

[dflemstr]

Well, I see the benefits of python. Scala is at least as powerful as python, but because Python puts alot of stuff in syntax instead of libraries, it becomes easier to read (at least for those not used to the language).
Example: Here's a complete recursive quicksort-implementation ins cala for a list of ints:
CODE

def qsort(lst: List[Int]):List[Int] =
lst match {
case Nil => Nil
case pivot::tail => qsort(tail filter { _ < pivot })
::: pivot :: qsort(tail filter { _ >= pivot })
}


For those not accustomed to Scala's extremely capable pattern matching system (à la Erlang) and its very good string and list library will read that piece of code as if it were gibberish
Note that the only operators used in that piece of code are the "=>"-operator, which means "returns", and the "match"-operator, which is similar to Erlang's match. Everything else is functions.


However, Scala can be readable, too. Here's a Unit test in Scala:
CODE

class StackSpec extends Spec with ShouldMatchers {

describe("A Stack") {

it("should pop values in last-in-first-out order") {
val stack = new Stack[Int]
stack.push(1)
stack.push(2)
stack.pop() should equal (2)
stack.pop() should equal (1)
}

it("should be empty when created") {
val stack = new Stack[Int]
stack should be ('empty)
}
}
}

 

[bzar]

Nice! I've never really taken time to get to know scala, but it seems that I should . Does the "1st match ... case Nil => Nil" mean that the part described in the other case will only be done for the first match (otherwise will return Nil)? That was my first guess

 

[dflemstr]

This is some serious Scala-code that I presented to you. Kinda like the more hackish C-code that you can find on the internet sometimes. But, I am bored so I will try to explain it.

First of all, the default "List"-type in Scala is immutable, so nothing here modifies a list. Only new Lists are created all the time.
Then; somehting like "lst filter whatever" is exactly the same as "lst.filter(whatever)" in Scala. Same for all methods in this code; "pivot :: qsort(...)" is the same as "pivot.:: (qsort(...))". Yes, methods can have names like "::" in Scala.

Ok, we have a function "qsort" that takes a "list of ints" and returns a "list of ints". It only has 1 statement, so no {}'s.

"lst match {}" does a match operation on the lst variable. This is kinda advanced for those not familiar with Erlang's match, since it is an operation only common in functional languages.

If the variable matches the empty list "Nil" (may be familiar to all you Schemers out there)(you could also write "List()"), then the match-statement returns Nil, too (you almost never write the "return" statement in Scala, the last return value in the function is returned).

Else, if lst consists of at least one element (it matches a "head" followed by a "tail"; note that the tail can be Nil too, read further down for info on what "::" means), then put the first element in the variable "pivot" and the rest of the list in the variable "tail". Then, return the following:

1. First, make a list of all the elements of "tail" that have a value smaller than the pivot, and call the qsort-function recursively with that list. Keep the result.
2. Then, make a list of all the elements of "tail" that have a value equal or greater than the pivot, and call the qsort-function recursively. Keep the result.
3. Finally, put the result from 1., the "pivot" and the result from 2. together and return that resulting list. The "::"-method puts something in front of a list
(here, the pivot is put in front of the list in 2.; note that we used this in the match, too; this method "works both ways" in the way that it can match a list head)),
and the ":::"-method puts two lists together.

The "sorting" that is required for the recursive call to qsort is achieved by calling the method "filter" of the "tail"-list. The "filter"-method takes a function for its argument and creates a new list of all the elements it has that make the passed function return false (aka: each of the elements of lst are in turn sent to the function, and those that return false are discarded). Here, the first time, we give the filter method the function "_ < pivot", which is an anonymous function that returns true whenever its argument is less than pivot. The second time, we give it the function "_ >= pivot", which returns true whenever the value passed is larger or equal than pivot.


*Phew* this is some heavy code; I hope I clarified a few things

EDIT:
tl;dr:
The code does this in pseudocode:
define a function qsort that takes a list of ints and returns a list of ints:
- if the list is empty, return an empty list.
- if the list contains one or more elements:
-- put the first element of the list in the "pivot" variable
-- put the rest of the list in the "tail" variable
-- return all members of "tail" that are smaller than "pivot", sorted by qsort; followed by pivot itself; followed by a list of all the members of "tail" that are larger than or equal to "pivot", sorted by qsort.

 

[sindbad]

1. Compare that to compiled languages, where EVERYTHING you do gets accelerated. And having C modules in Python-code makes it unportable (which is why I prefer JVM-based languages, as they are kinda-portable and still compiled).
But I never said that everything about python was bad, I just mentioned some general problems with scripting languages in general.

2. Why does a language have to have alot of syntax around something just because it's part of the core? (And I don't say that C is well-structured when it comes to syntax; I don't particularily like the language at all)

3. Compare that to Python, where there are lists and maps and hybrids between them, such as slices, etc, that everything builds on. Many of these types are atomic in Python (even if they can be split up, they can still only be handled as an unit, you can't implement your own fully working List class, which makes the core have to handle the List implementation etc).
Then we can cover syntax uniformness. What is the []-Operator? When does it apply to what, and what does it do? What is the value of what it contains (for example "2:3")? Can you make your own classes with this operator?

And [4.] method signatures, and [5.] static typing... I won't even go there.
I feel you have a bad opinion of python because you've never used it.

1. Your small C (or cython) module would be portable, you would just have to distribute binaries for each OS. It's not a problem at all, as you always only need a few functions to be faster. Look at Pyglet and what can be done with pure python by using native libraries whenever possible and small, easy to distribute binaries otherwise.
JVM languages aren't compiled either, at least no more than python bytecode. One could argue that you should love Jython.

2. Because that syntax is very useful for very common patterns.

3. All types are atomic from the programmer's p.o.v. and they are all objects. The [], [:] and whatever else syntax is always just syntactic sugar in Python. For example, the [ ] operator is a call to the __getitem__ method with the thing in the brackets as a parameter. Same for [2:3], or pretty much anything else.You can easily inherit basic types or you can even change them globally if you want to.
Python actually has a very minimalist syntax and it's usually getting smaller with every version (for example in 3.0, print is a function and % turns into the .format method on strings).

4. Look at decorators

5. That's a completely different debate. I think it's much easier to write correct code in a dynamic language because it's simply easier to write (and read) and also much easier to debug/test.
I'll paraphrase Steve Yegge: "When you show Java people Python or Ruby or JavaScript they'll tell you <but it's not statically typed, it's not safe!>. But then, the Scala people point at the Java people <your type system sucks! Ours is much more strict and precise!>. And the Java people start defending themselves, <but you don't really need that precise a type system, you'll do unit testing anyway and catch errors, ...>".

Also, although python has several idiomatic functional features (functions as first class citizens, list comprehensions, etc), scala is much more functional. That's yet another completely different debate

 

[lulzfish]

Python bothers me because you don't declare variables explicitly, and I'm really bad at remembering my variable names. I like to have them all listed in one place.

 

[Exophase]

Lots of functional languages have a similar kind of pattern matching: if this kind of thing interests you then you might want to check out languages like SML, OCaml (especially if you like OOP thrown in), Haskell, Dylan, etc. Also, LISPs have really cool macros that have very powerful pattern matching too.

The pair type (or cons if you want to go legacy) dflemstr demonstrated is also very typical of functional languages and goes well in hand with recursive algorithms. In languages with a basic pair type lists are usually implemented as recursive pairs (with the innermost element being paired with '(), or Nil as it's called here)

 

[dflemstr]

@ sindbad

I feel you have a bad opinion of python because you've never used it.


I use Trac (the very good bug tracking system) for all my projects and love it. I use Blender and have made alot of own plugins for it. I'm not fluent in Python but I know my way around

1. Yesyes, I think it's wonderful that Python is portable. Was just sayin' that to highlight the fact, that if you mix C in, you get all of C's pros AND cons.

2. Yes, but still; why not put it in Libraries? Look at the Unit test example I gave in scala; there's no new syntax there at all.

3. Oh, ok. Then this is done similar to the way it's done in Scala. Nice.

4. Well, those don't do type-checking.

5. Yes, Java's system sucks. Scala tries to improve it (and does so quite well; only limit so far is that you can't match type parameters). But dynamic type-systems are still unsafe in many ways, there's no denying that. Let's leave that discussion for some other time, ok?

Also, although python has several idiomatic functional features (functions as first class citizens, list comprehensions, etc), scala is much more functional. That's yet another completely different debate

Scala is a hybrid; it's the most object-oriented language I've seen to date (mutiple inheritance done right, "interface"-like structures that support mix-ins etc). And, it's functional in the sense that every object/class is a function, too. It's a very interesting language

@Exophase yes indeed; scala steals ideas from everywhere, it seems
The author himself says that he took alot of features from those languages. The fact that you don't have to extend the syntax to do such things makes it especially easy to add such features.
Scala implements these functional paradigms by abusing linked lists, where the last link node is null.
Of course, Scala still has mutable lists and things like that. As I said, a very interesting language.

 

[Pleng]

As with all quality Amiga developments the ETA is "When It's Done"™.

but will it be better than OSX? :lol:

QUOTE


There aren't many Amos source codes available. That's the sad part of it.



That is sad. Maybe it might be worth launching an appeal on AW for people who may have programmed AMOS games in the past. It would surely help with testing MBasic.

Getting hold of the source to the Reality game creators could be a bit of a Coup. I'm almost certain they were written in AMOS. Have no idea who published them though.

 

[samuraicrow]

@Exophase yes indeed; scala steals ideas from everywhere, it seems
The author himself says that he took alot of features from those languages. The fact that you don't have to extend the syntax to do such things makes it especially easy to add such features.
Scala implements these functional paradigms by abusing linked lists, where the last link node is null.
Of course, Scala still has mutable lists and things like that. As I said, a very interesting language.

Scala even stole its name from Scala!

As with all quality Amiga developments the ETA is "When It's Done"™.

but will it be better than OSX? :lol:

QUOTE


There aren't many Amos source codes available. That's the sad part of it.



That is sad. Maybe it might be worth launching an appeal on AW for people who may have programmed AMOS games in the past. It would surely help with testing MBasic.

Getting hold of the source to the Reality game creators could be a bit of a Coup. I'm almost certain they were written in AMOS. Have no idea who published them though.


It shouldn't need to be better than OSX since it will probably support OSX long before it adds support for AmigaOS 5.

If you know anybody that has Amos sources that they would like to see ported to the mainstream operating systems, have them make a note on http://amos.pspuae.com/ aka the Amos Factory website.

 

[Pleng]

It shouldn't need to be better than OSX since it will probably support OSX long before it adds support for AmigaOS 5.

lol

QUOTE


If you know anybody that has Amos sources that they would like to see ported to the mainstream operating systems, have them make a note on http://amos.pspuae.com/ aka the Amos Factory website.




I don't know anybody but I might go on a hunt after I get back from holiday...

 

[yaKC]

As with all quality Amiga developments the ETA is "When It's Done"™.

but will it be better than OSX? :lol:

QUOTE


There aren't many Amos source codes available. That's the sad part of it.



That is sad. Maybe it might be worth launching an appeal on AW for people who may have programmed AMOS games in the past. It would surely help with testing MBasic.

Getting hold of the source to the Reality game creators could be a bit of a Coup. I'm almost certain they were written in AMOS. Have no idea who published them though.


I`ve got the sources for Reality and the extras disks, helped Brian "Mr AMOS" Bell finish the package off back in `96. Still in occasional contact with Brian if you`d like me to check his thoughts or point him to this thread he's busy doing Multimedia projects now (or was not so long ago)

The package used Skeleton disks for providing different genres, I did the "8 way scrolling platform" game and "Ultra Space Invaders" mini ones, still have the source for those too, was supposed to get them dumped by someone last year, but drifted away from the scene again


here's clips of a couple of games done with the scrolling Skeleton
Egor's Quest:-
http://www.youtube.com/watch?v=YeZjDJ00tfo
http://www.youtube.com/watch?v=uOyNSQA1Ank

Egor in Toyland:-
http://www.youtube.com/watch?v=4YpN09MIA3E
http://www.youtube.com/watch?v=sW86-Sv9MHM

anyway, I don't think any extensions were used by Reality itself, or any of the Skeleton disks that were finished, so may be a good set of games to try with MBasic.

 

[valhalla]

While I do like books, I can download and read web content on the Pandora and not having to carry a big book around. I also want to get started on game programming and SDL. Coding a puzzle game would be a nice way to learn C++. Money is also a short supply at the moment.

portability of the (reference) documentation is one of the reason I love python for programming on the go: accessing the docutils documentation via the help() of ipython is a great timesaver, and I can also try small snippets in the same environment.

C isn't hard! if you already code in any other language, you can get into C coding in a matter of a couple of days, and then you are good to go and make your games

this is quite true: C is way too hard as a first programming language, but once you know the basics of programming in another procedural language there are no big obstacles to learn it.

(on the small syntax issue)
Well, ok, this is maybe only my preference, but I like it if a language's core is as small as possible and handles as little as possible.

sorry, I understood that you were saying that python didn't even have a basic syntax, i.e. had bad aggregation of hacks, now I understod you meant that python has a "big" syntax as opposed to the "smaller" one of C.

Then what I said doesn't make sense

1. Yesyes, I think it's wonderful that Python is portable. Was just sayin' that to highlight the fact, that if you mix C in, you get all of C's pros AND cons.

but you have still saved lots of time writing the parts that don't need optimization, since python is one of the faster languages for writing code

2. Yes, but still; why not put it in Libraries? Look at the Unit test example I gave in scala; there's no new syntax there at all.

because if you take it too far you enter the java hell where to do something very simple you have to fill an 80 character line with an extremely elegant series of method calls with ClearlyDescriptiveOverlongCamelCaseNamedMethods

 

[Pleng]

I`ve got the sources for Reality and the extras disks, helped Brian "Mr AMOS" Bell finish the package off back in `96. Still in occasional contact with Brian if you`d like me to check his thoughts or point him to this thread he's busy doing Multimedia projects now (or was not so long ago)

That would be excellent.

I remember 'going halves' on buying Reality after playing the dizzy-style demo on the front of (I think) Amiga Format.

I'd love to have a look at the Source and maybe one day write a new interface to it. I thought Reality was a really good idea, and implemented quite well but the interface was a bit, well, wordy! If I remember correctly it basically had all the logical programming listed out and you just filled in the bits where you wanted actions to happen?

Because my programming knowledge was limited, I had no real ideas about planning a game, and I was shit at graphics. I never really got very far with it, but I could certainly see me doing something with it these days, especially with all the resources now available on the internet.

It's a shame it came around so late in the life (or early in the death) of the Amiga. If it had been around a few years earlier I could have seen it being a roaring success.

QUOTE


The package used Skeleton disks for providing different genres, I did the "8 way scrolling platform" game and "Ultra Space Invaders" mini ones, still have the source for those too, was supposed to get them dumped by someone last year, but drifted away from the scene again


here's clips of a couple of games done with the scrolling Skeleton
Egor's Quest:-

anyway, I don't think any extensions were used by Reality itself, or any of the Skeleton disks that were finished, so may be a good set of games to try with MBasic.



That looks pretty cool. If you can get some ADFs of those games I'd love to give them a play. The only real issue with Reality was that as it was written in AMOS it had the typical tell-tale 'AMOS scrolling'. Hopefully with MBasic scrolling will become a lot smoother.

 

[yaKC]

I`ve got the sources for Reality and the extras disks, helped Brian "Mr AMOS" Bell finish the package off back in `96. Still in occasional contact with Brian if you`d like me to check his thoughts or point him to this thread ) he's busy doing Multimedia projects now (or was not so long ago)

That would be excellent.

I remember 'going halves' on buying Reality after playing the dizzy-style demo on the front of (I think) Amiga Format.

I`d love to have a look at the Source and maybe one day write a new interface to it. I thought Reality was a really good idea, and implemented quite well but the interface was a bit, well, wordy! If I remember correctly it basically had all the logical programming listed out and you just filled in the bits where you wanted actions to happen?

Because my programming knowledge was limited, I had no real ideas about planning a game, and I was shit at graphics. I never really got very far with it, but I could certainly see me doing something with it these days, especially with all the resources now available on the internet.

It's a shame it came around so late in the life (or early in the death) of the Amiga. If it had been around a few years earlier I could have seen it being a roaring success.

QUOTE


The package used Skeleton disks for providing different genres, I did the "8 way scrolling platform" game and "Ultra Space Invaders" mini one, still have the source for those too, was supposed to get them dumped by someone last year, but drifted away from the scene again


here`s clips of a couple of games done with the scrolling Skeleton
Egor`s Quest:-

anyway, I don't think any extensions were used by Reality itself, or any of the Skeleton disks that were finished, so may be a good set of games to try with MBasic.



That looks pretty cool. If you can get some ADFs of those games I`d love to give them a play. The only real issue with Reality was that as it was written in AMOS it had the typical tell-tale 'AMOS scrolling'. Hopefully with MBasic scrolling will become a lot smoother.


I`m not surprised you went halfs on buying it, at 30 quid it was expensive. I thought the interface was quite good for the day, although I get what you mean with the big list of variables, but no other way to do it I'd be interested in seeing if Brian would be up for doing a game creator along the same lines for Pandora, I know I would be, I`ll send him a message and hopefully he will pop in or give me permission to hand the source code over to you

As far as the games above, I still need to get them ripped, I want to play them myself on Pandora The Egor games didn't suffer from "AMOS Scrolling" as you put it, hehe, they ran at 50 fps (or 60fps on NTSC), AFAIK the first and only ever to do so in AMOS on a A500 (and no extensions), so it couldn't get smoother But yeah, by `96 the Amiga market was duying in UK, so Reality never became what it could have.

anyway, rambling (or is it bragging ) This Mathias Basic sounds really cool, pleased it's been brought up here

 

[Pleng]

I thought the interface was quite good for the day, although I get what you mean with the big list of variables, but no other way to do it I'd be interested in seeing if Brian would be up for doing a game creator along the same lines for Pandora, I know I would be, I`ll send him a message and hopefully he will pop in or give me permission to hand the source code over to you

That would be good, but best get the source to Samurai_Crow. He's the one heading up the MBasic project.

I think the problem with game creators at the time was the trend to have a 'no programming knowledge required'. Just looking at any game made in tke 'klick 'n' play' series showed how much more complicated the 'no programming required' systems were than one that would be built on a smile scripting system.

Personally my view of a rapid games development system should take care of the mapping, spriting, sound and all the other bits that are no fun to code, then let the user select the events and write small scripts to handle the events.

QUOTE

As far as the games above, I still need to get them ripped, I want to play them myself on Pandora The Egor games didn't suffer from "AMOS Scrolling" as you put it, hehe, they ran at 50 fps (or 60fps on NTSC), AFAIK the first and only ever to do so in AMOS on a A500 (and no extensions), so it couldn't get smoother But yeah, by `96 the Amiga market was duying in UK, so Reality never became what it could have.

anyway, rambling (or is it bragging ) This Mathias Basic sounds really cool, pleased it's been brought up here



OK Must have been the Youtube video that gave that impression!

What skeleton disks were available for Reality? I remember the dizzy-style one which came with the main package, and I think there was a shoot-em-up and... I don't remember what the other one was. I do recall seeing pictures of a racing game and maybe a beat-em-up?

 

[samuraicrow]

I thought the interface was quite good for the day, although I get what you mean with the big list of variables, but no other way to do it I'd be interested in seeing if Brian would be up for doing a game creator along the same lines for Pandora, I know I would be, I`ll send him a message and hopefully he will pop in or give me permission to hand the source code over to you

That would be good, but best get the source to Samurai_Crow. He's the one heading up the MBasic project.

I think the problem with game creators at the time was the trend to have a 'no programming knowledge required'. Just looking at any game made in tke 'klick 'n' play' series showed how much more complicated the 'no programming required' systems were than one that would be built on a smile scripting system.

Personally my view of a rapid games development system should take care of the mapping, spriting, sound and all the other bits that are no fun to code, then let the user select the events and write small scripts to handle the events.

QUOTE

As far as the games above, I still need to get them ripped, I want to play them myself on Pandora The Egor games didn't suffer from "AMOS Scrolling" as you put it, hehe, they ran at 50 fps (or 60fps on NTSC), AFAIK the first and only ever to do so in AMOS on a A500 (and no extensions), so it couldn't get smoother But yeah, by `96 the Amiga market was duying in UK, so Reality never became what it could have.

anyway, rambling (or is it bragging ) This Mathias Basic sounds really cool, pleased it's been brought up here



OK Must have been the Youtube video that gave that impression!

What skeleton disks were available for Reality? I remember the dizzy-style one which came with the main package, and I think there was a shoot-em-up and... I don't remember what the other one was. I do recall seeing pictures of a racing game and maybe a beat-em-up?


Actually I'm second in command at the Mattathias project but thanks for the mention! If you want to get updates from our mailing list (low traffic) you might want to get onto http://tech.groups.yahoo.com/group/mattathias/ and join up. Also we do Amos-related stuff at http://amos.pspuae.com/ as we are both moderators there. If you have trouble logging in at the Amos Factory website, just let me know.