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.

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

On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
[…]
> If that's an optimization, and most people are going to use LDC 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,…) and in every Linux
distro that has market presence ­– which effectively means Debian and
Fedora since all distros with presence build on them – 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 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
> 
> 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.

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 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 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/… that 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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

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

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!!

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();
}
------------------------
# dmd main.d -c
# dmd mylib.d -c
# gcc main.o mylib.o -lrt -lphobos2 -lpthread
# ./a.out
?

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

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.

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

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