Dear,

My topic is a kick in the anthill. I hope this will help D to think on his problems.

D exist since 1999, if we look behind, what is done?
We have :
- a huge cemetery of D project
- no D killer application
- miss the goal what to do to improve D experience
- each new D release your application is broken and often with
some D compiler bugs
With around 15 years of works we are at same state as the
beginning.
What to do:
  - Stop to add new feature in D (new annotation or whatever is
not an urgent needs)
  - Get a compiler and a language stable
  - When this is done work on some free (libre) framework in some
specific fields
     * grid computing (sub-field: data-computing)
     * web-server
     * graphics computing (sub-field: gui )
And not more, not to disperse …


From the beginning D had a bad start (1999-200X):
- dmd compiler was not totally open.
- we got a fight on standard library phobos - tango
With this language started to get a bad publicity
- d2 is come with a new syntax which kill lot of project: -> http://www.dsource.org/
survivor are: phobos: derelict, gtkd all others are dead

We get for years deprecated module: xml, json, mmfile

When we introduce a new feature we release it with a partial use:
- @safe often is not used as is not yet implemented into phobos
- range even the basic io as ByLine which implement range can't work with std.range.takeOne as is not an Input Range. While a basic function such as takeOne do not really need to use save method to work a forward range is enough.

So we adding feature and going forward without consolidate the previous works.
That is like you give to a children a gift, barely opened you give another gift.

Currently D project are:
- not open project to make money (no code shared)
- personal code ( which fit only one point of view )

Really I hope to see D3 with a clean model and a stable language. Do not release it as a toy like was done for D1 and D2.
Release D3 with much ah possible no compiler bug and a well implemented standard library. We have get enough experience to do it.


Why we do not create a useful D programming environment as is done is java, python, ruby.

On 19/12/2014 1:38 a.m., bioinfornatics wrote:
> Dear,
>
> My topic is a kick in the anthill. I hope this will help D to think on
> his problems.
>
> D exist since 1999, if we look behind, what is done?
> We have :
> - a huge cemetery of D project
> - no D killer application
> - miss the goal what to do to improve D experience
> - each new D release your application is broken and often with
> some D compiler bugs
> With around 15 years of works we are at same state as the
> beginning.
> What to do:
>    - Stop to add new feature in D (new annotation or whatever is
> not an urgent needs)
>    - Get a compiler and a language stable
>    - When this is done work on some free (libre) framework in some
> specific fields
>       * grid computing (sub-field: data-computing)
>       * web-server
>       * graphics computing (sub-field: gui )
> And not more, not to disperse …
>
>
>  From the beginning D had a bad start (1999-200X):
> - dmd compiler was not totally open.
> - we got a fight on standard library phobos - tango
> With this language started to get a bad publicity
> - d2 is come with a new syntax which kill lot of project: ->
> http://www.dsource.org/
> survivor are: phobos: derelict, gtkd all others are dead
>
> We get for years deprecated module: xml, json, mmfile
>
> When we introduce a new feature we release it with a partial use:
> - @safe often is not used as is not yet implemented into phobos
> - range even the basic io as ByLine which implement range can't work
> with std.range.takeOne as is not an Input Range. While a basic function
> such as takeOne do not really need to use save method to work a forward
> range is enough.
>
> So we adding feature and going forward without consolidate the previous
> works.
> That is like you give to a children a gift, barely opened you give
> another gift.
>
> Currently D project are:
> - not open project to make money (no code shared)
> - personal code ( which fit only one point of view )
>
> Really I hope to see D3 with a clean model and a stable language. Do not
> release it as a toy like was done for D1 and D2.
> Release D3 with much ah possible no compiler bug and a well implemented
> standard library. We have get enough experience to do it.
>
>
> Why we do not create a useful D programming environment as is done is
> java, python, ruby.

I'm in agreement that we need to start freezing the language.
E.g. in the next 6 months we will get x done. And no new features other then those chosen will be added.

One thing I will say without going full raging, we as a community need to work together for scoping of reusable projects that we all can agree to.
By scoping down significantly we won't have massive big code bases that are both a library and framework for a number of uses all rolled into one.
We have dub, which has sub packages its not acceptable to not do this.

D as a language is easy to sell to an education institute as a first language. I've done it.
Now we really should focus on getting started and cook book related tutorials on the main site.
Ali's book is amazing, but we also need to get e.g. ApplyYourDLang or something along those lines properly going and having them both combined as part of the main site. Maybe even with a nice big flashy banner at the top of the page saying go there to get started.

about Dub, I have another view.
This build system was created for end user to get a missing library when they want their killer application. As is done with PyPI or gem.
Dub to me is not a builder for developer and even less for an OS. dub install software in home user "a la" windows style. I prefer to use makefile at least with it I can to write a clean builder with respect of standard OS specification. For this I tool makefile template from makefileForD hosted on github.
But we have already give a lot of talk on this, so we could discuss on it into a separate thread.

On Thursday, 18 December 2014 at 13:16:11 UTC, bioinfornatics wrote:
> about Dub, I have another view.
> This build system was created for end user to get a missing library when they want their killer application. As is done with PyPI or gem.

Build system is never for end users but always for developers. Dub is 100% superior to gems/pip because it decoupled application dependencies and development dependencies. End user gets applications built with dub and sees no traces of it, neither he needs to be aware of any of code.dlang.org packages - this is the huge benefit of compiled languages and specifically dub.

Contrary to that gem/pip force me to install loads of stuff that is not handled by system package manager and does not inter-operate with the rest of the OS. It sucks, though somewhat inevitable by design of interpreted languages.

> Dub to me is not a builder for developer and even less for an OS. dub install software in home user "a la" windows style.

Bullshit. No, BULLSHIT.

Users should never see dub or even know of its existence. It is only for developers and packagers. Stop considering developers users and you will be good.

On Thursday, 18 December 2014 at 14:52:27 UTC, Dicebot wrote:
> [...]

Stop reading my mind !

I don't think it's fair to lump D1 into the 15 years, since D2 went in a different direction and broke compatibility.  In any case, ruby was around for a decade before it took off, and it didn't have to deal with a version break and all the stuff that went with it.

To answer your question, here's my guess as to the plan:

- Make D efficient, that already rules out competition from ruby, python, and all the interpreted languages.
- Add a bunch of features that are either C++ done better or pulled from the more dynamic languages but done at compile-time, ie CTFE and mixins.
- Hope commercial support comes along and cleans up a bunch of bugs and clashing features.

Commercial support might consist of companies contributing to the D core, a mob of users putting up bounties for bugs they want fixed or features they'd like, or a language vendor closing up parts of the D core and selling a paid version.

The hope is that some commercial entities like the first two aspects of D so much that they think it's worthwhile to invest in fixing and polishing it up.  Otherwise, D has no hope of becoming a "used" language.

On Thursday, 18 December 2014 at 17:13:08 UTC, Joakim wrote:
> - Hope commercial support comes along and cleans up a bunch of bugs and clashing features.
>
> Commercial support might consist of companies contributing to the D core, a mob of users putting up bounties for bugs they want fixed or features they'd like, or a language vendor closing up parts of the D core and selling a paid version.
>
> The hope is that some commercial entities like the first two aspects of D so much that they think it's worthwhile to invest in fixing and polishing it up.  Otherwise, D has no hope of becoming a "used" language.

IMHO commercial support is now what D needs most badly.

More complex creatures may take longer to mature than simpler ones.  At the age of five, an infant is a much less impressive creature than a dog of the same age.  (And one might sometimes feel the same way also when it reaches the age of 15 ;)  Social institutions have organic traits too, so the metaphor may have some application.

Sometimes in the growth of a business there are some limiting factors that simply need to be worked through, and there may be no viable short-cut.  It's easy to become frustrated if one makes comparisons, but it may be that the situations simply are not comparable because the problems faced are different.

The growth of a business also often depends on external factors. It just trundles along for years, and suddenly the stars align, and there is explosive growth.  People attribute overnight success to overnight causal factors, but that is rarely how it works beyond the most superficial level of understanding.  When the stars align, it isn't just one thing, but rather a whole bunch of often slow but powerful developments coming together.

I am a newcomer to D, and by far not an expert in computer science, processor and memory tends etc.  But perhaps it may be the case that changing cost conditions dramatically influence the kinds of tools that best suit the most pressing problems.  These problems too may be becoming more ambitious in terms of magnitude.  For a long time in the business world, processing power was essentially a free resource (and often RAM was too).  Gamers had more powerful machines, even compared sometimes to those used in the financial sector.  But people do respond to relative prices, and when something is cheap they find ways to use lots of it although it does take some time.

Ie it was once perhaps true as a simple generalisation for quite some time that much activity was I/O bound, and so the speed of interpreted languages with a C back-end like Python simply didn't matter.  It may perhaps also be true that the world of the future will be quite different.

That is why I am interested in D - it seems to be the only viable option that seems likely to perform well whilst meeting a certain set of constraints that I believe will be important for me.  Sometimes I get things wrong, but often I tend to identify changes in trends early enough, and it may be that others come to similar conclusions in time.

Its adoption at Facebook is intriguing.  The temptation is to dismiss it and suggest that they have a lot of resources for R&D, and a handsome salary for Dr Andreiscu is a rounding error compared to the productivity of a talented person, and if he wants to program in VBA then if it works, why fight him!  Also, to say that Facebook has some extraordinary challenges that are not representative of those faced by other business applications, and that are not ever representative to be so.

But I have a different perspective, and I think perhaps the kinds of challenges faced by Facebook may be more like the leading edge of what many more people may be facing in the years to come. William Gibson's "The future is here already, but not evenly distributed".

In any case, there is little point speculating about the future, and certainly none throwing up one's hands in woe at what seems to be slow adoption.  (If one compares oneself to the languages that have been most quickly adopted, one will always feel bad because that is the nature of comparison).

Strife is good, if one responds to it in a creative fashion.  One also should not be limited by what seem to be immediate constraints of lacking resources - budget, people etc.  First of all one comes up with a vision and plan to execute it, and somehow magically the path to get there emerges slowly out of the fog.  The amounts of money at stake to me really seem to be quite small in the bigger picture of things.  I cannot personally help today, but that may change in a few years, and I will if I can then.

I don't claim to have great technical expertise, but it does seem to me that - contrary to what might be inferred from the original post - D has made very substantial progress since it was launched.  The years have not been wasted, because it is a much better language that has kind of discovered further sources of beauty that were unexpected perhaps even by its creators.

I personally think the following would be very helpful

- better reference documentation.  I don't believe I lack the ability generally to figure things out, but the dlang.org library reference is far from being utterly clear if you don't start from a place of understanding the language and its concepts.  once you get the spirit of it, it all makes sense, but modern people don't tend to be distinguished by their grit and many will give up first.

- better worked examples.  python is outstanding for this.  you can figure out how to do anything by looking at someone else's example.  of course there isn't presently the support for this, and I recognize that one attracts a different kind of person when it becomes easy to learn a language.  but such is the price of maturity.

- agree about commercial support.  if you are using it at an enterprise level you want to know you can call someone and get it fixed because the price of not doing so may be incalculably high, and people don't necessarily trust themselves to be able to fix it.  entrepreneurs don't like uncertainty outside their home ground that they cannot pin down.

- some degree of strategic planning as regards use cases.  if someone owned the product they would be very interested and inquisitive about the nitty gritty details to see who is using it in different domains, why (and why don't people go for the competition), what the language does really well, and whether the problems perceived to be the biggest ones actually align with what end-users find important.

- also a degree of relating D's power to emerging trends in different sectors and some writing up of stories, case studies, interviews with end users.  this is a kind of community-building task and requires very different skills and emotional makeup to other aspects.  the obvious areas I might think about would be the financial sector (hedge funds, investment banks, financial exchanges, platforms etc), machine learning media analysis problems, economic analysis (much larger data sets than economists are used to, and the don't have the right tools for it), bioinformatics, processing logs for the internet of things, etc.

if you were running a business you would want there to be somebody you could call if you were a practitioner in bioinformatics and wanted to know the experience of people using D in that area.  I appreciate that's highly unrealistic for the time being, but it may be worth bearing in mind as something helpful for the distant future.

- finally, a bit better organisation.  Andrei spoke about needing more lieutenants.  Of course it's a no-brainer that he shouldn't be spending his time designing a conference web site.  But perhaps you could make it clearer by adding a section on the D wiki front page: "Interested in supporting D?  Here's how you can help".  It could then take you to a page that breaks down different areas to work on and tasks to be accomplished on each of them.  Then someone with time and inclination can see "oh - it would be great to have someone promote this event on Reddit".  But as things stand, I imagine to a certain extent nobody knows what specifically they can do.

I am horribly disorganized, so I am not the right one here.


- and one could have a bit of patience and self-confidence.  having high standards and wanting to achieve excellence does not mean one cannot recognize one cannot get there overnight and that it is more a matter of taking steps in the right direction, sustained over time.  I liked Andrei's attitude of brutal honesty in this respect.

On 18/12/14 14:07, Rikki Cattermole via Digitalmars-d wrote:
> I'm in agreement that we need to start freezing the language.
> E.g. in the next 6 months we will get x done. And no new features other then
> those chosen will be added.

IMHO, it's important to demarcate well what is considered "done", but also to enthusiastically embrace breaking changes that improve the performance and reliability of the language.

Well-defined and well-kept promises for what is stable, what is in development, and what is in the roadmap, matter more than just freezing things.  The fact that "problem X will never be fixed because of backwards compatibility" can be just as demotivating to uptake (if not more so) than "feature Y may change in the next release".

<snip>> We have :
>> - a huge cemetery of D project

+ 1
>> What to do:
>>   - Stop to add new feature in D (new annotation or whatever is
>> not an urgent needs)

+1000.

But this is not the culture of the creators. They think adding features is fun.

Vic
blog.apakau.com - company built on top of D in Silicon Valley

<snip>