Quote:Original post by theOcelot
I don't understand how @ is used, especially in the for loops. Could you explain that more?

In Circa, the @ symbol means in general that "this name is rebound to the result of this expression". In a for loop, it means that the list can be "modified" by the code inside the loop (although the list isn't really modified; instead it makes a new list and rebinds the name to that result). Example code:

list = [1, 2, 3]for i in @list  i += 1endprint('list = ', list)// prints: list = [2, 3, 4]

It's kind of like the map() function in Lisp/Ruby/Python/etc, but with ordinary for-loop syntax instead of passing a function or lambda.

The motivation is that I'm trying to minimize side effects; code shouldn't modify values in-place, instead it should return new values (and possibly rebind existing names to the new values). So the different usages of the @ symbol are all about making it easier to write code under those restrictions.

Quote:Original post by theOcelot
That should be optional, at least. It might be convenient in simple cases, but I think I'd prefer just having an easy API for loop timing and control and handling it myself. Eventually, a user is going to want more control over their main loop.

Yeah that is true, this will probably be supported later on.

Quote:Original post by Decrius
Or, allow both? Many people have their preferences, just allow whatever is possible and more people will like it. Must admit ' instead of " ain't a bad idea.

One nice thing about allowing both is that you don't need to put slashes in front of quote marks as often.

str1 = 'This "string" has unescaped double quotes in it'str2 = "This string has unescaped 'single quotes' in it"

Quote:Original post by Makaan
Comments sould not be started with `--`(instead use the classic // and /*) because you might want to use that as an operator: int a = 10; a--;

Heh, a few people have pointed this out. The other side is that I wanted to use // to mean something else. In Python 3, // means integral division and / means floating-point division (it's not based on whether the arguments are ints or floats). I was thinking of copying them. I guess that leaves # for the comment syntax.

Quote:Original post by Windryder
First and foremost, I demand strong typing for making real games in a language. Python and Ruby are excellent for small, simple games, but the type system makes them much more prone to critical (runtime!) errors.

I object: Python and Ruby are strongly typed. You are confusing "strong vs. weak" with "dynamic vs. static".

Quote:Another thing to consider is OO and encapsulation. While both Ruby and Python are OO languages in a sense, they lack many features that I consider critical.

Ah, yes, well. :)

Quote:For example, Python's encapsulation is... Well, there really isn't any to speak of. Ruby allows for new methods and data to be added to a class from anywhere,

Python allows this too. The only real difference is that the Python community sort-of-officially discourages it, whereas Ruby has standard frameworks that use it to do wonderous things.

Quote:rendering the encapsulation that actually exists useless against a determined "attack".

Repeat after me: Encapsulation is not in any way, shape or form a security measure. It cannot protect your code from malicious attack, in any language, because it's only relevant to developers. If you can't trust the people on your own team, you have bigger problems than your choice of language. It is there to prevent people on your team from getting the wrong impression about what's part of the interface to a module or not. But you have documentation for that, right?

Quote:Furthermore, both of these languages are "duck typed"

You're restating yourself, but more accurately this time.

Quote:This discourages the use of inheritance for flexibility

As it should; composition is usually what you want instead.

But more importantly, it enables you to program to an interface and not worry about boilerplate. If Foo and Bar are conceptually Spammable, but get spammed() in completely different ways, is it useful or necessary to have a base Spammable definition (which might not provide any useful shared code) - or even to name the concept?

Quote:and instead encourages its use as a means of code reuse.

Not really. In my experience, "code reuse" is a red herring anyway; the real goal is code use - i.e. actually calling the functionality you already have rather than rewriting it. There are a zillion ways to do this. Inheritance is rarely the right way, but it's one of the few things it's actually good for. Especially when you have higher-order functions and can therefore customize behaviour with all kinds of neat template-and-hook patterns.

For what it's worth, about the only time I ever (manually) use inheritance in Python at all is when an API tells me it expects me to.

The short version of all that: you don't have to like it, but there are real reasons why others do.

Quote:As for the actual syntax, I agree with Krohm on the use of the '--' operator as comment symbol.

The overall impression of a language's syntax is important, yes. But details like this are getting into bikeshed-colour-choice territory.