August 03, 2010
dsimcha, el  3 de agosto a las 02:34 me escribiste:
> == Quote from Walter Bright (newshound2@digitalmars.com)'s article
> > Leandro Lucarella wrote:
> > > For me the problem with D is dependency control. You don't know what symbol come from which module. Yes, I know you can do explicit dependencies in D with static and selective imports, the same you can do the inverse in other languages with the import module.*-like syntax, but I think D got the default wrong, I prefer explicit by default.
> > It's a reasonable point of view, but the motivating thing for me here is making it easy for people to write quick&dirty programs.
> 
> I truly appreciate D's stance that both quick and dirty code and more heavily engineered code need to be supported.  My biggest gripe about languages like Java is that they force so much "proper style" on me that I can't just "make it work" before I "make it right".
> 
> I love how, using D, I can go from a quick and dirty prototype to a "real" program/library without having to switch languages and completely rewrite every function.  In bioinformatics research, we do TONS of prototyping/small scripts and only a small fraction of these prototypes are fleshed out into serious programs. I suspect there are other fields like this, where you just want a quick prototype up front, but it may or may not be converted into a proper program depending on how the prototype works. Being able to do both in the same language is just an outstanding feature.
> 
> Second, being able to write quick/dirty programs lowers the barrier to entry for trying out the language.  My first few D programs, back when D was a mere curiosity for me, were things like programs that counted the amount of times each DNA nucleotide occurred in a sequence.  Of course this is trivial, but if the language treated me like a naughty child instead of a consenting adult, I would likely not have stuck with it.
> 
> Third, often only part of a program needs to be well-engineered (the core algorithms that will likely be around awhile) and the rest is just some quick and dirty glue to feed data to the core algorithms, and will likely change in relatively short order.  The well-factored core algorithms plus quick and dirty glue style is very often how I program in practice.

I agree completely, I hate Java and every programming language where
a readable hello world takes more than 3 SLOC. But I insist I'm talking
about defaults. If D would accept an import module.* syntax, you could
still do quick&dirty without much hassle, but make the dirtyness
explicit.

The argument about having technical problems to implement this model seems like a good reason (but I guess it should be doable though, at some point you have to know all the symbols that are present in a source file, and where they came from).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
<original> [Penis Uptime: 2days 13hrs 59mins 35secs]
<Yapa> viagra? :)
<original> yea, 20 pills
August 03, 2010
Walter, I suggest you to stop right now to say how much good D module system is and how much good your design is, etc, and to start looking for the problems/holes instead. In my language there is a proverb that says something like "Who praises himself a lot, covers himself with broth" or something similar ^_^ Keep looking for the *design* problems of the D module system, and try to fix them, instead of saying several times how much good D module system is.

Later,
bearophile
August 03, 2010
bearophile wrote:
> Walter, I suggest you to stop right now to say how much good D module system is and how much good your design is, etc, and to start looking for the problems/holes instead. In my language there is a proverb that says something like "Who praises himself a lot, covers himself with broth" or something similar ^_^ Keep looking for the *design* problems of the D module system, and try to fix them, instead of saying several times how much good D module system is.

I agree with the spirit. Getting in the state we unconditionally believe we got it right essentially prevents progress in the matter by halting the brain.

That being said, I recall you mentioned a couple of times in the past that D's modules have problems. Whenever you substantiated those claims, I found the arguments insufficient and ended up forgetting them. Are there some bugzilla reports (at the risk of repeating the same question)?


Andrei
August 03, 2010
On 2010-08-03 08:39, Andrei Alexandrescu wrote:
> bearophile wrote:
>> Walter, I suggest you to stop right now to say how much good D module
>> system is and how much good your design is, etc, and to start looking
>> for the problems/holes instead. In my language there is a proverb that
>> says something like "Who praises himself a lot, covers himself with
>> broth" or something similar ^_^ Keep looking for the *design* problems
>> of the D module system, and try to fix them, instead of saying several
>> times how much good D module system is.
>
> I agree with the spirit. Getting in the state we unconditionally believe
> we got it right essentially prevents progress in the matter by halting
> the brain.
>
> That being said, I recall you mentioned a couple of times in the past
> that D's modules have problems. Whenever you substantiated those claims,
> I found the arguments insufficient and ended up forgetting them. Are
> there some bugzilla reports (at the risk of repeating the same question)?
>
>
> Andrei

How about this one: http://d.puremagic.com/issues/show_bug.cgi?id=3108

-- 
/Jacob Carlborg
August 03, 2010
Jacob Carlborg wrote:
> On 2010-08-03 08:39, Andrei Alexandrescu wrote:
>> bearophile wrote:
>>> Walter, I suggest you to stop right now to say how much good D module
>>> system is and how much good your design is, etc, and to start looking
>>> for the problems/holes instead. In my language there is a proverb that
>>> says something like "Who praises himself a lot, covers himself with
>>> broth" or something similar ^_^ Keep looking for the *design* problems
>>> of the D module system, and try to fix them, instead of saying several
>>> times how much good D module system is.
>>
>> I agree with the spirit. Getting in the state we unconditionally believe
>> we got it right essentially prevents progress in the matter by halting
>> the brain.
>>
>> That being said, I recall you mentioned a couple of times in the past
>> that D's modules have problems. Whenever you substantiated those claims,
>> I found the arguments insufficient and ended up forgetting them. Are
>> there some bugzilla reports (at the risk of repeating the same question)?
>>
>>
>> Andrei
> 
> How about this one: http://d.puremagic.com/issues/show_bug.cgi?id=3108

Thanks. I voted it up! A cursory reading suggests that neither of those are matters of principles, only implementation issues. Is that right?

Andrei
August 03, 2010
On 2010-08-03 16:20, Andrei Alexandrescu wrote:
> Jacob Carlborg wrote:
>> On 2010-08-03 08:39, Andrei Alexandrescu wrote:
>>> bearophile wrote:
>>>> Walter, I suggest you to stop right now to say how much good D module
>>>> system is and how much good your design is, etc, and to start looking
>>>> for the problems/holes instead. In my language there is a proverb that
>>>> says something like "Who praises himself a lot, covers himself with
>>>> broth" or something similar ^_^ Keep looking for the *design* problems
>>>> of the D module system, and try to fix them, instead of saying several
>>>> times how much good D module system is.
>>>
>>> I agree with the spirit. Getting in the state we unconditionally believe
>>> we got it right essentially prevents progress in the matter by halting
>>> the brain.
>>>
>>> That being said, I recall you mentioned a couple of times in the past
>>> that D's modules have problems. Whenever you substantiated those claims,
>>> I found the arguments insufficient and ended up forgetting them. Are
>>> there some bugzilla reports (at the risk of repeating the same
>>> question)?
>>>
>>>
>>> Andrei
>>
>> How about this one: http://d.puremagic.com/issues/show_bug.cgi?id=3108
>
> Thanks. I voted it up! A cursory reading suggests that neither of those
> are matters of principles, only implementation issues. Is that right?
>
> Andrei

Am not sure about 1441 and I don't think 2529 is just an implementation issue.

-- 
/Jacob Carlborg
August 03, 2010
Jacob Carlborg wrote:
> Am not sure about 1441 and I don't think 2529 is just an implementation issue.

2529 is an implementation issue (and I don't agree with Don, I think his suggestion breaks encapsulation).
August 03, 2010
On 2010-08-03 21:28, Walter Bright wrote:
> Jacob Carlborg wrote:
>> Am not sure about 1441 and I don't think 2529 is just an
>> implementation issue.
>
> 2529 is an implementation issue (and I don't agree with Don, I think his
> suggestion breaks encapsulation).

I guess it depends on how one wants it to work, what the intended behavior is.

-- 
/Jacob Carlborg
August 04, 2010
Walter Bright wrote:
> Jacob Carlborg wrote:
>> Am not sure about 1441 and I don't think 2529 is just an implementation issue.
> 
> 2529 is an implementation issue (and I don't agree with Don, I think his suggestion breaks encapsulation).

Maybe it does. I think the bug should be closed as invalid, because the initial suggestion in the bug report is completely wrong: it would drive you to put low-level stuff in the root, and derived stuff in the leaves.
Implementing that suggestion would encourage poor design.

I believe D's current approach is what Java does?
August 04, 2010
Don wrote:
> Walter Bright wrote:
>> Jacob Carlborg wrote:
>>> Am not sure about 1441 and I don't think 2529 is just an implementation issue.
>>
>> 2529 is an implementation issue (and I don't agree with Don, I think his suggestion breaks encapsulation).
> 
> Maybe it does. I think the bug should be closed as invalid, because the initial suggestion in the bug report is completely wrong: it would drive you to put low-level stuff in the root, and derived stuff in the leaves.
> Implementing that suggestion would encourage poor design.

Please add this as a comment to the entry.

> I believe D's current approach is what Java does?

I'm not sure what Java does.