Different languages have different defaults. For example in Java all methods are are virtual by default and final on demand. In C# it's vice versa.

What I'd like to talk about is mutability. In Java all variables are mutable by default and constant on demand. In Caml it's vice versa.

So what is the design rational for mutable by default. Why

const foo := AClass.make()
bar := AClass.make()

instead of

foo := AClass.make();
mutable bar := AClass.make();

?

And why do properties have a setter by default and are readonly only on demand.

I'm a fan of immutability, but maybe that's because I'm a fan of functional programming languages.

Good question - although I definitely like the functional style, I personally don't have anything against mutable state. I only oppose mutable state shared between threads. I think if you were to really go immutable by default that would be a much more radical change than just changing field defaults. For example I think you really need to move towards the world of linked lists, recursion, tail calls, etc.

Instead I would say Fan is more of a baby step from the Java/C# world - we support immutability as a first class concept, but we don't go whole hog. I personally find that middle ground a sweet spot for me (but like everything it is just a matter of taste).

I understand how FP has garnered a lot of interest recently, but its not where most developers are at. In fact I suspect that Scala will remain a niche language at least in part because of being quite FP focussed.

I definitely wouldn't want to see fan changed to have cost variables by default.

I am still unconvinced about the change to have methods in fan be virtual only on request. I think we need to see how that plays out.

I'm surprised to hear an argument against non-virtual by default. IMO a class designer must explicitly design a method to be overridden as part of the class's contract. I've seen an awful lot of code where someone is overriding a method which wasn't designed to be overridden and the end result is programming by coincidence.

Also non-virtual is the safe default. I can always go back and make something virtual without breaking anything. But I can't change my mind and make something non-virtual - that is a breaking change.

I agree that const should be the default. Most variables that I create in Java never change. In fact, my ide defaults to final. For example:

final DataSource ds = lookup(..) final Connection c = ds.getConn() final PreparedStatement ps = c.prepareStatement(..) final ResultSet rs = ps.executeQuery()

The finals are really just extra noise. Also, with fan's flexible constructor and it-blocks, I will probably make instance fields const more often than i did with java.

In Java, I would forgo what seems like a good programming practice (to me) of preferring constructers (over setters) to initialize an object. The reason was because it was hard to read a construction like this:

p = new Person("Kelly","Ford",16,true)

So i would use setters for an otherwise immutable object. But fan's it-blocks solve that problem. So I would use this:

p = Person{

lastName = "Ford"
firstName = "Kelly"
shoeSize = 16
awesome = true

}

Why not make const the default when the whole class is declared const? Or add a class modifier like autoConst?

Are there compiler optimizations with const?

Also, if statics must be const than why not just do it (the compiler, i mean)? Why make us (the app programmer) do it? It seems a little silly.

I definitely wouldn't want to see fan changed to have cost variables by default.

I think two separate things are being discussed here. In Java, the final keyword means "single-assignment". The vast majority of variables (more than 95%) are assigned a single time, and enforcing this can sometimes prevent bugs. In Fan, the const keyword does not just mean "single-assignment", it means the value of the variable is immutable. Fan has no direct equivalent for final.

Why not make const the default when the whole class is declared const? Or add a class modifier like autoConst?

As JohnDG noted, const implies a stronger contract than Java final - the value type must be immutable also (or in the case of List/Map the toImmutable method is called automatically). So I am not sure it makes sense to make it the default.

Are there compiler optimizations with const?

Yes, const field access is done with GETFIELD opcode in JVM. Non-const fields are accessed with a virtual method call. Although in the case of non-virtual field access inside a pod, the compiler optimizes to direct field access. But in the end HotSpot typically optimizes all this away anyhow.

Also, if statics must be const than why not just do it (the compiler, i mean)? Why make us (the app programmer) do it? It seems a little silly.

I don't have a problem making const implied by the static modifier for a field. Can I get a survey how the rest of you feel about that change?

I've bumped against that one quite a bit lately -- translating Java to Fan, and first I get the "statics must be const" error, so I add const; then I get "initializing a const field with non-const type", so I have to rethink things a little.

I understand and appreciate the reasoning for requiring statics to be const, but it is an annoyance when I have to declare what the compiler already knows.

There needs to be some indication from the compiler as to why it's like that, though. So that when you get the error you know what to do to fix it.