www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Focus

reply "bearophile" <bearophileHUGS lycos.com> writes:
Do you know why Walter is currently working on this stuff? Is 
this an optimization? If it's an optimization, do you know why it 
is more important than implementing "scope" or an unpacking 
syntax for tuples?

https://github.com/D-Programming-Language/dmd/commit/fc4462b95307d5c31d4c0bcf830faf6686b0feae

If that's an optimization, and most people are going to use LDC 
or GDC in future, why is Walter working on that stuff?

Also do you know why Walter is working still on D1? Isn't D1 code 
going to be deleted, to have a purely D2 code on GitHub?

Currently there are 118 open pull requests:
https://github.com/D-Programming-Language/dmd/pulls

Maybe (probably) not every one of them is good, but among them 
there is lot of stuff I've asked in bug reports and enhancement 
requests, thanks to Hara and others. If 50% of the biggest pull 
requests of those 118 gets pulled, the D language will feel 
almost as a new thing.

Also, I don't agree a lot about the "fog of war" theory by 
Walter. I think a development plan should be discussed, written 
down, and then followed (and dynamically fixed, when necessary). 
Building a new system language has a high risk of failure, but 
there's no need to also shot D in the feet on purpose.

Bye,
bearophile
Jan 18 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Friday, 18 January 2013 at 20:21:47 UTC, bearophile wrote:

 Also, I don't agree a lot about the "fog of war" theory by 
 Walter.


I must have missed that one, what's it about?


 I think a development plan should be discussed, written down, 
 and then followed (and dynamically fixed, when necessary). 
 Building a new system language has a high risk of failure, but 
 there's no need to also shot D in the feet on purpose.


Yes, a plan is sorely lacking. Also the language specification 
can be much  better managed. For example, there's no clear plan 
for it, no clear revision history, discussions for improvements 
are made but then get lost or forgotten, etc. If it were better 
managed, many advantages become apparent, such as being able to 
link a particular release of the compiler to a specific revision 
of the language that the compiler supports, but that's just one 
benefit. The limited resources can be more focused on fixing 
specific parts of the compiler because that specific area was 
made a priority. What's the priority right now? I don't know, and 
that's not sending a confidence inspiring message to the people 
who are thinking about taking a risk and using D.

On the positive side, we have seen a recent improvement with the 
rolling out of a defined development and release process. Some of 
the details are still being sorted out, but it is a;ready huge 
improvement and may help kick start more of the same thing. We 
just need to keep working towards expanding the process to 
include other areas of D development.

--rt
Jan 18 2013
parent reply "Andrey" <andr-sar yandex.ru> writes:
Me and many others consider D as consistent, free and clever 
replacement for screwed(IMHO) C++. From that perspective the 
current design of D already has necessary things. I would like 
developers to focus on fixing issues and polishing everything 
rather than trying to implement something new and experimental.

The most common suggestions raises such problems as:

- the garbage collecting system (the ability to control and 
implement manual collectors or, at least, improve the precise and 
speed of the current);
- efficient and comfortable handling of dynamic libraries;
- extending standard library, because it lacks of many modules 
(containers, xml parser), more developed OS support and wrappers 
for popular libs;
- user defined operators (including support for unicode math 
stuff).

I'm not saying about production instruments, like IDEs, static 
code analyzers, debuggers.

I'm now still on 2.060 release, and I was shocked when suddenly 
have discovered that member visibility and access attributes just 
don't work! Well, 2060 release, and I can easily compile such 
thing:

struct MyStruct {
    private int a;
}

MyStruct ms;
ms.a = 42; //!!!
writeln(ms.a);

So, when you observe this situation, it becomes really hard to 
pursue fully fledged commercial development with D.

I love D and I hate C++. But I still need to code on C/C++ for 
food.

Anyway, cheers everybody. Hope one day to see D as leading and 
very efficient world-wide platform.
Jan 18 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2013 2:16 PM, Andrey wrote:

 I'm now still on 2.060 release, and I was shocked when suddenly have discovered
 that member visibility and access attributes just don't work! Well, 2060
 release, and I can easily compile such thing:

 struct MyStruct {
     private int a;
 }

 MyStruct ms;
 ms.a = 42; //!!!
 writeln(ms.a);



This is by design, not a bug. All code in a module has access to all private 
members in that same module. This obviates the need for the C++ "friend" 
declarations.
Jan 18 2013
next sibling parent reply "Andrey" <andr-sar yandex.ru> writes:
 MyStruct ms;
 ms.a = 42; //!!!
 writeln(ms.a);



 This is by design, not a bug. All code in a module has access 
 to all private members in that same module. This obviates the 
 need for the C++ "friend" declarations.


Wikipedia states:

«In general, encapsulation is one of the 4 fundamentals of OOP 
(object-oriented programming). Encapsulation is to hide the 
variables or something inside a class, preventing unauthorized 
parties to use.»

So how am I supposed to hide the variable inside the struct or 
class? I don't want anything to access it outside struct 
definition. And I don't see any point in giving the opportunity 
to access it using "friend" invitation. I'm sure "friend" 
explodes the basics of OOP encapsulation mechanics.

Struct is an «container» that owns its declarations and use 
special word for this: private. Then comes completely another 
data structure and can easily manipulate private members of 
another. Only imagine the other man from the neighbor house comes 
into your house and take your children without asking only 
because he lives on the same street.
Jan 18 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:

 So how am I supposed to hide the variable inside the struct or 
 class?


Generally the D answer here is to put them in separate files. The 
module (file) is the main D encapsulation unit rather than the 
class/struct.

It isn't the same as C++ but I find it works pretty well - you 
often do one file per class anyway, and files are a natural unit 
for encapsulating too.


 I'm sure "friend" explodes the basics of OOP encapsulation 
 mechanics.


http://www.parashift.com/c++-faq/friends-and-encap.html

If you have helper structures it can be useful to get at the 
private parts anyway, for example an iteration range.
Jan 18 2013
next sibling parent reply "Andrey" <andr-sar yandex.ru> writes:
On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:

 On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:

 So how am I supposed to hide the variable inside the struct or 
 class?


 Generally the D answer here is to put them in separate files. 
 The module (file) is the main D encapsulation unit rather than 
 the class/struct.

 It isn't the same as C++ but I find it works pretty well - you 
 often do one file per class anyway, and files are a natural 
 unit for encapsulating too.


 I'm sure "friend" explodes the basics of OOP encapsulation 
 mechanics.


 http://www.parashift.com/c++-faq/friends-and-encap.html

 If you have helper structures it can be useful to get at the 
 private parts anyway, for example an iteration range.


Are nested classes quite more perfectly suited for this? In my 
containers I implement iterator interface using nested class. 
Then I can easily construct mycontainer.new Iterator and have 
(should have by theory) access to protected (not private) 
members. Also I will be ensured that this is a proper iterator 
and that it can be constructed only when I have the instantiated 
parent container.

And after that D forces you to restrict access not via default 
language construct, but via having one declaration per file. I 
think this is a not correct. In OOP concept you don't have such 
thing as a file or module. There are no files, there is ONE 
program with multiple data structures and hierarchies, united 
under one super root. Well, at least, that is how this supposed 
to work from the start.

«Actually I made up the term "object-oriented", and I can tell 
you I did not have C++ in mind.» Alan Key.
Jan 18 2013
next sibling parent "Andrey" <andr-sar yandex.ru> writes:
 «Actually I made up the term "object-oriented", and I can tell 
 you I did not have C++ in mind.» Alan Key.


Kay, of course. Alan Curtis Kay. Sorry for my english. :-)
Jan 18 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2013 4:55 PM, Andrey wrote:

 Are nested classes quite more perfectly suited for this? In my containers I
 implement iterator interface using nested class. Then I can easily construct
 mycontainer.new Iterator and have (should have by theory) access to protected
 (not private) members. Also I will be ensured that this is a proper iterator
and
 that it can be constructed only when I have the instantiated parent container.

 And after that D forces you to restrict access not via default language
 construct, but via having one declaration per file. I think this is a not
 correct. In OOP concept you don't have such thing as a file or module. There
are
 no files, there is ONE program with multiple data structures and hierarchies,
 united under one super root. Well, at least, that is how this supposed to work
 from the start.


This all falls apart once you decide you need "friend" access.
Jan 18 2013
next sibling parent reply "Andrey" <andr-sar yandex.ru> writes:
 This all falls apart once you decide you need "friend" access.


I haven't seen such situations yet. According to OOP concept they 
must be very rare, so I tend to consider them more of 
architecture and logic mistake (and C++ is one big architecture 
and logic frankenstein).

Once again, in D you have active nested classes that can 
automatically reference parent and this allows very nice and 
accurate compositions. So the need for separate small supporting 
class is eliminated, because it integrates into its parent. 
Moreover, you preserve very well the "program with interface" 
idiom.

For example, you have a List container and a Array container. 
Then you have general iterator interface.

interface iIterator {...}

class List {

      class Iterator : iIterator {specific implementation}
}

class Array {

      class Iterator : iIterator {another specific implementation}
}

And then you can switch between two containers easily preserving 
the rest of code: List.new Iterator <-> Array.new Iterator;

Of course, you can make this work by having two different factory 
functions returning proper iterator implementation for class.

class List {

     iIterator constructIterator() { return new 
ListIterator(this); }
}

But this is artificial, speculative, not language feature. 
Compiler still can't figure out any bond shared between classes. 
And for that reason we have a simple helper "friend" in C++. D 
understands the hierarchy, but for unknown reason refuses to take 
full advantage of this feature. And we could use it to establish 
concrete and specific links instead of outer module wrapper 
container.

Well, I don't want to force any changes. Just trying to better 
understand D. This became off-topic.
Jan 18 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2013 6:50 PM, Andrey wrote:

 And for that reason we have a simple helper "friend" in C++.


C++ friends are quite complex and are a giant pain. D's method of everything in 
a module being implicitly a friend has been working very well for 10 years now.
Jan 18 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 19 January 2013 at 03:40:35 UTC, Walter Bright wrote:

 On 1/18/2013 6:50 PM, Andrey wrote:

 And for that reason we have a simple helper "friend" in C++.


 C++ friends are quite complex and are a giant pain. D's method 
 of everything in a module being implicitly a friend has been 
 working very well for 10 years now.


That is also the way to go IMO.

The usual definition of encapsulation is way too much object 
centric. In many language, you'll find out that a class == a 
module (or pretty much in practice). This don't fit at all 
multi-paradigm, where D does pretty well.
Jan 18 2013
parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
 That is also the way to go IMO.

 snip


This isn't directed at you, or any other poster for that matter
(I am to technically inept to figure out how to post to the
thread other than using the 'reply' feature)...

Anyway, just wanted to say that this thread got off topic in an
awful hurry.
Jan 18 2013
parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
 snip

 Anyway, just wanted to say that this thread got off topic in an
 awful hurry.


It sort of funny that the thread started off with a complaint
about Walters lack of focus and quickly got off topic.  Maybe
lack of focus is a common attribute of people interested in D.

I suggested that D be renamed the ADD language.
Jan 18 2013
parent Miles Stoudenmire <miles.stoudenmire gmail.com> writes:
Here is a helpful discussion on stack overflow about whether friend in
C++ breaks encapsulation:
http://stackoverflow.com/questions/1093618/how-does-the-friend-keyword-class-function-break-encapsulation-in-c

Also an article on encapsulation by Scott Meyers:
http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

Basically I think the consensus is that encapsulation != everything is
private. Also I like Meyer's point that encapsulation is a means, not
an end.



On 18 January 2013 20:11, Craig Dillabaugh <cdillaba cg.scs.carleton.ca> wrote:

 snip


 Anyway, just wanted to say that this thread got off topic in an
 awful hurry.



 It sort of funny that the thread started off with a complaint
 about Walters lack of focus and quickly got off topic.  Maybe
 lack of focus is a common attribute of people interested in D.

 I suggested that D be renamed the ADD language.




-- 
   -=Miles Stoudenmire=-
   miles.stoudenmire gmail.com
   estouden uci.edu
   http://itensor.org/miles/
Jan 18 2013
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 19.01.2013 03:50, schrieb Andrey:

 This all falls apart once you decide you need "friend" access.


 I haven't seen such situations yet. According to OOP concept they must
 be very rare, so I tend to consider them more of architecture and logic
 mistake (and C++ is one big architecture and logic frankenstein).


In .NET languages this is internal access.

In JVM languages, package default access.

So there is a need for such features.

--
Paulo
Jan 19 2013
prev sibling next sibling parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Saturday, 19 January 2013 at 02:50:35 UTC, Andrey wrote:

 This all falls apart once you decide you need "friend" access.


 I haven't seen such situations yet. According to OOP concept 
 they must be very rare, so I tend to consider them more of 
 architecture and logic mistake (and C++ is one big architecture 
 and logic frankenstein).


Sorry for being a little harsh, but there's a big warning sign on 
the Overview page of this site:

Who D is Not For:
Language purists. D is a practical language, and each feature of 
it is evaluated in that light, rather than by an ideal.

All of this stuff about pure (or true) OOP concept, when you just 
don't need such hacks as "friend" is good on paper. But most of 
the time it's very expensive to stick with such kind of purity 
rigorously.

Or even is just a completely bad idea. Consider algorithms for 
data structures being members in true-OO vs. STL/D-ranges 
approach or everything is a function with no side-effects in 
"pure" functional languages.
Jan 19 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-19 03:50, Andrey wrote:


 I haven't seen such situations yet. According to OOP concept they must
 be very rare, so I tend to consider them more of architecture and logic
 mistake (and C++ is one big architecture and logic frankenstein).


In theory and according to the OOP concept they might not be needed but 
when it comes to actually implement a OO concept it can turn out to be 
handy to have. That is, accessing a private member in the same module.

-- 
/Jacob Carlborg
Jan 19 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 19.01.2013 16:26, schrieb Jacob Carlborg:

 On 2013-01-19 03:50, Andrey wrote:


 I haven't seen such situations yet. According to OOP concept they must
 be very rare, so I tend to consider them more of architecture and logic
 mistake (and C++ is one big architecture and logic frankenstein).


 In theory and according to the OOP concept they might not be needed but
 when it comes to actually implement a OO concept it can turn out to be
 handy to have. That is, accessing a private member in the same module.


I do use it a lot when doing unit tests that check for side effects in 
the private data (JVM/.NET) of objects.
Jan 19 2013
prev sibling parent "Andrey" <andr-sar yandex.ru> writes:
 In theory and according to the OOP concept they might not be 
 needed but when it comes to actually implement a OO concept it 
 can turn out to be handy to have. That is, accessing a private 
 member in the same module.


Allright. But I don't see a reason why this coudln't be done with 
nested classes. If some class wants frequently to access parent's 
members, then it preferably demands constant reference to it and 
therefore need to be presented as inner class. Then we can better 
and more intelligently track the existence and cooperation of 
both classes.

And, as it was said, there is no actual encapsulation unless you 
have organized runtime access checks to the memory chunk occupied 
by an object. Maybe the creators of D can implement this using 
contract programming or other things, I do not know. But this can 
be really a huge step towards safety. The real effect may be seen 
if the whole OS is written in object oriented manner, and its 
processes and services have the built-in hierarchical access 
policy. Such architecture makes possible natural cooperation 
between various core modules, processes and the user space. Maybe 
even existence in one address space without the need of slow 
artificial system calls.

If someone wants to continue discussing OOP, then I suggest to 
move to another thread to stop polluting this topic. Although I 
think that there are enough debates around OOP in the Internet 
already and yet another one will not make difference.
Jan 19 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright wrote:

 On 1/18/2013 4:55 PM, Andrey wrote:
 This all falls apart once you decide you need "friend" access.


What is wrong with this POV is that the original class no longer 
has a word to say if she wants to be friended by someone.

In C++ the class has a word to say: if it does not declare: "hey! 
you will be my friend!", then nobody can come there to say: "hey! 
I consider myself your friend (even if you don't want it), so I 
will mess up your internal state!"
Jan 21 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:

 On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright 
 wrote:

 On 1/18/2013 4:55 PM, Andrey wrote:
 This all falls apart once you decide you need "friend" access.


 What is wrong with this POV is that the original class no 
 longer has a word to say if she wants to be friended by someone.

 In C++ the class has a word to say: if it does not declare: 
 "hey! you will be my friend!", then nobody can come there to 
 say: "hey! I consider myself your friend (even if you don't 
 want it), so I will mess up your internal state!"


Only if that class is in the same module.

This is being blown completely out of proportion.

A few things to consider:

- Lots of languages don't have access control at all, yet somehow 
people use them without problem.
- As far as I can see, the DMD source has very few private 
variables, yet very few (if any) bugs are caused by people 
messing up other people's variables.
- If you have one class per module, D is no different to
Jan 21 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 13:16:03 UTC, Peter Alexander wrote:

 On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:

 On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright 
 wrote:

 On 1/18/2013 4:55 PM, Andrey wrote:




 - Lots of languages don't have access control at all, yet 
 somehow people use them without problem.


Lots of languages do not even have classes. Lots of languages do 
not even have functions. Lots of languages are... assembler.


 - As far as I can see, the DMD source has very few private 
 variables, yet very few (if any) bugs are caused by people 
 messing up other people's variables.


In the beginning, C++ programs had very few bugs. Then, real 
coding in C++ happened. BTW, DMD (not phobos) source is C++ 
(https://github.com/D-Programming-Language/dmd/blob/master/src/arrayop.c), 
not D.


 - If you have one class per module, D is no different to 



Yes... And if you define:
struct var *p2=new_from_data(p1->a, p1->b, p1->c);
then you have a copy constructor... Straight, isn't?
Jan 21 2013
parent "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 13:32:35 UTC, eles wrote:

 On Monday, 21 January 2013 at 13:16:03 UTC, Peter Alexander 
 wrote:

 On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:

 On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright 
 wrote:

 On 1/18/2013 4:55 PM, Andrey wrote:






 In the beginning, C++ programs had very few bugs. Then, real 
 coding in C++ happened. BTW, DMD (not phobos) source is C++ 
 (https://github.com/D-Programming-Language/dmd/blob/master/src/arrayop.c), 
 not D.



BTW, Walter, pls take a moment and change the extension of those 
files from .c to .cpp.
Jan 21 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/21/13, Peter Alexander <peter.alexander.au gmail.com> wrote:

 This is being blown completely out of proportion.


I don't think so.

Consider that currently it's impossible to hide any symbols from a
user if they are located in subpackages. Which means you're forced to
either put everything into the same package and use the package access
specifier, or put everything into the same module.

The problem I have with this is it makes it impossible to separate
implementation-specific modules into their subpackages without giving
access of these symbols to the user. Consider that the following would
make a nice folder structure for a library:

lib/gui.d
lib/platform/win32/gui.d
lib/platform/posix/gui.d

Unfortunately everything in lib/platform must be public in order for
gui.d to use it, and as a consequence user-code ends up having access
to these platforms-specific implementation modules.

You could move everything into the lib folder and use the package
access specifier. That also means class methods must have package
access to prevent the user from invoking them, but this automatically
makes them non-virtual.

Bottom line is, the module system and access specifiers can use some
improvements. Language XYZ might do something in its own way, but D is
a language of its own and we should feel free to innovate.
Jan 21 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic wrote:

 On 1/21/13, Peter Alexander <peter.alexander.au gmail.com> 
 wrote:

 This is being blown completely out of proportion.


 I don't think so.

 Consider that currently it's impossible to hide any symbols 
 from a
 user if they are located in subpackages. Which means you're 
 forced to
 either put everything into the same package and use the package 
 access
 specifier, or put everything into the same module.


Package have nothing to do with the private discussion that take 
place here.


 The problem I have with this is it makes it impossible to 
 separate
 implementation-specific modules into their subpackages without 
 giving
 access of these symbols to the user. Consider that the 
 following would
 make a nice folder structure for a library:

 lib/gui.d
 lib/platform/win32/gui.d
 lib/platform/posix/gui.d

 Unfortunately everything in lib/platform must be public in 
 order for
 gui.d to use it, and as a consequence user-code ends up having 
 access
 to these platforms-specific implementation modules.


Ideally, package should allow this in a way or another.
Jan 21 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/21/13, deadalnix <deadalnix gmail.com> wrote:

 Package have nothing to do with the private discussion that take
 place here.


It's completely relevant.
Jan 21 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/13 9:41 AM, Andrej Mitrovic wrote:

 On 1/21/13, deadalnix<deadalnix gmail.com>  wrote:

 Package have nothing to do with the private discussion that take
 place here.


 It's completely relevant.


FWIW I think they are distinct issues.

Andrei
Jan 21 2013
prev sibling parent reply "Rob T" <alanb ucora.com> writes:
On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic wrote:

 Bottom line is, the module system and access specifiers can use 
 some
 improvements. Language XYZ might do something in its own way, 
 but D is
 a language of its own and we should feel free to innovate.


Yes modules can be improved considerably and made much more 
practical. For example, you should be able to specify in the 
module what components are to be exported to a DI interface file 
and in what form. Currently  there's no control, and everything 
gets dumped in the DI, then you have to hand craft it to hide 
implementation details. If you want D to become more popular, you 
have to allow for the hiding of implementation details, and you 
have to make it simple for the programmer to do it.

We could do much better with a road map of what needs to be done 
with priorities set.

--rt
Jan 21 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 19:43:15 UTC, Rob T wrote:

 On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic 
 wrote:

 Bottom line is, the module system and access specifiers can 
 use some
 improvements. Language XYZ might do something in its own way, 
 but D is
 a language of its own and we should feel free to innovate.


 Yes modules can be improved considerably and made much more 
 practical. For example, you should be able to specify in the 
 module what components are to be exported to a DI interface 
 file and in what form. Currently  there's no control, and 
 everything gets dumped in the DI, then you have to hand craft 
 it to hide implementation details. If you want D to become more 
 popular, you have to allow for the hiding of implementation 
 details, and you have to make it simple for the programmer to 
 do it.

 We could do much better with a road map of what needs to be 
 done with priorities set.


I suggesting by starting to address any unargumented proposition 
to "make D more popular" to Dave Null. He'll be very happy to 
help.
Jan 21 2013
prev sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:

 On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:

 So how am I supposed to hide the variable inside the struct or 
 class?




 I'm sure "friend" explodes the basics of OOP encapsulation 
 mechanics.


 http://www.parashift.com/c++-faq/friends-and-encap.html

 If you have helper structures it can be useful to get at the 
 private parts anyway, for example an iteration range.


http://yosefk.com/c++fqa/friend.html#fqa-14.2

Unfortunately this applies to D in some kind of speaking.
Jan 18 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/13 2:35 AM, Maxim Fomin wrote:

 On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:

 On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:

 So how am I supposed to hide the variable inside the struct or class?




 I'm sure "friend" explodes the basics of OOP encapsulation mechanics.


 http://www.parashift.com/c++-faq/friends-and-encap.html

 If you have helper structures it can be useful to get at the private
 parts anyway, for example an iteration range.


 http://yosefk.com/c++fqa/friend.html#fqa-14.2


I think that's a rather poor piece.

Andrei
Jan 19 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 19 January 2013 at 13:12:32 UTC, Andrei Alexandrescu 
wrote:

 On 1/19/13 2:35 AM, Maxim Fomin wrote:

 On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe 
 wrote:

 On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:

 So how am I supposed to hide the variable inside the struct 
 or class?




 I'm sure "friend" explodes the basics of OOP encapsulation 
 mechanics.


 http://www.parashift.com/c++-faq/friends-and-encap.html

 If you have helper structures it can be useful to get at the 
 private
 parts anyway, for example an iteration range.


 http://yosefk.com/c++fqa/friend.html#fqa-14.2


 I think that's a rather poor piece.

 Andrei


How much chances does this program have?
----------mylib.di--------
class A
{
	public int i;
}

void foo(A a);
---------mylib.d---------
class A
{
	public int i;
	private int ii;
}

void foo(A a)
{
	if (a !is null)
	{
		a.ii = 2;
	}
}
---------main.d---------
import mylib;

void main()
{
	A a = new A;
	a.foo();
}
------------------------




?
Jan 19 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/13 8:21 AM, Maxim Fomin wrote:

 How much chances does this program have?
 ----------mylib.di--------
 class A
 {
 public int i;
 }

 void foo(A a);
 ---------mylib.d---------
 class A
 {
 public int i;
 private int ii;
 }


Looks like an ODR violation, but oddly there's nothing stopping us from 
making this work. It's a good idea to pursue.

Andrei
Jan 19 2013
next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 19 January 2013 at 13:57:02 UTC, Andrei Alexandrescu 
wrote:

 On 1/19/13 8:21 AM, Maxim Fomin wrote:

 How much chances does this program have?


 Looks like an ODR violation, but oddly there's nothing stopping 
 us from making this work. It's a good idea to pursue.

 Andrei


Unfortunately, this will never work in general. That code runs 
because private member was placed after public and because 
_d_new_class got "right" Typeinfo (compiled from mylib, not from 
main). If a private member is placed before a public one, than 
this will lead to troubles because dmd just generates (wrong) 
offsets from base pointer.

What I wanted to say is that in D private members should be 
included in declaration in general case (sometimes the opposite 
may work by chance) which partly defeats encapsulation.

For example, if you make changes in class which affects order of 
private members, you have to recompile all code which uses that 
class. That is a poor encapsulation.
Jan 19 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/13 9:23 AM, Maxim Fomin wrote:

 On Saturday, 19 January 2013 at 13:57:02 UTC, Andrei Alexandrescu wrote:

 On 1/19/13 8:21 AM, Maxim Fomin wrote:

 How much chances does this program have?


 Looks like an ODR violation, but oddly there's nothing stopping us
 from making this work. It's a good idea to pursue.

 Andrei


 Unfortunately, this will never work in general. That code runs because
 private member was placed after public and because _d_new_class got
 "right" Typeinfo (compiled from mylib, not from main). If a private
 member is placed before a public one, than this will lead to troubles
 because dmd just generates (wrong) offsets from base pointer.

 What I wanted to say is that in D private members should be included in
 declaration in general case (sometimes the opposite may work by chance)
 which partly defeats encapsulation.

 For example, if you make changes in class which affects order of private
 members, you have to recompile all code which uses that class. That is a
 poor encapsulation.


I knew where you were driving. These are well-known tradeoffs. More 
robust modularity could be achieved at the expense of good layout. I was 
saying it would be interesting if we could allow better hiding in select 
cases (like the one in the example).

Andrei
Jan 19 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/19/2013 5:57 AM, Andrei Alexandrescu wrote:

 On 1/19/13 8:21 AM, Maxim Fomin wrote:

 How much chances does this program have?
 ----------mylib.di--------
 class A
 {
 public int i;
 }

 void foo(A a);
 ---------mylib.d---------
 class A
 {
 public int i;
 private int ii;
 }


 Looks like an ODR violation, but oddly there's nothing stopping us from making
 this work. It's a good idea to pursue.


It can only work if the user is very well aware of how classes are laid out, 
avoids things that depend on the instance size, etc.
Jan 19 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/13 1:36 PM, Walter Bright wrote:

 On 1/19/2013 5:57 AM, Andrei Alexandrescu wrote:

 On 1/19/13 8:21 AM, Maxim Fomin wrote:

 How much chances does this program have?
 ----------mylib.di--------
 class A
 {
 public int i;
 }

 void foo(A a);
 ---------mylib.d---------
 class A
 {
 public int i;
 private int ii;
 }


 Looks like an ODR violation, but oddly there's nothing stopping us
 from making
 this work. It's a good idea to pursue.


 It can only work if the user is very well aware of how classes are laid
 out, avoids things that depend on the instance size, etc.


Well I'm thinking of scenarios in which the implementation file imports 
and verifies the incomplete declaration file.

Andrei
Jan 19 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/19/2013 01:04 AM, Andrey wrote:

 MyStruct ms;
 ms.a = 42; //!!!
 writeln(ms.a);



 This is by design, not a bug. All code in a module has access to all
 private members in that same module. This obviates the need for the
 C++ "friend" declarations.


 Wikipedia states:

 «In general, encapsulation is one of the 4 fundamentals of OOP
 (object-oriented programming). Encapsulation is to hide the variables or
 something inside a class, preventing unauthorized parties to use.»


Even if this definition was accurate, note that it does not state what 
"unauthorized" means. Languages that implement OOP can (and do) vary in 
this aspect.

Also, it goes on like:
«So the public methods like getter and setter access it and the other 
classes call these methods for accessing.»

Obviously the author of that sentence had no idea what encapsulation is 
about!


 So how am I supposed to hide the variable inside the struct or class? I
 don't want anything to access it outside struct definition. And I don't
 see any point in giving the opportunity to access it using "friend"
 invitation. I'm sure "friend" explodes the basics of OOP encapsulation
 mechanics.


No it does not. "friend" attempts to work around the inexpressiveness of 
accessibility modifiers.


 Struct is an «container» that owns its declarations and use special word
 for this: private. Then comes completely another data structure and can
 easily manipulate private members of another. Only imagine the other man
 from the neighbor house comes into your house and take your children
 without asking only because he lives on the same street.


The module is the house, not the street. "Encapsulation" is sometimes 
applied (or pseudo-applied) at a way too small scale by programmers who 
do not understand it. It is not magic.
Jan 18 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright wrote:

 On 1/18/2013 2:16 PM, Andrey wrote:

 This is by design, not a bug. All code in a module has access 
 to all private members in that same module. This obviates the 
 need for the C++ "friend" declarations.


Yes, but that is a bad choice. The simplest argument against it 
it is that it is a departure of C++. Yes, you've made "private" 
like Java (package), but that's not the first intended audience.

If you cannot go back with private acting like C++ private, then 
at least introduce an "internal" specifier for things that truly 
belongs to the class only (ie: the C++ private).

You could have:

internal
private
package
protected
public
export

or

private
semiprivate // well? better ideas?
package
protected
public
export

Why make access protection dependent of how the source code is 
spread into files?
Jan 21 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:

 On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright wrote:

 On 1/18/2013 2:16 PM, Andrey wrote:

 This is by design, not a bug. All code in a module has access 
 to all private members in that same module. This obviates the 
 need for the C++ "friend" declarations.


 Yes, but that is a bad choice. The simplest argument against it 
 it is that it is a departure of C++. Yes, you've made "private" 
 like Java (package), but that's not the first intended audience.

 If you cannot go back with private acting like C++ private, 
 then at least introduce an "internal" specifier for things that 
 truly belongs to the class only (ie: the C++ private).

 You could have:

 internal
 private
 package
 protected
 public
 export

 or

 private
 semiprivate // well? better ideas?
 package
 protected
 public
 export

 Why make access protection dependent of how the source code is 
 spread into files?


What would be the point ? You'll have the implementation and the 
function definition under the nose anyway as it is in the same 
file.

If something should be private from your code, what is your code 
doing is the same module ?
Jan 21 2013
parent reply "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:

 On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:

 On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright 
 wrote:

 On 1/18/2013 2:16 PM, Andrey wrote:




 What would be the point ? You'll have the implementation and 
 the function definition under the nose anyway as it is in the 
 same file.

 If something should be private from your code, what is your 
 code doing is the same module ?


1. Quoting Andrey's original post (3rd on this thread):

"So, when you observe this situation, it becomes really hard to
pursue fully fledged commercial development with D."

So, if you think that D is so string that it allows itself such 
ingenuities that makes C++ programmers giving it a try to scream 
away from D, then fine. D already has difficulties in being 
accepted by corporations (and I thing that lack of gcc 
integration is the strongest difficulty). But, now, imagine that 
you present D in front of a bunch of hardened C++ programmers and 
you have to explain those already skeptikal people that thes 
should not scream when they see Andrey's originally posted code. 
It is not also about D's own way, D still has to make some 
compromises to be accepted. In 10 years, it will be, maybe, the 
reference. IT IS NOT TODAY.

2. That file/module could be really huge. Several succesive 
programmers working on the same file/module could be of various 
expertise levels and not aware of such subtleties. Refactoring 
means also moving a lot of code around and you will find yourself 
needed to go back to that file where the code was originally 
defined and modify the "private" into "package" if you still want 
your code to compile. As a rule, during refactoring, it is a bad 
thing to touch (or be needed to touch) other code than the one 
you are messing up with, be in the same source file or no.
Jan 21 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 14:06:49 UTC, eles wrote:

 On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:

 On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:

 On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright 
 wrote:

 On 1/18/2013 2:16 PM, Andrey wrote:




 What would be the point ? You'll have the implementation and 
 the function definition under the nose anyway as it is in the 
 same file.

 If something should be private from your code, what is your 
 code doing is the same module ?


 1. Quoting Andrey's original post (3rd on this thread):

 "So, when you observe this situation, it becomes really hard to
 pursue fully fledged commercial development with D."

 So, if you think that D is so string that it allows itself such 
 ingenuities that makes C++ programmers giving it a try to 
 scream away from D, then fine. D already has difficulties in 
 being accepted by corporations (and I thing that lack of gcc 
 integration is the strongest difficulty). But, now, imagine 
 that you present D in front of a bunch of hardened C++ 
 programmers and you have to explain those already skeptikal 
 people that thes should not scream when they see Andrey's 
 originally posted code. It is not also about D's own way, D 
 still has to make some compromises to be accepted. In 10 years, 
 it will be, maybe, the reference. IT IS NOT TODAY.


I don't really understand the logic here. That seems very 
confused to me.


 2. That file/module could be really huge. Several succesive 
 programmers working on the same file/module could be of various 
 expertise levels and not aware of such subtleties. Refactoring 
 means also moving a lot of code around and you will find 
 yourself needed to go back to that file where the code was 
 originally defined and modify the "private" into "package" if 
 you still want your code to compile. As a rule, during 
 refactoring, it is a bad thing to touch (or be needed to touch) 
 other code than the one you are messing up with, be in the same 
 source file or no.


That may happen. If it happen you'll have trouble; Actually 
enough trouble that I'm pretty sure that this private things will 
not be of any priority to your eyes.

And your point around refactoring is kind of moot, because if you 
refactor big a module into smaller one, you are, by definition 
refactoring that module. And the code affected by the private 
thing IS, by definition of private, in that module. No need to 
mess around with other code.

Some approach have been proposed to be able to refactor a module 
into a package, and that is probably a much more interesting way 
to go, as it solve a much broader range of issues.
Jan 21 2013
parent reply "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 14:29:32 UTC, deadalnix wrote:

 On Monday, 21 January 2013 at 14:06:49 UTC, eles wrote:

 On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:

 On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:

 On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright 
 wrote:

 On 1/18/2013 2:16 PM, Andrey wrote:




 What would be the point ? You'll have the implementation and 
 the function definition under the nose anyway as it is in the 
 same file.

 If something should be private from your code, what is your 
 code doing is the same module ?


 1. Quoting Andrey's original post (3rd on this thread):


 I don't really understand the logic here. That seems very 
 confused to me.


Just think about Andrey as being such C++ programmer that gave D 
a try and ran away. Why? Because it was puzzled to see that, 
despit being "private", the attribute is "public" (well, to some 
degree).

His first thought was that D should not be used into production 
environment.

OK? Andrey is one C++ programmer that you lose, you cannot 
convert him to D. Does D afford that?
Jan 21 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 14:34:50 UTC, eles wrote:

 Just think about Andrey as being such C++ programmer that gave 
 D a try and ran away. Why? Because it was puzzled to see that, 
 despit being "private", the attribute is "public" (well, to 
 some degree).

 His first thought was that D should not be used into production 
 environment.

 OK? Andrey is one C++ programmer that you lose, you cannot 
 convert him to D. Does D afford that?


That is completely backward. D and C++ have very different needs 
in terms of visibility of symbols, especially if you think about 
the fact that namespace introduction in C++ come after visibility 
qualifiers. D have a module system that make the requirement very 
different.

Every time you change something people are used too, they get 
scared. Someone scared by a change they don't understand will not 
use D anyway. Given another behavior of private more C++ 
compliant, it is very likely that Andrey would have find 
something else to be scared of.
Jan 21 2013
parent reply "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 14:46:52 UTC, deadalnix wrote:

 On Monday, 21 January 2013 at 14:34:50 UTC, eles wrote:
 Every time you change something people are used too, they get 
 scared. Someone scared by a change they don't understand will 
 not use D anyway. Given another behavior of private more C++ 
 compliant, it is very likely that Andrey would have find 
 something else to be scared of.


The point is some changes are useless, to not say they are bad. 
If D modified the "private", I think better decisions would have 
been to rename it too (ie. into "D_special_meaning_of_private")

Do not forget that D still needs to attract people from the C/C++ 
world. If you adress to them, at least be nice to them and do not 
scare them from the begining.

Also, C++ done *some* things right and those should be kept. At 
least, when correcting the bad things in C++, do not mess them 
more than it is necessary.

For me, for example, it is puzzling to see that the "private" 
meaning was modified, but kept the same name. I knew that 
Andrey's code is legal into D, still I find it unnatural and I 
understand his reaction. I had the same reaction.

In order to demonstrate privateness in a Hello World before of 
students, do I really need to go with TWO files?
Jan 21 2013
parent "mist" <none none.none> writes:
C++ does not have UFCS. It does matter.
Jan 21 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/13 7:49 AM, eles wrote:

 Why make access protection dependent of how the source code is spread
 into files?


For the simple reason that files are the de facto unit of encapsulation 
for viewing and editing.

Andrei
Jan 21 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/18/13 3:21 PM, bearophile wrote:

 Do you know why Walter is currently working on this stuff? Is this an
 optimization? If it's an optimization, do you know why it is more
 important than implementing "scope" or an unpacking syntax for tuples?

 https://github.com/D-Programming-Language/dmd/commit/fc4462b95307d5c31d4c0bcf830faf6686b0feae


 If that's an optimization, and most people are going to use LDC or GDC
 in future, why is Walter working on that stuff?

 Also do you know why Walter is working still on D1? Isn't D1 code going
 to be deleted, to have a purely D2 code on GitHub?

 Currently there are 118 open pull requests:
 https://github.com/D-Programming-Language/dmd/pulls

 Maybe (probably) not every one of them is good, but among them there is
 lot of stuff I've asked in bug reports and enhancement requests, thanks
 to Hara and others. If 50% of the biggest pull requests of those 118
 gets pulled, the D language will feel almost as a new thing.

 Also, I don't agree a lot about the "fog of war" theory by Walter. I
 think a development plan should be discussed, written down, and then
 followed (and dynamically fixed, when necessary). Building a new system
 language has a high risk of failure, but there's no need to also shot D
 in the feet on purpose.


I agree with the sentiment but let's not use oblique rhetorical 
questions to drive a point.

Allow me to extend again the invitation to participate to the 
development by contributing code. Put another way: Do you know why 
bearophile asks rhetorical questions instead of pushing to github?


Andrei
Jan 18 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 18, 2013 at 05:43:16PM -0500, Andrei Alexandrescu wrote:

 On 1/18/13 3:21 PM, bearophile wrote:


[...]

 I agree with the sentiment but let's not use oblique rhetorical
 questions to drive a point.
 
 Allow me to extend again the invitation to participate to the
 development by contributing code. Put another way: Do you know why
 bearophile asks rhetorical questions instead of pushing to github?


[...]

I have to say, after my initial euphoria upon discovering just how
awesome D is, I did stumble across a number of very frustrating issues
in the current implementation. I also found the slow rate of bug fixes
rather frustrating (from my biased POV, of course -- I was looking for
*my* bugs to be fixed, regardless of how many other bugs were being
fixed). So I thought, I have three choices: (1) give up on D and go back
to C++ (that was a pretty quick "no"), (2) post vitriol to the mailing
list, increasing the likelihood of offending the devs and reducing the
likelihood of my bugs getting fixed, or (3) fix the bug myself and
submit a pull request to show 'em how it's done (greatly increases the
likelihood of my bugs getting fixed, and faster at that).

I concluded that (3) was the most profitable approach, and that if
enough others arrive at the same conclusion, we will stand a good chance
of actually improving the situation. I'm a big fan of showing others how
to do things better when I see something less than satisfactory.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things
you wish you hadn't.
Jan 18 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 I agree with the sentiment but let's not use oblique rhetorical 
 questions to drive a point.


Those questions aren't fully rhetorical because I don't know 
those answers and I'd like to know. I don't know why Walter 
thinks removing bit intrisics is more urgent than working on 
designing/implementing "scope" or similar things, I don't know 
why D1 development isn't discontinued yet (and I don't know why 
the pull requests are merged according to a mostly LIFO pattern), 
and so on.



 Allow me to extend again the invitation to participate to the 
 development by contributing code.


Given the many factors in this equation, I think my time is 
better spent elsewhere, teaching D to people in Real Life, 
showing D solutions to people in sites (like: 
reddit.com/r/dailyprogrammer/ ), writing D examples/tutorials in 
various sites, etc, because there's no point in creating a 
language that no one knows about.

This page shows many missing D programs, I invite people here to 
fill some of those blanks:

http://rosettacode.org/wiki/Reports:Tasks_not_implemented_in_D

Bye,
bearophile
Jan 19 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
[=E2=80=A6]

 If that's an optimization, and most people are going to use LDC=20
 or GDC in future, why is Walter working on that stuff?


Working on a separate backend is fine if that is what people want to do.
I think though that unless D sits on GCC or LLVM it will get no
traction.  D has been going for 10 years now and is still a tiny niche
language that large organization don't consider given C and C++. Riding
on GCC and LLVM and being everywhere that gcc, g++ and clang are is a
step to allowing D to be used by people not in this mailing list related
community.

This D development community should put effort into making GDC and LDC
the primary D tools, ensuring that the latest D version is always
shipped on Mac OS X (macports, brew, DMG installer,=E2=80=A6) and in every =
Linux
distro that has market presence =C2=AD=E2=80=93 which effectively means Deb=
ian and
Fedora since all distros with presence build on them =E2=80=93 as well as
Windows (which bizarrely remains the major platform for software
development).

This is not something it has to be left to Walter to do unless D is to
remain a 1-man band, in which case it will never get real traction: any
toolchain which even remotely looks like a one-man band has no chance of
getting real traction.


 Also do you know why Walter is working still on D1? Isn't D1 code=20
 going to be deleted, to have a purely D2 code on GitHub?


Having declared D1 dead as of 2012-12-31 and issued a final release, any
and all work on D1 is counterproductive. But on the other hand Walter is
not an employee of the D development team (**).


 Currently there are 118 open pull requests:
 https://github.com/D-Programming-Language/dmd/pulls
=20
 Maybe (probably) not every one of them is good, but among them=20
 there is lot of stuff I've asked in bug reports and enhancement=20
 requests, thanks to Hara and others. If 50% of the biggest pull=20
 requests of those 118 gets pulled, the D language will feel=20
 almost as a new thing.


Anyone and everyone can work on these bug reports. The problem is that D
need a few people, not just one, to be paid in some way to work of the D
system.  Whilst all effort is basically on a volunteer basis then the
project will just trundle along going nowhere.

D needs some big users who put resource into development either in terms
of cash to get contractors to do work, or by putting staff members onto
the project for some or all of their time. Only with commitment of
resource from user organizations will the project actually go anywhere.


 Also, I don't agree a lot about the "fog of war" theory by=20
 Walter. I think a development plan should be discussed, written=20
 down, and then followed (and dynamically fixed, when necessary).=20
 Building a new system language has a high risk of failure, but=20
 there's no need to also shot D in the feet on purpose.


I am not sure what this theory is but it sounds akin to "let the product
be an emergent property of chaotic behaviour".

It strikes me that the DConf 2013 shouldn't be just a friendly get
together to share some D knowledge. This conference should be the
meeting that kicks off the programme of D's ascendency into the realms
of actually being used seriously.

1.  It needs to be clear that D is no longer Walter's baby/toy/=E2=80=A6 th=
at
only he can work on.

2. There needs to be a roadmap of creating a language spec, a test suite
for all the features, and a programme for any future features and how
they will be implemented.

3. A marketing programme to get D known about and used. This hinges on
successful projects so an objective would be to get an up to date list
of products, both small and large, that rely on D and why they use D and
not C, C++, Java, Scala, etc.

4. Networking to find organizations who may be able to put real resource
into the D infrastructure and libraries.

5. Find a big organizational champion (*).

If the D world is after DConf 2013 fundamentally the same as the D world
has been before DConf 2013 then the project is going nowhere and the
only recourse will be to fighting with C++, Go, Rust, Clay, etc.  DConf
2013 has to be treated as a watershed moving D from the 10 year cycle of
creation into the infinite cycle of use.

(*) Groovy managed to use a 6 year rather than 10 cycle to real
usability, but it was only when SpringSource bought G2One and started
putting resource into Groovy that it really took off. With Canoo backing
it and one or two USA consultancies, it rapidly became the dynamic
language of choice and actual use on the JVM.  The similarities between
D evolution and Groovy evolution are quite interesting (**). Groovy has
made the jump to organizational respectability. D needs to do the same.

(**) Groovy had a development team crisis/explosion/implosion not
dissimilar to the Tango/Phobos situation. But the Groovy team moved on.
It seems the D situation has become history and people have moved on.
The crucial difference is that the Groovy team started looking outwards
from the language as much as looking at the development of the language.
The D community needs to look out towards use of the language out there
rather than just the language infrastructure. Vibe.d is something
Twitter and G+ should be full of.  Should there be effort of graphics
bindings? Network bindings, etc. But what are the applications using
these? That is where the real traction stems from.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 19 2013
next sibling parent reply "Freddie Chopin" <freddie_chopin op.pl> writes:
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:

 This D development community should put effort into making GDC 
 and LDC
 the primary D tools


For example Go (developed since 2009) is already integrated with 
GCC (since 4.6.3 so for some time)... I know that it's google and 
stuff, but I tend to agree with this thread on general - GCC 
support would possibly open D for a market really hungry for a 
new and powerful language - embedded (microcontrollers, not 
smartphones with Linux). And there's no competition - just C/C++ 
(;

4\/3!!
Jan 19 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 19.01.2013 14:19, schrieb Freddie Chopin:

 On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:

 This D development community should put effort into making GDC and LDC
 the primary D tools


 For example Go (developed since 2009) is already integrated with GCC
 (since 4.6.3 so for some time)... I know that it's google and stuff, but
 I tend to agree with this thread on general - GCC support would possibly
 open D for a market really hungry for a new and powerful language -
 embedded (microcontrollers, not smartphones with Linux). And there's no
 competition - just C/C++ (;

 4\/3!!


Yes, but you forget that one of the GCC developers is also part of the 
Go developers team.

--
Paulo
Jan 19 2013
prev sibling next sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:

 On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
 […]
 (*) Groovy managed to use a 6 year rather than 10 cycle to real
 usability, but it was only when SpringSource bought G2One and 
 started
 putting resource into Groovy that it really took off. With 
 Canoo backing
 it and one or two USA consultancies, it rapidly became the 
 dynamic
 language of choice and actual use on the JVM.  The similarities 
 between
 D evolution and Groovy evolution are quite interesting (**). 
 Groovy has
 made the jump to organizational respectability. D needs to do 
 the same.


This opinionated piece of opinion agrees:

"What about D as a replacement for C?

It's not there for the same reasons as Go. It's possible that 
someday it will be suitable, but I'm less optimistic about it 
strictly from a momentum perspective, it doesn't have a big 
backer like Google and doesn't seem to be growing very rapidly. 
But perhaps it will get there someday."

http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html
Jan 19 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 19 January 2013 at 18:43:45 UTC, SomeDude wrote:

 On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder 
 wrote:

 On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
 […]
 (*) Groovy managed to use a 6 year rather than 10 cycle to real
 usability, but it was only when SpringSource bought G2One and 
 started
 putting resource into Groovy that it really took off. With 
 Canoo backing
 it and one or two USA consultancies, it rapidly became the 
 dynamic
 language of choice and actual use on the JVM.  The 
 similarities between
 D evolution and Groovy evolution are quite interesting (**). 
 Groovy has
 made the jump to organizational respectability. D needs to do 
 the same.




Yes. I remember looking at Groovy around 2000 timeframe and not 
giving
too much consideration.

Back then Jacl had much more support, and IBM was pushing 
Beanshell and
Jacl.

Funny how it turned out to be.


 This opinionated piece of opinion agrees:

 "What about D as a replacement for C?

 It's not there for the same reasons as Go. It's possible that 
 someday it will be suitable, but I'm less optimistic about it 
 strictly from a momentum perspective, it doesn't have a big 
 backer like Google and doesn't seem to be growing very rapidly. 
 But perhaps it will get there someday."

 http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html


Go might eventually succeed in replacing C, Google just needs to 
make Go a first class language for Android development.

--
Paulo
Jan 21 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 08:34:49 UTC, Paulo Pinto wrote:

 Go might eventually succeed in replacing C, Google just needs 
 to make Go a first class language for Android development.


Go has no chance to replace C as too many low level features are 
missing. But yes, it can become pretty big !
Jan 21 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 21 January 2013 at 10:42:17 UTC, deadalnix wrote:

 On Monday, 21 January 2013 at 08:34:49 UTC, Paulo Pinto wrote:

 Go might eventually succeed in replacing C, Google just needs 
 to make Go a first class language for Android development.


 Go has no chance to replace C as too many low level features 
 are missing. But yes, it can become pretty big !


That is debatable, as most things are possible via unsafe + 
syscall.

Already proven in another GC enabled system languages.

That the industry needs to have them shoved by their throat like 
in Java's case, that is another matter.

--
Paulo
Jan 21 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-01-21 at 09:34 +0100, Paulo Pinto wrote:
[=E2=80=A6]

 Yes. I remember looking at Groovy around 2000 timeframe and not=20
 giving
 too much consideration.


[=E2=80=A6]

Just to ensure the history as determined by Google search is at least
fairly reasonable, Groovy started in mid to late 2003 had a hiccup mid
2004, and really got moving in late 2004.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 21 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 21 January 2013 at 12:31:16 UTC, Russel Winder wrote:

 On Mon, 2013-01-21 at 09:34 +0100, Paulo Pinto wrote:
 […]

 Yes. I remember looking at Groovy around 2000 timeframe and 
 not giving
 too much consideration.


 […]

 Just to ensure the history as determined by Google search is at 
 least
 fairly reasonable, Groovy started in mid to late 2003 had a 
 hiccup mid
 2004, and really got moving in late 2004.


Yeah, it might have been 2003.

I have written "around 2000", because I wasn't sure when exactly.

This was the time when Groovy was supposed to be made part of 
Java.

Ok, it was JSR-241, http://www.jcp.org/en/jsr/detail?id=241

I got the date wrong by 4 years it seems.

--
Paulo
Jan 21 2013
prev sibling parent "eles" <eles eles.com> writes:
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:

 On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
 […]
 This D development community should put effort into making GDC 
 and LDC
 the primary D tools, ensuring that the latest D version is 
 always


I second that.
Jan 21 2013