Hello, I just discovered the fan langage and I'm interested in it. It seems simple and concise, qualities I value.

I've seen that you use the := affection operator, like in the Pascal langage. I understand that choice, = being since chilhood associated with equility.

But I wonder, why choosing the &&, || and ! C-like operators instead of the and, or and not ones which are clearer and closer to the natural langage ?

I was not able to find a topic on it using the search feature.

Actually, = is also used for assignment in Fan. The := operator is only used for initial variable definition. For example:

n := 1
n = 2
if (n == 2) {
  echo("Definitely 2")
}

So, not really like Pascal, though the similarity could be misleading, as you point out. I think the point is to avoid extra typing, as in:

var n = 1
n = 2

Some languages, like Ruby and Python, don't require declaration before use. They just assume you want a local var if there's assignment to a var in a methods, but that gets ambiguous sometimes. I get the impression that Brian and Andy wanted the same feel as Ruby/Python but without the ambiguity.

Not that I've asked about it to be sure.

Anyway, I think the model works well, but some cases (like method parameters) take some getting used to for me. Still, I think it's a good choice.

Fan is essentially a C family language, so &&, || and ! make sense. That said, I think that not is potentially a lot more readable than ! - and I think I'd like Fan to support it.

if (!str.indexof("abba")) { ...}

if (not str.indexof("abba")) { ...}

Fan is a child of Java and C#, as such I try not to change anything that isn't broken (including the ! operator).

As Tom said the := operator isn't assignment, it is declaration and = is used for assignment.

You can read the original history here from back in 2005.

Interestingly enough James Gosling had that same idea.

Hello again, thank for your answers.

Sorry for my mistake about :=.

I'm a bit nostalgic of the intuitiveness of Pascal (you almost write pseudo-code) and I often use and, etc ... in SQL, or JSP's EL. I've already found myself writing such a condition in Java code.

I wish I had a langage with this keywords but still the curly braces (not BEGIN ... END) to delimitate blocs.

In plain old C, I could have wrote :

#define and && #define or || #define not !

but there is no mechanism allowing me to do this in Java.

Until now, no potentially mainstream language has given up the old C operators. Language designers may all be C secret lovers :-) (but aren't we all C lovers ?)

I do love C, actually, but not necessarily for the syntax. It's just that it's the lingua franca. And I agree with following the syntax where meaningful.

Still, I do find it interesting that Guido van Rossum is Dutch but chose to use the English boolean words in Python anyway. I guess English is the other Frankish Language these days.

Hi Raphael,

How would you feel if you end up reading code where the programmer decided they would redefine && to be "und" and || "oder"? Doesn't seem such a good idea any more, does it? :-)

This is a simple illustration of the potential downsides of preprocessors. They have a few benefits, but in my experience, they are not worth the pain that they can cause down the line, which is why they are not supported by default in Java (and Fan).

-- Cedric

Hi,

you can also redefine if to si, else to sinon, return to retourner etc ... English is the default language for the keywords and all programmers undertand it (at least they understand and and or ...), so I still think it's a good idea.

I don't think I would be a good idea to have a preprocessor in java.

Preprocessors are like fancy text splicers: copy & paste. As a result, any language that uses them is bound to have inferior tool support.

A single change to a header file in C/C++ necessitates a reparse of an arbitrarily large amount of information. Similarly, a change to a source file often cannot be reparsed directly, but must first be preprocessed before being reparsed.

Although there are tricks for getting around this in some cases, they are quite complex and don't always work. Combine this with the grammatical complexity of C++ (C is simpler but far from trivial) and the typical size of C/C++ header/code files (thousands of lines), and you have a recipe for tool disaster.