8 ms·

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

by knocte 12y ago

btown 12y ago
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-control-structures/#variables 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.
- knocte 12y ago
  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?
  - twic 12y ago
    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/focusing-on-ownership/ 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!
    - gavinking 12y ago
      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.
ww520 12y ago
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.
- gavinking 12y ago
  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.
- frowaway001 12y ago
  > The world is very much mutable. LOL, what?
  - deleted 12y ago
    [deleted]
  - jkrems 12y ago
    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.
    - frowaway001 12y ago
      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.
    - davidrusu 12y ago
      Attach a date stamp to your references and facts and BOOM, everything is immutable!

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

by knocte 12y ago

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

btown 12y ago

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-control-structures/#variables 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.

knocte 12y ago
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?
- twic 12y ago
  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/focusing-on-ownership/ 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!
  - gavinking 12y ago
    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.

ww520 12y ago

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.

gavinking 12y ago
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.
frowaway001 12y ago
> The world is very much mutable. LOL, what?
- deleted 12y ago
  [deleted]
- jkrems 12y ago
  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.
  - frowaway001 12y ago
    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.
  - davidrusu 12y ago
    Attach a date stamp to your references and facts and BOOM, everything is immutable!