View mode: basic / threaded / horizontal-split · Log in · Help
January 18, 2013
Focus
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
January 18, 2013
Re: Focus
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
January 18, 2013
Re: Focus
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.
January 18, 2013
Re: Focus
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.
January 18, 2013
Re: Focus
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
January 18, 2013
Re: Focus
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.
January 19, 2013
Re: Focus
>> 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.
January 19, 2013
Re: Focus
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.
January 19, 2013
Re: Focus
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.
January 19, 2013
Re: Focus
> «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. :-)
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home