Encapsulating trust

Andrew Godfrey via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 2 09:24:05 PDT 2014


On Tuesday, 2 September 2014 at 13:15:02 UTC, Dicebot wrote:
> On Tuesday, 2 September 2014 at 08:24:42 UTC, ketmar via 
> Digitalmars-d wrote:
>> please note that i'm not trying to say that D developers doing
>> everything wrong nor that they are incompetent. D is great. 
>> but we can
>> make it even better. just stop buying "enterprise need 
>> stability" bs:
>> we have enough "enterprise-stable" languages already, let's 
>> make one
>> that is attractive to programmers.
>
> I am by all means regular advocate of changes but your are 
> pushing it to other radically harmful attitude. There is a huge 
> difference between maintaining own set of patches that work for 
> cases you personally use language for and maintaining feature 
> constantly in the publicly available upstream. Things break in 
> most unexpected ways when exposes to even small / medium user 
> bases, we have it all the time.
>
> For example, this specific syntax is absolutely guaranteed to 
> result in weird issues because it is ambiguous with already 
> existing one (that applies attributes to declarations). In the 
> end it gives you _nothing_. Saving two characters for already 
> short idiom that is not even supposed to be easy to use is just 
> a joke. There is simply no way something as trivial as that is 
> going to pull its weight.
>
> There is a limited amount of maintenance effort we can invest 
> into adding new stuff to language and it needs to be used 
> wisely.

Something I'm feeling as a newcomer to D reading these threads, 
is that the community has already thought of a number of 
guidelines for Phobos development, but they are buried in the 
forum. I also saw one which is controversial - the idea that 
embedded systems programmers should be able to use some subset of 
Phobos without bloating their executable. I'd have no idea 
whether we are trying to maintain that property of Phobos where 
it already exists, or ignore it. Similarly, there are a lot of 
diverse goals/use cases people have in mind - the std.logger 
thread has some.

It feels like Phobos has a good amount of 'breadth'' but could do 
with more "depth". Have we already tried some exercises which 
would flesh out more "Phobos requirements" (I.e. That we aspire 
to for existing modules and require for new ones?)


More information about the Digitalmars-d mailing list