On Sat, 29 Dec 2007 11:39:14 -0800, Walter Bright wrote:

> Derek Parnell wrote:
>> So I guess its not a necessary requirement but it is a nice thing to have, so we can lower the cost of developing acceptable applications.
> 
> Constness has 2 main uses:
> 
> 1) Better specification of an API. This is of little import for smaller projects or projects done by a very small team. It becomes important for large projects worked on by diverse teams. It essentially makes explicit what things a function can be expected to change, and what things it won't change.

In short, improved "documentation".

> 2) It makes functional programming possible. The plum FP gets us is it opens the door to automatic parallelization of code! C++ and Java are dead in the water when it comes to automatic parallelization - if there are multiple cores, the app needs to be painfully and carefully recoded to take advantage of them. With FP, this can be done automatically.

This sounds like your real underlying goal; to enable people to use D for FP.

> Some secondary advantages are:
> 
> 3) Better optimization.
> 
> 4) ROMable data.
> 
> What languages we use definitely shape our thinking about programming. C++  ... (2). Java  ...

I use neither. The languages I do use don't have much of a 'const' implementation and that has been a factor in the higher-than-acceptable cost of maintenance. I have long been sold on the benefits of being able to specify what and when data is immutable. You and I don't have an issue there.

My problems with D2 revolve around the syntax you have chosen for us, and the omissions in the 'const' paradigm you have decided are acceptable for us. Both of those, I foresee, will add to the cost of maintenance.

The D programming language already has too many over-used keywords and poorly chosen keywords.

The current decision to reuse 'enum' for manifest constants is yet another example of a designer believing that their intuition is better than their customers', regardless of any evidence to the contrary. Please reconsider that there might be a remote possibility that this decision is actually wrong in this case; 'enum' is not the best choice for developers when it comes to declaring manifest constants.

And yes, after using it for awhile we will get used to it, but that is not a reason for having it in the first place. We can get accustomed to the wart on our partners' nose but it will always be a wart.

The arguments to date for 'enum' boil down to (1) its easier to implement
given the current state of the D compiler, (2) C++ sort of, kind of, uses
it sometimes like that, and (3) you think its better than anything else.

Could it be that your point of view is not always the same as the developers' trying to use D?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Derek Parnell wrote:
> My problems with D2 revolve around the syntax you have chosen for us, and
> the omissions in the 'const' paradigm

I'm not sure what omissions you mean. The const scheme is pretty thorough end-to-end.

> you have decided are acceptable for
> us. Both of those, I foresee, will add to the cost of maintenance.

It's difficult to tell what is right without using it for a while.

> The D programming language already has too many over-used keywords and
> poorly chosen keywords.

Some have also argued that it has too many keywords, period.

> The current decision to reuse 'enum' for manifest constants is yet another
> example of a designer believing that their intuition is better than their
> customers', regardless of any evidence to the contrary. Please reconsider
> that there might be a remote possibility that this decision is actually
> wrong in this case; 'enum' is not the best choice for developers when it
> comes to declaring manifest constants.

There are a number of people who strongly feel it is the correct decision who are not vocal about it.

> And yes, after using it for awhile we will get used to it, but that is not
> a reason for having it in the first place. We can get accustomed to the
> wart on our partners' nose but it will always be a wart.
> 
> The arguments to date for 'enum' boil down to (1) its easier to implement
> given the current state of the D compiler,

Actually it's easier to invent another keyword.

> (2) C++ sort of, kind of, uses it sometimes like that, and

I brought up the C++ thing in the context of showing that enum is already routinely used for similar things.

> (3) you think its better than anything else.

That's not really an argument as to why I think it's the best option <g>.

> Could it be that your point of view is not always the same as the
> developers' trying to use D?

All I can say is try using it for a while. Give it a chance, and then see what you think. I initially got criticized a lot for using !( ) for templates rather than < >, but I think that time has shown it was a good decision.

On Sat, 29 Dec 2007 17:40:37 -0800, Walter Bright wrote:

Thank you for responding (N.B. That statement is truthful and not sarcasm)

> Derek Parnell wrote:
>> My problems with D2 revolve around the syntax you have chosen for us, and the omissions in the 'const' paradigm
> 
> I'm not sure what omissions you mean. The const scheme is pretty thorough end-to-end.

Does the scheme allow a mutable pointer to immutable data?

	?? (const int)* p

Does the scheme allow an immutable pointer to mutable data?

	?? (int *) const p

Does the scheme allow an immutable pointer to immutable data?

	?? (const int)* const p

(and for completeness) Does the scheme allow a mutable pointer to mutable
data?

	?? int *p

Can a mutable item become immutable at any time during the run time of an application?

Can you take a mutable copy of any immutable item? And is the syntax to do this dependant on the data type of the original?

Can you take a mutable copy of any immutable class object, struct or array? And is the syntax to do this dependant on the data type of the original?


>> you have decided are acceptable for
>> us. Both of those, I foresee, will add to the cost of maintenance.
> 
> It's difficult to tell what is right without using it for a while.

That idea does not apply to everything in life. I have not used cigarettes but I know they are not right.

Also "goto" can be shown to increase the cost of program maintenance without having to actually use it to demostrate this effect.

>> The D programming language already has too many over-used keywords and poorly chosen keywords.
> 
> Some have also argued that it has too many keywords, period.

I have not heard that comment from anyone.

>> The current decision to reuse 'enum' for manifest constants is yet another example of a designer believing that their intuition is better than their customers', regardless of any evidence to the contrary. Please reconsider that there might be a remote possibility that this decision is actually wrong in this case; 'enum' is not the best choice for developers when it comes to declaring manifest constants.
> 
> There are a number of people who strongly feel it is the correct decision who are not vocal about it.

If they are not vocal, how do you know about them? Can you give numbers?

>> And yes, after using it for awhile we will get used to it, but that is not a reason for having it in the first place. We can get accustomed to the wart on our partners' nose but it will always be a wart.
>> 
>> The arguments to date for 'enum' boil down to (1) its easier to implement given the current state of the D compiler,
> 
> Actually it's easier to invent another keyword.

That is good news then.

>> (2) C++ sort of, kind of, uses it sometimes like that, and
> 
> I brought up the C++ thing in the context of showing that enum is already routinely used for similar things.

And just like there are many of the bad things in C++ that have made it into D, right? Oh hang on, that's why you started D, to rid us of the misuse and insanity of some C++ idioms.

>> (3) you think its better than anything else.
> 
> That's not really an argument as to why I think it's the best option <g>.

I know that. But it has been used anyway.

>> Could it be that your point of view is not always the same as the developers' trying to use D?
> 
> All I can say is try using it for a while. Give it a chance, and then see what you think. I initially got criticized a lot for using !( ) for templates rather than < >, but I think that time has shown it was a good decision.

Actually I think that both < > and !() suck big time.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Derek Parnell wrote:
> Does the scheme allow a mutable pointer to immutable data? 
> 
> 	?? (const int)* p

Yes:
const(int)* p;


> Does the scheme allow an immutable pointer to mutable data? 
> 
> 	?? (int *) const p

No. If that's the omission you're referring to, I now understand your point.

> Does the scheme allow an immutable pointer to immutable data?
> 
> 	?? (const int)* const p

Yes:
const(int*) p;

> (and for completeness) Does the scheme allow a mutable pointer to mutable
> data?
> 
> 	?? int *p

Yes:
int* p;

> Can a mutable item become immutable at any time during the run time of an
> application?

Yes.

> Can you take a mutable copy of any immutable item?

Yes.

> And is the syntax to do
> this dependant on the data type of the original?

No, but if you want a deep copy, you'll have to implement .dup for your class/struct.

> Can you take a mutable copy of any immutable class object, struct or array?

Yes, but again you have to implement the dup if you want a deep copy.

> And is the syntax to do this dependant on the data type of the original?

No.

>>> you have decided are acceptable for
>>> us. Both of those, I foresee, will add to the cost of maintenance.
>> It's difficult to tell what is right without using it for a while.
> 
> That idea does not apply to everything in life. I have not used cigarettes
> but I know they are not right. 

I've never smoked because I know I'd like it, and I'd never get that monkey off my back. But there is plenty of experience on smoking - you know exactly what you're in for if you take it up.


> Also "goto" can be shown to increase the cost of program maintenance
> without having to actually use it to demostrate this effect.
> 
>>> The D programming language already has too many over-used keywords and
>>> poorly chosen keywords.
>> Some have also argued that it has too many keywords, period.
> 
> I have not heard that comment from anyone.

I have.


>>> The current decision to reuse 'enum' for manifest constants is yet another
>>> example of a designer believing that their intuition is better than their
>>> customers', regardless of any evidence to the contrary. Please reconsider
>>> that there might be a remote possibility that this decision is actually
>>> wrong in this case; 'enum' is not the best choice for developers when it
>>> comes to declaring manifest constants.
>> There are a number of people who strongly feel it is the correct decision who are not vocal about it.
> 
> If they are not vocal, how do you know about them?

They email me. There are many D users who do not participate here, but are still very much involved with D.

> Can you give numbers?

About as many as post here against it. There are also those who believe this is a tempest in a teapot, that we should be arguing about more important things :-)


>>> And yes, after using it for awhile we will get used to it, but that is not
>>> a reason for having it in the first place. We can get accustomed to the
>>> wart on our partners' nose but it will always be a wart.
>>>
>>> The arguments to date for 'enum' boil down to (1) its easier to implement
>>> given the current state of the D compiler,
>> Actually it's easier to invent another keyword.
> 
> That is good news then.
> 
>>> (2) C++ sort of, kind of, uses it sometimes like that, and
>> I brought up the C++ thing in the context of showing that enum is already routinely used for similar things.
> 
> And just like there are many of the bad things in C++ that have made it
> into D, right? Oh hang on, that's why you started D, to rid us of the
> misuse and insanity of some C++ idioms.

I guess one man's insanity is another man's sanity! Regardless of that, however, I think the C++ usage of it shows that people aren't so terribly confused about it, even if they don't like it.

>>> (3) you think its better than anything else.
>> That's not really an argument as to why I think it's the best option <g>.
> 
> I know that. But it has been used anyway.
>  
>>> Could it be that your point of view is not always the same as the
>>> developers' trying to use D?
>> All I can say is try using it for a while. Give it a chance, and then see what you think. I initially got criticized a lot for using !( ) for templates rather than < >, but I think that time has shown it was a good decision.
> 
> Actually I think that both < > and !() suck big time.

What would you have preferred?

Walter Bright wrote:
>>
>>>> The D programming language already has too many over-used keywords and
>>>> poorly chosen keywords.
>>> Some have also argued that it has too many keywords, period.
>>
>> I have not heard that comment from anyone.
> 
> I have.

I have too, like in comments about D from non-D users on Digg.  There seem to be some people who believe that number of keywords is directly related to the complexity of a language.  I think the line of reasoning goes: lisp has like 3 keywords; so if you need more than 3 keywords your language must be a crappy rat trap caving in under its own complexity.

Some people substitute "C" for "Lisp" or "elegance" for "simplicity".

Anyway, keyword count is a very silly way to choose a programming language.  I'll give you that lisp is small and elegant.  But once you get up to a C-ish number of keywords (~70?) there just ain't a whole lot of difference as long as what you're adding are not commonly used variable names like 'tmp' or 'value'.

Maybe someone else has better insight into the minds of these "keyword accountants" but from where I sit it just doesn't make a lot of sense to obsess over +/- a few dozen keywords in a C-like language.

--bb

Bill Baxter wrote:
> Maybe someone else has better insight into the minds of these "keyword accountants" but from where I sit it just doesn't make a lot of sense to obsess over +/- a few dozen keywords in a C-like language.

By itself, it is not an issue. But it can be an indicator of sloppy design.

Walter Bright wrote:
> Bill Baxter wrote:
>> Maybe someone else has better insight into the minds of these "keyword accountants" but from where I sit it just doesn't make a lot of sense to obsess over +/- a few dozen keywords in a C-like language.
> 
> By itself, it is not an issue. But it can be an indicator of sloppy design.

Agreed.  And judging a language merely by keyword count is a certain indicator of sloppy analysis :-)

--bb

Bill Baxter wrote:
> Walter Bright wrote:
>> Bill Baxter wrote:
>>> Maybe someone else has better insight into the minds of these "keyword accountants" but from where I sit it just doesn't make a lot of sense to obsess over +/- a few dozen keywords in a C-like language.
>>
>> By itself, it is not an issue. But it can be an indicator of sloppy design.
> 
> Agreed.  And judging a language merely by keyword count is a certain indicator of sloppy analysis :-)
> 
> --bb


I honestly wonder at what point D is to be considered too wordy? I suppose it's fair to assume that the critical point is determined by the designer(s), but I do wonder how any new syntax is ever to be argued in these forums based on the fact that the designer always brings this argument into play.  The general impression is "no new keywords allowed" even when they would seem to be the better option.

Even so, I think new keywords will be added... they are bound to be, but only of the designer's choice.  Oh well, time for me to let this rather fruitless discussion rest, I suppose.

I keep forgetting how the circle goes round and round. :)

-JJR

On Sat, 29 Dec 2007 19:24:05 -0800, Walter Bright wrote:
>>> All I can say is try using it for a while. Give it a chance, and then see what you think. I initially got criticized a lot for using !( ) for templates rather than < >, but I think that time has shown it was a good decision.
>> 
>> Actually I think that both < > and !() suck big time.
> 
> What would you have preferred?

I don't know because I haven't put any real thought to it. It would be pointless to do so now anyway.


I wait in great anticipation for the next incarnation of 'const'.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Too many keywords may give problems, this is a graph related to the Io language: http://www.iolanguage.com/about/simplicity/

But I think that using the same keyword to express two or more different meanings may be often worse. You can see a little example here:
http://www.space.unibe.ch/comp_doc/c_manual/C/SYNTAX/static.htm

At end of the page it says, regarding the C language:

>For some reason, static has different meanings in in different contexts.
1. When specified on a function declaration, it makes the function local to the file.
2. When specified with a variable inside a function, it allows the variable to retain its value between calls to the function. See static variables.
It seems a little strange that the same keyword has such different meanings...<

(Such meanings aren't that different...)
So I often don't mind adding some new keywords.

Bye,
bearophile