www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - const sucks

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Just got this from Eric Niebler:

http://tinyurl.com/4apat7

Guess what Anders Heljsberg and Guy Steele have to say about future of 
programming languages.

Immutable and eliminating side effects are necessary. Quickly written 
down from Anders: "...we need support for immutable data at the language 
level..." "...so that the compiler can infer that there is isolation..." 
"... formalization of immutability... we don't have them in the language 
and it's nontrivial to put them in... and that's the big challenge." He 
goes on and describes the difficulties... and mentions "pure functions" 
and "transitivity" and "functional extensions"!!! "Pure FP is not the 
solution... what we try to do is to have islands of purity in functional 
style and switch between default to functional in a hybrid style of 
programming... the answer is not at the extreme..."

This is huge. You have to listen to it to hear just how huge it is. He 
is essentially describing some of the difficulties we have encountered 
and already solved in D2, so it looks we have a strategic advantage.

This is the confirmation I hoped was going to come someday. If it 
surprises me, it that it comes so early, so unequivocally, and so 
aligned terminologically. I'm in Nirvana.


Andrei

P.S. Guy Steele mentions Unicode operators favorably too. Nyuk-nyuk.
Oct 16 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 P.S. Guy Steele mentions Unicode operators favorably too. Nyuk-nyuk.

That's not surprising, because I think he has designed most of Fortress, that's unicode-based. Bye, bearophile
Oct 16 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Just got this from Eric Niebler:
 
 http://tinyurl.com/4apat7
 
 Guess what Anders Heljsberg and Guy Steele have to say about future of 
 programming languages.

It sure looks like they're going down the same path we did about a year ago.
Oct 16 2008
prev sibling next sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
news:gd85n2$9rq$1 digitalmars.com...
 Just got this from Eric Niebler:

 http://tinyurl.com/4apat7

 Guess what Anders Heljsberg and Guy Steele have to say about future of
 programming languages.

 Immutable and eliminating side effects are necessary. Quickly written down
 from Anders: "...we need support for immutable data at the language
 level..." "...so that the compiler can infer that there is isolation..."
 "... formalization of immutability... we don't have them in the language
 and it's nontrivial to put them in... and that's the big challenge." He
 goes on and describes the difficulties... and mentions "pure functions"
 and "transitivity" and "functional extensions"!!! "Pure FP is not the
 solution... what we try to do is to have islands of purity in functional
 style and switch between default to functional in a hybrid style of
 programming... the answer is not at the extreme..."

 This is huge. You have to listen to it to hear just how huge it is. He is
 essentially describing some of the difficulties we have encountered and
 already solved in D2, so it looks we have a strategic advantage.

 This is the confirmation I hoped was going to come someday. If it
 surprises me, it that it comes so early, so unequivocally, and so aligned
 terminologically. I'm in Nirvana.

Anders mentioned "... be clearer about where the mutation occurs and where the side-effects are, by in a sense switching the default to be more functional". Should D3 be the version that introduces default immutable storage and default pure functions? IIRC, this was discussed for D2 early on in the const discussion, but the consensus then was that it was too big of a leap for an imperative language.
Oct 17 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Dave wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gd85n2$9rq$1 digitalmars.com...
 Just got this from Eric Niebler:

 http://tinyurl.com/4apat7

 Guess what Anders Heljsberg and Guy Steele have to say about future of
 programming languages.

 Immutable and eliminating side effects are necessary. Quickly written 
 down
 from Anders: "...we need support for immutable data at the language
 level..." "...so that the compiler can infer that there is isolation..."
 "... formalization of immutability... we don't have them in the language
 and it's nontrivial to put them in... and that's the big challenge." He
 goes on and describes the difficulties... and mentions "pure functions"
 and "transitivity" and "functional extensions"!!! "Pure FP is not the
 solution... what we try to do is to have islands of purity in functional
 style and switch between default to functional in a hybrid style of
 programming... the answer is not at the extreme..."

 This is huge. You have to listen to it to hear just how huge it is. He is
 essentially describing some of the difficulties we have encountered and
 already solved in D2, so it looks we have a strategic advantage.

 This is the confirmation I hoped was going to come someday. If it
 surprises me, it that it comes so early, so unequivocally, and so aligned
 terminologically. I'm in Nirvana.

Anders mentioned "... be clearer about where the mutation occurs and where the side-effects are, by in a sense switching the default to be more functional". Should D3 be the version that introduces default immutable storage and default pure functions? IIRC, this was discussed for D2 early on in the const discussion, but the consensus then was that it was too big of a leap for an imperative language.

I'm very glad someone finally answered about the main thrust of the interview. I was a tad let down by the thundering silence following my post, which I attributed to its rather strident tone; in my defense, I have to say I was in a state of euphoria caused by such a comprehensive confirmation of beliefs and thinking patterns I held dear for years. That aside, I do highly recommend interested people to watch the video. It is slow and boring at times, but some very interesting points are being made, particularly about the relationship between manycores and immutability (fortunately, that's also towards the beginning of the interview). It sure makes D look like it placed a winning bet two (three?) years ago when we started working on immutability. To answer your point, Dave, I think the alea has been jacta with regard to D's flavor. We'll be unable to retire mutability as a matter of course, otherwise we might as well call the new language E :o). What we can do is to simplify introduction of places and regions where immutability is either a must, or the default. Also, we can better separate the places where mutability is harmless (stack data) from places where mutability causes problems (shared data). Walter is in fact working on language changes in that general direction. Andrei
Oct 17 2008
parent reply "Dave" <Dave_member pathlink.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gdbrq5$272j$1 digitalmars.com...
 Dave wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gd85n2$9rq$1 digitalmars.com...
 Just got this from Eric Niebler:

 http://tinyurl.com/4apat7

 Guess what Anders Heljsberg and Guy Steele have to say about future of
 programming languages.

 Immutable and eliminating side effects are necessary. Quickly written 
 down
 from Anders: "...we need support for immutable data at the language
 level..." "...so that the compiler can infer that there is isolation..."
 "... formalization of immutability... we don't have them in the language
 and it's nontrivial to put them in... and that's the big challenge." He
 goes on and describes the difficulties... and mentions "pure functions"
 and "transitivity" and "functional extensions"!!! "Pure FP is not the
 solution... what we try to do is to have islands of purity in functional
 style and switch between default to functional in a hybrid style of
 programming... the answer is not at the extreme..."

 This is huge. You have to listen to it to hear just how huge it is. He 
 is
 essentially describing some of the difficulties we have encountered and
 already solved in D2, so it looks we have a strategic advantage.

 This is the confirmation I hoped was going to come someday. If it
 surprises me, it that it comes so early, so unequivocally, and so 
 aligned
 terminologically. I'm in Nirvana.

Anders mentioned "... be clearer about where the mutation occurs and where the side-effects are, by in a sense switching the default to be more functional". Should D3 be the version that introduces default immutable storage and default pure functions? IIRC, this was discussed for D2 early on in the const discussion, but the consensus then was that it was too big of a leap for an imperative language.

I'm very glad someone finally answered about the main thrust of the interview. I was a tad let down by the thundering silence following my post, which I attributed to its rather strident tone; in my defense, I have to say I was in a state of euphoria caused by such a comprehensive confirmation of beliefs and thinking patterns I held dear for years.

It is great to have these D2 design initiatives reaffirmed!
 That aside, I do highly recommend interested people to watch the video. It 
 is slow and boring at times, but some very interesting points are being 
 made, particularly about the relationship between manycores and 
 immutability (fortunately, that's also towards the beginning of the 
 interview). It sure makes D look like it placed a winning bet two (three?) 
 years ago when we started working on immutability.

 To answer your point, Dave, I think the alea has been jacta with regard to 
 D's flavor. We'll be unable to retire mutability as a matter of course, 
 otherwise we might as well call the new language E :o). What we

I'd like to read more opinions on D3 "default immutapurity"... IIRC, even though it was considered a stretch for D2 it was actually discussed for a time, and (again IIRC) I don't think Walter was neccessarily the one who put the kabosh on that direction of thought. If D3 doesn't try it first, someone might get "E" right in the meantime <g>. Anders seemed to intimate that "E" is a direction he's considering, and hasn't MS Research already been experimenting with something like this (not F#, but with another C#-based, primarily imperative language)? Someone posted a link a while back... Anyway, it kind of seems a logical progression to me, especially considering this from: http://www.digitalmars.com/d/2.0/const-faq.html#const "Here's the biggie. Points 1..3 are insignificant in comparison. The future of programming will be multicore, multithreaded. Languages that make it easy to program them will supplant languages that don't. Transitive const is key to bringing D into this paradigm. The surge in use of Haskell and Erlang is evidence of this coming trend (the killer feature of those languages is they make it easy to do multiprogramming). C++ cannot be retrofitted to supporting multiprogramming in a manner that makes it accessible. D isn't there yet, but it will be, and transitive const will be absolutely fundamental to making it work." Point is, what does D3 have to lose by at least exploring "default immutapurity" initially? Even if does turn out to be somewhat of a rabbit hole, it would probably either validate or serve to help improve the compiler and language design w.r.t. immutable storage and pure functions. And maybe along the way a lot of interesting things would be learned about porting the std. lib. perhaps? Based on the video and where things are headed, a language that takes the best of imperative pragramatism and functional computer science might be just what we all need <g>
 can do is to simplify introduction of places and regions where 
 immutability is either a must, or the default. Also, we can better 
 separate the places where mutability is harmless (stack data) from places 
 where mutability causes problems (shared data). Walter is in fact working 
 on language changes in that general direction.

That's terrific to hear; perhaps if the changes make it into D2, and it turns out that developers find themselves making the majority of code "immutapure" anyhow, it may make sense to approach things from the other side for D3...
 Andrei

Oct 18 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Dave,

 I'd like to read more opinions on D3 "default immutapurity"... IIRC,
 even though it was considered a stretch for D2 it was actually
 discussed for a time, and (again IIRC) I don't think Walter was
 neccessarily the one who put the kabosh on that direction of thought.
 
 If D3 doesn't try it first, someone might get "E" right in the
 meantime <g>. Anders seemed to intimate that "E" is a direction he's
 considering, and hasn't MS Research already been experimenting with
 something like this (not F#, but with another C#-based, primarily
 imperative language)? Someone posted a link a while back...
 
 Anyway, it kind of seems a logical progression to me, especially
 considering this from:
 http://www.digitalmars.com/d/2.0/const-faq.html#const
 

I have extremely limited experience with const, so my opinion bears very little weight on the matter... but, for what's its worth, I agree with Dave. I think it would great to explore "immutability by default" regardless of the precedent set by original D and C++ (Hah! Throw caution to the wind!). "Explore" being the key word: "after trying it for a bit, we might get used to it." :-D I was just reading the link above too, and I notice that this would fix consistancy with "Why aren't function parameters const by default?" I imagine that's already been brought up multiple times before, though. Any chance that we might see an experimental version of this? I'm surprised it hasn't been tried with D considering all the other attempts made with const already. Are there any other drawbacks with default immutability other than breaking with the norm? -JJR
Oct 18 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
John Reimer wrote:
 Are there any other drawbacks with default immutability other than 
 breaking with the norm?

Well for one thing much of OO style involves creating few objects that hold their state and evolve in well-defined ways. Many objects are "entity" objects, meaning that holding a reference to a particular object is the way to stay in touch. In FP style new objects are being created all the time, so the programming styles are very different. But by and large I find it very interesting that the tide has changed to the extent that this option is being discussed. It's good progress from the const-should-die-a-gruesome-death view :o). Andrei
Oct 18 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I think you mean "this option is being discussed *once again*".  It
 was discussed quite a lot before the current invariant/const was
 implemented.  The consensus was definitely that it was worth a shot.
 But it did not get a shot.

Yes, it was discussed a lot.
 I recall Walter's main argument against it was that local variable
 really shouldn't be const-by-default since you're usually creating
 them because you want to manipulate them.  But then you end up with a
 system where local variable declarations and parameter declarations
 follow very different rules.  "int[] foo" in one place means something
 different from "int[] foo" in the other place.  I'm not convinced this
 would be that confusing, though.  There could be other problems with
 const-by-default in parameters, but that one doesn't seem like such a
 big deal.

The problem is things like: void foo(int[] a) { int[] b; } so a is const, and b is mutable? That's very confusing. It gives the appearance of D having a lot of wacky and arbitrary semantic rules.
Oct 18 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Walter,

 Bill Baxter wrote:
 
 I think you mean "this option is being discussed *once again*".  It
 was discussed quite a lot before the current invariant/const was
 implemented.  The consensus was definitely that it was worth a shot.
 But it did not get a shot.
 

 I recall Walter's main argument against it was that local variable
 really shouldn't be const-by-default since you're usually creating
 them because you want to manipulate them.  But then you end up with a
 system where local variable declarations and parameter declarations
 follow very different rules.  "int[] foo" in one place means
 something different from "int[] foo" in the other place.  I'm not
 convinced this would be that confusing, though.  There could be other
 problems with const-by-default in parameters, but that one doesn't
 seem like such a big deal.
 

void foo(int[] a) { int[] b; } so a is const, and b is mutable? That's very confusing. It gives the appearance of D having a lot of wacky and arbitrary semantic rules.

I'll have to go dig up all the past discussions on this (there were volumes that I mostly skipped over). My impression of mutable by default was more than function parameters. Weren't we talking something like this when referring to "immutable by default": // void foo(int[] a) // { // int b; // mutable int c; // // /* block declaration */ // // mutable // { // int d; // int e; // } // } 'a' is an implied const (immutable) parameter. 'b' is const by default 'c', 'd', and 'e' are all declared mutable. Isn't this what is meant by "constant by default"? I haven't described class variables here, of course. I'm nervous to comment further lest I have totally misunderstood what's going on. :) -JJR
Oct 18 2008
next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello John,

 My impression of mutable by default was more than function parameters.
 
 Weren't we talking something like this when referring to "immutable by
 default":
 
 // void foo(int[] a)
 // {
 //     int b;
 //     mutable int c;
 //
 //     /* block declaration */
 //
 //     mutable
 //     {
 //          int d;
 //          int e;
 //      }
 // }
 'a' is an implied const (immutable) parameter.
 'b' is const by default
 'c', 'd', and 'e' are all declared mutable.
 Isn't this what is meant by "constant by default"?  I haven't
 described class variables here, of course.
 
 I'm nervous to comment further lest I have totally misunderstood
 what's going on. :)
 
 -JJR
 

Sorry, I really should have reviewed this before posting. I see that const-by-default was referring to parameters only. Shame on me. Even so, I think the argument that it would make D confusing if parameters are const and variables are mutable by default merely falls to convention: it mostly disruptive because it's such a big change from C++. Perhaps that's a big argument against it, but ultimately it's usefulness might be more important? I can't say much for or against, I suppose, so I'll avoid saying much more until I understand this better. I suppose the other matter discussed was concerning class objects as Andrei indicated, which appears to be discussed much in past threads, if I'm not mistaken. -JJR
Oct 18 2008
prev sibling parent Benji Smith <dlanguage benjismith.net> writes:
John Reimer wrote:
 My impression of mutable by default was more than function parameters.
 
 Weren't we talking something like this when referring to "immutable by 
 default":
 
 // void foo(int[] a)
 // {
 //     int b;
 //     mutable int c;
 //
 //     /* block declaration */
 //
 //     mutable //     {
 //          int d;
 //          int e;
 //      }
 // }
 
 'a' is an implied const (immutable) parameter.
 'b' is const by default
 'c', 'd', and 'e' are all declared mutable.
 
 Isn't this what is meant by "constant by default"?  I haven't described 
 class variables here, of course.
 
 I'm nervous to comment further lest I have totally misunderstood what's 
 going on. :)

My understanding of the proposal was that "const by default" was only for function parameters. And I agree with walter that it's a little but wonky and unexpected. But I liked it anyhow, and I think people could have easily gotten used to the distinction in constness between function params and all other variables. Especially since the compiler would always be able to catch the mistake. --benji
Oct 18 2008
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 18 Oct 2008 20:36:51 -0700, Walter Bright wrote:

 The problem is things like:
 
    void foo(int[] a)
    {
      int[] b;
    }
 
 so a is const, and b is mutable? That's very confusing. It gives the 
 appearance of D having a lot of wacky and arbitrary semantic rules.

I work with the Euphoria language and this has been the case since its begining. No one, from newbie-coder to experienced coders of a number of languages have EVER thought this as weird. In Euphoria, there is NO WAY one can change a function's argument. The caller of a function can have complete confidence that any argument passed will not have its value changed by the function. However, variables local to the function are not immutable. Your fears may need empirical evidence before I would take them seriously. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Oct 19 2008
next sibling parent Don <nospam nospam.com.au> writes:
Bill Baxter wrote:
 On Mon, Oct 20, 2008 at 5:50 AM, Derek Parnell <derek psych.ward> wrote:
 On Sat, 18 Oct 2008 20:36:51 -0700, Walter Bright wrote:

 The problem is things like:

    void foo(int[] a)
    {
      int[] b;
    }

 so a is const, and b is mutable? That's very confusing. It gives the
 appearance of D having a lot of wacky and arbitrary semantic rules.

begining. No one, from newbie-coder to experienced coders of a number of languages have EVER thought this as weird. In Euphoria, there is NO WAY one can change a function's argument. The caller of a function can have complete confidence that any argument passed will not have its value changed by the function. However, variables local to the function are not immutable. Your fears may need empirical evidence before I would take them seriously.

Yeh, and on the other side, I remember way back when I was learning C as a newbie that I found it was surprising that parameters acted just like local variables. When you think about it, yeh, they are basically, but as a newbie the thought never occurred to me that they were (or should be) the same thing.

Learning C, I remember being astonished that it was legal to modify a parameter. It still feels wrong to me, so I never do it. Even in asm! They've always felt to me that they are part of the calling function.
 Even now in D what you can do with them is different.  You can only
 have 'in' or 'ref' on parameters, not on local variables.  So I too
 think more evidence is needed that such a change will make code
 confusing.
 
 --bb

Oct 20 2008
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Sat, 18 Oct 2008 20:36:51 -0700, Walter Bright wrote:
 
 The problem is things like:

    void foo(int[] a)
    {
      int[] b;
    }

 so a is const, and b is mutable? That's very confusing. It gives the 
 appearance of D having a lot of wacky and arbitrary semantic rules.

I work with the Euphoria language and this has been the case since its begining. No one, from newbie-coder to experienced coders of a number of languages have EVER thought this as weird. In Euphoria, there is NO WAY one can change a function's argument. The caller of a function can have complete confidence that any argument passed will not have its value changed by the function. However, variables local to the function are not immutable. Your fears may need empirical evidence before I would take them seriously.

Well claiming that you know what everybody using Euphoria has ever thought sets the standard pretty low in terms of evidence. Andrei
Oct 19 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:
 
 I recall Walter's main argument against it was that local variable
 really shouldn't be const-by-default since you're usually creating
 them because you want to manipulate them.  But then you end up with a
 system where local variable declarations and parameter declarations
 follow very different rules.

Pure functions already work this way, so perhaps this isn't a big deal. Sean
Oct 20 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
 Bill Baxter wrote:
 I recall Walter's main argument against it was that local variable
 really shouldn't be const-by-default since you're usually creating
 them because you want to manipulate them.  But then you end up with a
 system where local variable declarations and parameter declarations
 follow very different rules.

Pure functions already work this way, so perhaps this isn't a big deal. Sean

Are you sure of that? Reading the latest about pure: http://dobbscodetalk.com/index.php?option=com_content&task=view&id=745&Itemid= I don't see were you can infer that. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 21 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bill Baxter wrote:
 I recall Walter's main argument against it was that local variable
 really shouldn't be const-by-default since you're usually creating
 them because you want to manipulate them.  But then you end up with a
 system where local variable declarations and parameter declarations
 follow very different rules.

Pure functions already work this way, so perhaps this isn't a big deal.

Are you sure of that? Reading the latest about pure: http://dobbscodetalk.com/index.php?option=com_content&task=view&id=745&Itemid= I don't see were you can infer that.

I simply meant that pure functions require reference parameters to be const, not that they are implicitly const. Sean
Oct 21 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Oct 19, 2008 at 6:35 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 John Reimer wrote:
 Are there any other drawbacks with default immutability other than
 breaking with the norm?

Well for one thing much of OO style involves creating few objects that hold their state and evolve in well-defined ways. Many objects are "entity" objects, meaning that holding a reference to a particular object is the way to stay in touch. In FP style new objects are being created all the time, so the programming styles are very different. But by and large I find it very interesting that the tide has changed to the extent that this option is being discussed. It's good progress from the const-should-die-a-gruesome-death view :o).

I think you mean "this option is being discussed *once again*". It was discussed quite a lot before the current invariant/const was implemented. The consensus was definitely that it was worth a shot. But it did not get a shot. I recall Walter's main argument against it was that local variable really shouldn't be const-by-default since you're usually creating them because you want to manipulate them. But then you end up with a system where local variable declarations and parameter declarations follow very different rules. "int[] foo" in one place means something different from "int[] foo" in the other place. I'm not convinced this would be that confusing, though. There could be other problems with const-by-default in parameters, but that one doesn't seem like such a big deal. --bb
Oct 18 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Oct 20, 2008 at 5:50 AM, Derek Parnell <derek psych.ward> wrote:
 On Sat, 18 Oct 2008 20:36:51 -0700, Walter Bright wrote:

 The problem is things like:

    void foo(int[] a)
    {
      int[] b;
    }

 so a is const, and b is mutable? That's very confusing. It gives the
 appearance of D having a lot of wacky and arbitrary semantic rules.

I work with the Euphoria language and this has been the case since its begining. No one, from newbie-coder to experienced coders of a number of languages have EVER thought this as weird. In Euphoria, there is NO WAY one can change a function's argument. The caller of a function can have complete confidence that any argument passed will not have its value changed by the function. However, variables local to the function are not immutable. Your fears may need empirical evidence before I would take them seriously.

Yeh, and on the other side, I remember way back when I was learning C as a newbie that I found it was surprising that parameters acted just like local variables. When you think about it, yeh, they are basically, but as a newbie the thought never occurred to me that they were (or should be) the same thing. Even now in D what you can do with them is different. You can only have 'in' or 'ref' on parameters, not on local variables. So I too think more evidence is needed that such a change will make code confusing. --bb
Oct 19 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Oct 20, 2008 at 6:14 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Derek Parnell wrote:
 On Sat, 18 Oct 2008 20:36:51 -0700, Walter Bright wrote:

 The problem is things like:

   void foo(int[] a)
   {
     int[] b;
   }

 so a is const, and b is mutable? That's very confusing. It gives the
 appearance of D having a lot of wacky and arbitrary semantic rules.

I work with the Euphoria language and this has been the case since its begining. No one, from newbie-coder to experienced coders of a number of languages have EVER thought this as weird. In Euphoria, there is NO WAY one can change a function's argument. The caller of a function can have complete confidence that any argument passed will not have its value changed by the function. However, variables local to the function are not immutable. Your fears may need empirical evidence before I would take them seriously.

Well claiming that you know what everybody using Euphoria has ever thought sets the standard pretty low in terms of evidence.

Although I'm 90% sure Derek just mean that he's never seen anyone complain about it on the Euphoria mailing list, it's not a bad suggestion to collect some harder data. Derek, if you didn't already do this the last time const by default came up, how about taking a survey on the Euphoria mailing list? Ask if anyone finds (or found at first) the immutable parameters to be confusing. --bb
Oct 20 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 18, 2008 at 2:22 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Dave wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gd85n2$9rq$1 digitalmars.com...
 Just got this from Eric Niebler:

 http://tinyurl.com/4apat7

 Guess what Anders Heljsberg and Guy Steele have to say about future of
 programming languages.

 Immutable and eliminating side effects are necessary. Quickly written
 down
 from Anders: "...we need support for immutable data at the language
 level..." "...so that the compiler can infer that there is isolation..."
 "... formalization of immutability... we don't have them in the language
 and it's nontrivial to put them in... and that's the big challenge." He
 goes on and describes the difficulties... and mentions "pure functions"
 and "transitivity" and "functional extensions"!!! "Pure FP is not the
 solution... what we try to do is to have islands of purity in functional
 style and switch between default to functional in a hybrid style of
 programming... the answer is not at the extreme..."

 This is huge. You have to listen to it to hear just how huge it is. He is
 essentially describing some of the difficulties we have encountered and
 already solved in D2, so it looks we have a strategic advantage.

 This is the confirmation I hoped was going to come someday. If it
 surprises me, it that it comes so early, so unequivocally, and so aligned
 terminologically. I'm in Nirvana.

Anders mentioned "... be clearer about where the mutation occurs and where the side-effects are, by in a sense switching the default to be more functional". Should D3 be the version that introduces default immutable storage and default pure functions? IIRC, this was discussed for D2 early on in the const discussion, but the consensus then was that it was too big of a leap for an imperative language.

I'm very glad someone finally answered about the main thrust of the interview. I was a tad let down by the thundering silence following my post, which I attributed to its rather strident tone; in my defense, I have to say I was in a state of euphoria caused by such a comprehensive confirmation of beliefs and thinking patterns I held dear for years. That aside, I do highly recommend interested people to watch the video. It is slow and boring at times, but some very interesting points are being made, particularly about the relationship between manycores and immutability (fortunately, that's also towards the beginning of the interview). It sure makes D look like it placed a winning bet two (three?) years ago when we started working on immutability.

I watched it yesterday. It was pretty interesting, but also kinda boring in the sense that it was like watching a video version of the D Programming Language newsgroup from a year ago. Thanks for the link. I didn't really have anything to say other than agree with what you posted, so I didn't post. :-) Probably the most fun for me was seeing what Anders and Guy are like, since I've heard their names many times, but never their faces or their speaking. --bb
Oct 17 2008
prev sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Sat, 18 Oct 2008 00:22:18 -0500, Andrei Alexandrescu wrote:

 Dave wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gd85n2$9rq$1 digitalmars.com...
 Just got this from Eric Niebler:

 http://tinyurl.com/4apat7

 Guess what Anders Heljsberg and Guy Steele have to say about future of
 programming languages.

 Immutable and eliminating side effects are necessary. Quickly written
 down
 from Anders: "...we need support for immutable data at the language
 level..." "...so that the compiler can infer that there is
 isolation..." "... formalization of immutability... we don't have them
 in the language and it's nontrivial to put them in... and that's the
 big challenge." He goes on and describes the difficulties... and
 mentions "pure functions" and "transitivity" and "functional
 extensions"!!! "Pure FP is not the solution... what we try to do is to
 have islands of purity in functional style and switch between default
 to functional in a hybrid style of programming... the answer is not at
 the extreme..."

 This is huge. You have to listen to it to hear just how huge it is. He
 is essentially describing some of the difficulties we have encountered
 and already solved in D2, so it looks we have a strategic advantage.

 This is the confirmation I hoped was going to come someday. If it
 surprises me, it that it comes so early, so unequivocally, and so
 aligned terminologically. I'm in Nirvana.

where the side-effects are, by in a sense switching the default to be more functional". Should D3 be the version that introduces default immutable storage and default pure functions? IIRC, this was discussed for D2 early on in the const discussion, but the consensus then was that it was too big of a leap for an imperative language.

I'm very glad someone finally answered about the main thrust of the interview. I was a tad let down by the thundering silence following my post, which I attributed to its rather strident tone; in my defense, I have to say I was in a state of euphoria caused by such a comprehensive confirmation of beliefs and thinking patterns I held dear for years. That aside, I do highly recommend interested people to watch the video. It is slow and boring at times, but some very interesting points are being made, particularly about the relationship between manycores and immutability (fortunately, that's also towards the beginning of the interview). It sure makes D look like it placed a winning bet two (three?) years ago when we started working on immutability. To answer your point, Dave, I think the alea has been jacta with regard to D's flavor. We'll be unable to retire mutability as a matter of course, otherwise we might as well call the new language E :o). What we can do is to simplify introduction of places and regions where immutability is either a must, or the default. Also, we can better separate the places where mutability is harmless (stack data) from places where mutability causes problems (shared data). Walter is in fact working on language changes in that general direction. Andrei

I am with Bill, I didn't have much to comment on so saying, "Go D!" would be too much like digg, "up voted for awesomeness." I say take the silence as lack of disagreement. With respect to "default immutable" I like the direction D is taking, where you are able to know only a small piece of the "const" and continue to program in a better C++. I think being able to "hide" the feature will be good in expanding its popularity and seems that it is being done in a way that is still easy to use. And the mutable stack, great idea.
Oct 18 2008
prev sibling next sibling parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
Looks familiar :-)

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77477

- Bent


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> skrev i meddelelsen 
news:gd85n2$9rq$1 digitalmars.com...
 Just got this from Eric Niebler:

 http://tinyurl.com/4apat7

 Guess what Anders Heljsberg and Guy Steele have to say about future of 
 programming languages.

 Immutable and eliminating side effects are necessary. Quickly written down 
 from Anders: "...we need support for immutable data at the language 
 level..." "...so that the compiler can infer that there is isolation..." 
 "... formalization of immutability... we don't have them in the language 
 and it's nontrivial to put them in... and that's the big challenge." He 
 goes on and describes the difficulties... and mentions "pure functions" 
 and "transitivity" and "functional extensions"!!! "Pure FP is not the 
 solution... what we try to do is to have islands of purity in functional 
 style and switch between default to functional in a hybrid style of 
 programming... the answer is not at the extreme..."

 This is huge. You have to listen to it to hear just how huge it is. He is 
 essentially describing some of the difficulties we have encountered and 
 already solved in D2, so it looks we have a strategic advantage.

 This is the confirmation I hoped was going to come someday. If it 
 surprises me, it that it comes so early, so unequivocally, and so aligned 
 terminologically. I'm in Nirvana.


 Andrei

 P.S. Guy Steele mentions Unicode operators favorably too. Nyuk-nyuk. 

Oct 18 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:
 Just got this from Eric Niebler:
 
 http://tinyurl.com/4apat7
 
 Guess what Anders Heljsberg and Guy Steele have to say about future of 
 programming languages.
 
 Immutable and eliminating side effects are necessary. Quickly written 
 down from Anders: "...we need support for immutable data at the language 
 level..." "...so that the compiler can infer that there is isolation..." 
 "... formalization of immutability... we don't have them in the language 
 and it's nontrivial to put them in... and that's the big challenge." He 
 goes on and describes the difficulties... and mentions "pure functions" 
 and "transitivity" and "functional extensions"!!! "Pure FP is not the 
 solution... what we try to do is to have islands of purity in functional 
 style and switch between default to functional in a hybrid style of 
 programming... the answer is not at the extreme..."
 
 This is huge. You have to listen to it to hear just how huge it is. He 
 is essentially describing some of the difficulties we have encountered 
 and already solved in D2, so it looks we have a strategic advantage.
 
 This is the confirmation I hoped was going to come someday. If it 
 surprises me, it that it comes so early, so unequivocally, and so 
 aligned terminologically. I'm in Nirvana.
 
 
 Andrei
 
 P.S. Guy Steele mentions Unicode operators favorably too. Nyuk-nyuk.

Hum, nice talk overall. I also point as interesting the part about language adoption, where the ecosystem and killer app where mentioned as important factors (although Guy's definition of killer app was a bit different than what I expected). -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 21 2008