Hacker News Reader

Comment by knocte | Hacker News Reader

I see that immutability is not a first-class citizen in this language... mmmhhh....

It actually seems to default to immutability, and have mutability as a first-class citizen with the language annotation `variable`: http://ceylon-lang.org/documentation/1.0/tour/attributes-con...

I'm not sure if it's quite as flexible as C++'s const-correctness, but if you're creating your own class hierarchy from scratch, you can (and are encouraged to) code in a style that basically ensures that every parameter is practically passed as a const (immutable) reference. So you can easily do things like make strongly-typed functional data structures that will compiler-complain if you try to modify them after creation, without needing to remember to type "const" all the time. And that's realistically what most people need at the end of the day.

I'm excited to experiment with this - it seems definitely designed by pragmatists who want to lower the barrier to entry and make it fun for non-functional programmers to code in (I'm looking at you, Haskell), but also encouraging and enforcing best practices wherever possible.

When I wrote my comment, I was actually looking at how variables inside a method are declared, not fields (attributes, as they call it in this language) like you mention (seems like the 'variable' keyword is not for local variables, but for attributes).

So I was mainly hoping it is like F#, that forces you to decorate non-immutable variables with the `mutable` keyword, inside a method/function.

However, thinking about it more deeply, this is not so important. Because local variables (in a method) are never shared between threads. So immutability doesn't suffer from them being mutable. Right?

Probably right. One of the Rust developers suggested something similar (but more nuanced, because Rust is a highly nuantial language):

http://smallcultfollowing.com/babysteps/blog/2014/05/13/focu...

"Put another way, it’s become clear to me over time that the problems with data races and memory safety arise when you have both aliasing and mutability. The functional approach to solving this problem is to remove mutability. Rust’s approach would be to remove aliasing."

Local variables themselves are naturally non-aliased, although the objects they point to might be.

PS apologies to anyone who's seen it before for trotting that link out yet again!

In Ceylon even local variables must be explicitly annotated `variable`.

The reason for that is that a local variable could be captured by an anonymous function or nested function, and escape from the local scope, so it's exactly the same situation with a local variable as for an instance variable of a class: both kinds of variable break referential transparency.

Immutability is kind of an overrated fad. The world is very much mutable. I want to see how languages manage mutability. Languages that provide simple mechanisms and tools to manage mutability go a long way to help the programmers to cope with the real problems.

> The world is very much mutable.

LOL, what?

Depending on your concept of time, it very much is. If you choose the same abstraction of time for reasoning about the program state and the real world, the same "reference" might change its properties over time. The speed of a car is mutable over time. The question is if the way we reason about time when talking about the "real" world is appropriate for reasoning about time in programs.

Yes, you mention it. Time.

Time is a real property just like IO, effects, values and types. If people stop hand-waving, we would have fewer bugs.

Attach a date stamp to your references and facts and BOOM, everything is immutable!

Immutability is an excellent tool to manage mutability. It lets you make guarantees about what won't change, which allows for some really great optimisations - like safe cross-thread reads without locks.

I agree it's not right for everything, but there are a lot of operations that can be modelled with immutable data, such as most server-side web code - reads definitely, and a lot of the write operations don't actually need to mutate objects though most ORMs and other DB APIs do require this.

> The world is very much mutable

This depends on your definition of "the world". If time and memory are taken into account, you could easily make the case that the world is very much immutable. For example, if your friend changes his email address, its not as if his old address no longer exists. Even if it only exists in memory, it still exists somewhere, and you're still able to reference it.

If you're interested in this topic, I highly recommend Rich Hickey's talk "The Value of Values"[1].

[1] http://www.infoq.com/presentations/Value-Values.

In that case, the reference is still mutable even if the email address isn't. One may also delete an account; i.e. you can change the state of something. A language should set clear boundaries on what is mutable or not, and I see both FP and IP languages going with extreme boundaries in either direction.

Mutability is a great tool; it dramatically simplifies certain algorithms, and dramatically improves performance of others. But it comes at a cost, and there are situations in which it is inappropriate. So the language should force you to think before reaching for this tool. It shouldn't be the default tool for every problem.

Reply on news.ycombinator.com