Why doesn't the SCI Studio's language follow C-style notation

NaksuApina Hello all,
I've been stuffing around with SCI Studio for some time. For all of this time, i've been wondering that, while the program itself is written in C++, the scripting language doesn't follow C-style notation at all. Is there a particular reason for this?

Some people (mostly those who like functional languages, such as scheme or haskell) may be big fans of adding thousands of brackets in their code but, IMHO, it makes the SCI Script very hard to read.

If this design choice is just an 'done-fast-and-then-it-was-given' style choice, maybe it would be a good idea to redesign the language. After all, SCI is said to be 'object-oriented', so why wouldn't the language follow this scheme as well?

Of course, there needs to be compatibility mode for all scripts written in the previous notation, but before going into that, I would like to hear your opinions about this matter. Please note that this is by no means a flame to the current language - some people really like to write their code that way.
Omer Mor I think Brian tried to use language as close as possible to the one sierra used, and can be seen when dumping script code from some in-game debuggers (Qfg2 has one for example, but there are more).
This code could also be seen in the KQ4 documentation if I'm correct.
It would be possible to use the C notation, but it would not be in the spirit of the original SCI notation.
Mokalus_of_Borg The lisp-like syntax is much easier to parse than most other possibilities, which is probably why Sierra chose it, and Brian followed.
Besides that, C++ isn't the only object-oriented language around, as I'm sure you know. Despite being the de-facto industry standard, there's not much else to recommend it. Since the issue here is the usability of the language, I'll leave out my other arguments and say that you'll just have to grit your teeth and bear it. That is, unless you can convince Brian to spend most of his energy on a new compiler rather than SCI Studio VGA, or you write one yourself. :P

Mokalus of Borg

PS - Please note that I don't intend to speak on behalf of Sierra or Brian.
PPS - In which case, you may proceed to ignore this message. >_<
creichen Hi,

just for completeness' sake (although this is somewhat orthogonal to the point you're trying to make): The number of parentheses you'll use in well-written haskell code (recall that you _can_ use parentheses to arbitrarily obfuscate almost all existing programming languages) is considerably smaller than the number of parentheses you'll need for corresponding C or C++ code. Example:

C++:
[tt]
template <class N> N fact(N v)
{
if (v == 0)
return 1;
else
return n * fact(v-1);
}
[/tt]

Haskell:

[tt]
fact 0 = 1
fact n = n * (fact $ n - 1)
[/tt]

Just trying to point out that functional != "needs a lot of parentheses". Neither does "functional" mean "dynamically typed"; usually, the opposite is the case. LISP and Scheme, by benefit of having been very early mostly-functional languages, have somewhat confused matters historically. In fact, you should find that Haskell and (to a lesser extent) SML require less syntax than the C/C++ family of languages.

As pointed out, that's orthogonal to the point you're trying to make; however, as someone who is particularly fond of Haskell, I couldn't let this slip by uncorrected-- hope you'll forgive me ;-)

-- Christoph
Omer Mor Computer languages, and their history is a very interesting subject.
Sadly enough, I didn't take this course when I did my computer science degree.
NaksuApina Well,
Let me clarify my intention with this post
Writing a nice language and a compiler for it would be a nice little exercise, if there was demand for it. The big question is, would there be any interest in having a language that would be more easily picked up by newbies to this scene - or do the people who like to make their own SCI games already know the existing SCI Script-language enough, so that there is no need for yet another one.

About the C++/C-style notation, while the C++ is suitable for doing certain types of applications, I believe that it wouldn't be the key to easier adoptation of the SCI development environment. More likely, I'm thinking of something with C-style notation (as is the case with Java, perl and a tousand other languages) for programmers to feel comfortable working with it. But then, a language for a certain virtual machine should support the special features of the VM in question. This means, that f.ex. polymorphism rules should follow the facilities established by the VM.

But, again to the question:
Do you want to write your SCI games in the currently existing language or
would you like to see something else?

(And about the Haskell-point. For these languages, say Haskell and Erlang etc. the example proving the elegancy of the language seems to be examples of calculation of recursive functions. While there's nothing wrong in that, most 'real life' problems do not fit into that class; I'm not sure whether real problems could be solved elegantly using these languages - but maybe I'll learn some day.. I'm sorry for mentioning the big H in inproper context)
juncmodule Being someone who completely lacks the programming skill to put much together at all in SCI Studio...I still must say I wouldn't want the language changed. If this is close to what Sierra used then that's cool with me...I'll just wait until more resources come around and force myself to learn it. As far as, would I like it to be easier? Sure, if it was a program seperate from SCI Studio that generated SCI scripts. That would be great. As far as that being put into SCI Studio, it probably won't happen. I went through this big "let's ask Brian to make things for SCI Studio" phase and learned that most things are either not possible or would take way to much time.

later,
-junc