Walter Bright:
> People who do work in large corporations managing extremely large codebases with legions of programmers working on them have made this abundantly clear to me.

You have to be really careful about adding features supported by such "evidence". Dynamic languages show that often such people are wrong, or they bark at the wrong tree, or there are alternative ways (totally different ones, that they can't even think about, like test driven development in a dynamically typed language) to solve similar problems. What they say are ways to solve problems in languages like C++ and Java, but experience shows that totally different ways can be invented, in different languages, to avoid some of those problems.

(I am for the backporting of some features of 2.x to 1.x, because I don't like the const system of 2.x, and I'm not going to use it (for now), but I understand that it may lead to too much work for D developers).

Bye,
bearophile

bearophile wrote:
> Walter Bright:
>> People who do work in large corporations managing extremely large
>> codebases with legions of programmers working on them have made
>> this abundantly clear to me.
> 
> You have to be really careful about adding features supported by such
> "evidence". Dynamic languages show that often such people are wrong,
> or they bark at the wrong tree, or there are alternative ways
> (totally different ones, that they can't even think about, like test
> driven development in a dynamically typed language) to solve similar
> problems. What they say are ways to solve problems in languages like
> C++ and Java, but experience shows that totally different ways can be
> invented, in different languages, to avoid some of those problems.

I agree that one has to be careful about what evidence one pays attention to. I'm not convinced about the evidence of dynamic languages, however, as I don't believe dynamic languages are used for very large programs. The reigning kings of large scale apps are C++ and Java. C++ has const, and there is continuing pressure to add some form of const to Java.

> 
> (I am for the backporting of some features of 2.x to 1.x, because I
> don't like the const system of 2.x, and I'm not going to use it (for
> now), but I understand that it may lead to too much work for D
> developers).
> 
> Bye, bearophile

On Fri, 07 Mar 2008 11:44:36 -0800, Walter Bright wrote:


> The reigning kings of large scale apps are C++ and Java.

I work with the banking industry and COBOL holds its head up high in that world.

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

Derek Parnell wrote:
> On Fri, 07 Mar 2008 11:44:36 -0800, Walter Bright wrote:
> 
> 
>> The reigning kings of large scale apps are C++ and Java. 
> 
> I work with the banking industry and COBOL holds its head up high in that
> world.
> 

And has it const?

--bb

On Sat, 08 Mar 2008 06:30:50 +0900, Bill Baxter wrote:

> Derek Parnell wrote:
>> I work with the banking industry and COBOL holds its head up high in that world.
>> 
> 
> And has it const?


ROFLMAO

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

Derek Parnell wrote:
> On Sat, 08 Mar 2008 06:30:50 +0900, Bill Baxter wrote:
> 
>> Derek Parnell wrote:
>>> I work with the banking industry and COBOL holds its head up high in that
>>> world.
>>>
>> And has it const?
> 
> 
> ROFLMAO

No I take it?

Still it's not necessarily a useful datapoint since it was designed long before "const" existed.

But it is still updated, right?  I remember the company I was working for losing a sale to some big customer who decided to go with some fancy tarted up Object COBOL thing.  Ooh yeh yeh this is the one http://www.microfocus.com/products/more/ObjectCOBOLDeveloperSuite/index.asp.

MicroFocus.  Wow, haven't heard that name in a long time.

Anyway, they added object orientation to Cobol, but not const?  That tells you something.

What's the deal with const in C#?  Anyone care to give a summary?  I see conflicting things in my googling.  Somethign about readonly objects, but no const/readonly for parameters to functions?

--bb

Bill Baxter wrote:
> What's the deal with const in C#?  Anyone care to give a summary?  I see conflicting things in my googling.  Somethign about readonly objects, but no const/readonly for parameters to functions?
> 
> --bb

const: compile-time constant.
readonly: you can assign it exactly once, and (IIRC) only field assignment or in a constructor. You can modify it after, though.

And I just checked -- neither const nor readonly are valid outside class/struct field declarations.

Bill Baxter wrote:
> What's the deal with const in C#?  Anyone care to give a summary?  I see conflicting things in my googling.  Somethign about readonly objects, but no const/readonly for parameters to functions?
> 
> --bb

The "const" keyword is only for value types. The "readonly" keyword can only be applied to (the reference of) instance variables. No const parameters and no const methods.

Const parameters are faked with read-only wrappers like List<T>.AsReadOnly().

Interestingly there's not that much pressure for const in C# as there's for const in Java.


-- 
Julio César Carrascal Urquijo
http://jcesar.artelogico.com/