Walter Bright wrote:
> grauzone wrote:
>> Does this approach fit D at all? D is a C based system programming language. Does it work to demand from everyone to obey the const rules? Couldn't all this be done manually, instead of bothering the programmer with a complex type system?
> 
> Doing it manually is how it's done in C. And the results are it is a massive failure. It's just impractical to write reliable, portable, inspectable, and maintainable multithreaded code in C. Even the experts can't get the trivial cases right, as there was a famous recent example in Dr. Dobb's (forgot the name of the article at the moment).

I didn't mean going back to programming with locks. Instead you could use the new ideas without extending the type system. As far as I understand, the language extensions are only needed for verification (so far).

> struggling, see http://tinyurl.com/4apat7. I'm very glad that the tide on this group has effectively reversed with regard to the general opinion about const and immutable.

I think they got annoyed and tired by the weekly (daily?) new const proposal threads and went silent.

>> Sometimes, you have to leave the more spiffy features to languages like Erlang or Haskell which are suited better for this. For example, Erlang doesn't share any state by default, and in Haskell, everything is immutable. But they use very special mechanisms to make up for the problems caused by this, and that's why you can't just pick the cherries: it won't fit, it will feel unnatural, and everything will be a mess. It's a good idea to copy good features from other languages, but never forget where you come from.
> 
> We plan to add the necessary mechanisms.

What mechanisms will these be? I'm sure others are curious too.

grauzone wrote:
>>> Sometimes, you have to leave the more spiffy features to languages like Erlang or Haskell which are suited better for this. For example, Erlang doesn't share any state by default, and in Haskell, everything is immutable. But they use very special mechanisms to make up for the problems caused by this, and that's why you can't just pick the cherries: it won't fit, it will feel unnatural, and everything will be a mess. It's a good idea to copy good features from other languages, but never forget where you come from.
>>
>> We plan to add the necessary mechanisms.
> 
> What mechanisms will these be? I'm sure others are curious too.

Still under discussion. We're considering for example message-passing queues a la Erlang.

Andrei

grauzone wrote:
>> struggling, see http://tinyurl.com/4apat7. I'm very glad that the tide on this group has effectively reversed with regard to the general opinion about const and immutable.
> 
> I think they got annoyed and tired by the weekly (daily?) new const proposal threads and went silent.

and in another post:

> I mean, it's not like I'm threatening anyone or that I want to start
> flamewars, I just want to know more about this.

I was wondering how one goes with the other.


Andrei

Andrei Alexandrescu:
> We're considering for example message-passing queues a la Erlang.<

Actors, like in Erlang and Scala? (Please ignore this comment if it misses the point of this discussion).

Bye,
bearophile

grauzone wrote:
> I didn't mean going back to programming with locks. Instead you could use the new ideas without extending the type system. As far as I understand, the language extensions are only needed for verification (so far).

Without verification, it's programming by hopeful convention. If you want a reliable system, you need more than hope <g>.

> Still under discussion. We're considering for example message-passing queues a la Erlang.

yes yes yes ...

Andrei Alexandrescu wrote:
> grauzone wrote:
>>>> Sometimes, you have to leave the more spiffy features to languages like Erlang or Haskell which are suited better for this. For example, Erlang doesn't share any state by default, and in Haskell, everything is immutable. But they use very special mechanisms to make up for the problems caused by this, and that's why you can't just pick the cherries: it won't fit, it will feel unnatural, and everything will be a mess. It's a good idea to copy good features from other languages, but never forget where you come from.
>>>
>>> We plan to add the necessary mechanisms.
>>
>> What mechanisms will these be? I'm sure others are curious too.
> 
> Still under discussion. We're considering for example message-passing queues a la Erlang.
> 
> Andrei

A library-level feature, I hope, but I'd be quite interested in seeing how this would be implemented as a pure function.

Walter Bright wrote:
> grauzone wrote:
>> I didn't mean going back to programming with locks. Instead you could use the new ideas without extending the type system. As far as I understand, the language extensions are only needed for verification (so far).
> 
> Without verification, it's programming by hopeful convention. If you want a reliable system, you need more than hope <g>.

Well .. if you think about OOP and private/public ..

Dynamic languages like python and smalltalk don't enforce private/public, and that never was a problem. And, smalltalk is *the* OO language (AFAIK)

(this is not really an argument against const per se, it's just an argument against an argument for const)