On Mon, 2016-01-25 at 21:31 +1300, Rikki Cattermole via Digitalmars-d- announce wrote:
> 
[…]
> Nope just no.
> I am only talking about newbies here.
> They will pick distributions of Python that are all encompassing.
> 
> http://winpython.github.io/#overview
> When it comes to newbies who come into programming seeing from all
> of
> their previous experience that things like GUI toolkit just comes
> with
> the language they just don't care if it was provided "extra" by a
> distribution or by the language itself. Only that they did exactly 0
> beyond importing and using it.

I'm afraid this whole view on the Python world is an old and long gone one. Even on Windows. Trust me on this I have been training people in Python since 2006. I have seen the whole scene change. Dramatically.

Oh and by the way, noone actually uses the one graphics system that comes as standard in Python. Everyone uses PyQt, wxPython, Phoenix, Gtk, direct bindings to other graphics libraries.

Pip is now core to everyone, even beginners use of Python. PyPI  may still have elements of crapness about it, but it is there, it is used, from Day 1 by most people learning Python.

> During my degree, the final programming class was Python.
> Everyone used WinPython except me. At the time pip didn't even work
> in
> it. Yes you heard me correct.

True, but how long ago was that? Python distributes pip in the Windows and OSX distributions. Package-based platforms tend to package it themselves. In fact all the commands are just entries into the library. Analogy: Dub is part of Phobos. If tehre is anything to add to Phobos it has to be Dub.

> When they had to use other code, they had no way or will to even try
> what wasn't part of it and so in their eyes what they had downloaded
> was
> Python. Because it really does appear to be Python.

Very true until four or five years ago. Now the whole situation is changed. Yes people go first to the standard library, but now people know to look in PyPI before writing their own.

> Especially with the IDE and QT being part of it...
> And right here is the problem. They expected and there it was.
> You will see this in every language. From Java to PHP.

Qt never has been and never will be a part of the Python standard library.

Ah you agree with me: The Java folk have a huge library, some if which is good, much of which is dross. But the real treasure of the Java Platform is Bintray and Maven Central. How can anyone contemplate doing Web stuff without Spring Hibernate, JavaEE, all of which are separate libraries not in teh distribution.

> […]
> 
> And I agree with you. As long as we have the bare bones in Phobos
> such
> as windowing and image library we can actually fight over GUI
> toolkits.
> Instead of repeatedly doing the same code over and over poorly.

I am afraid this is just displacement reasoning. The problem with graphics and D (other than GtkD, which is a very smooth operation) is that too many people have too many different ideas and assume everyone else will insist on doing their own thing. The problem is not Phobos here, the problem is the people not wanting to collaborate to create one or two things. Oh, that and resources. Whilst there is no money swashing around the D community (compare the Java, C++, Rust, Go, Python ones), there is little or no expectation of change. Given that all activity is volunteer activity, then what is happening will not change. And neither should it be forced to. On the other hand if a consensus could happen…

-- 
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 Mon, 2016-01-25 at 15:47 +0000, jmh530 via Digitalmars-d-announce wrote:
> 
[…]
> 
> I'm sympathetic to this. I still just download Anaconda and not bother with much else.

But that is the whole point I am trying to make. Anaconda (or Miniconda) is not a single massive monolithic library, it is a package management system for a Python milieu. You have a single command conda that allows you to get the bits you want. It is just pip on steroids, but with proper curation. Sadly they are still on Qt4, but…

The analogy to Miniconda in Python is Dub in D.

The analogy to Anaconda in Python is downloading the whole of the Dub repository before doing anything.

Actually Dub is more like Pip. Continuum Analytics put a lot of effort into managing their separate repository. Very little crap, lots of good stuff. But focused on data science.

-- 
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 Monday, 25 January 2016 at 16:49:36 UTC, Russel Winder wrote:
> What needs to be standardized? Data structure architecture. Already in Phobos. Cross platform Input/Output. Already in Phobos.

On Monday, 25 January 2016 at 16:49:36 UTC, Russel Winder wrote:
> Why isn't Dub the way forward on this? Why a centralized massive library that is hard to change and evolve, why not a far more lightweight management of contributions via a centralized mechanism, i.e. Dub.

I completely agree with Russel here. Kitchen-sink standard libraries are becoming legacy of old days and luxury of enterprise languages. It is the concept rather harmful to decentralized development nature of modern languages and very limited in flexibility. With a largely uncontrolled contribution flow D simply can't afford such approach.

There is quite a lot of missing in how dub works, how registry is organized and how it is featured from the dlang.org - in other words, in highlighting and endorsing valuable community projects. But that has nothing to do with Phobos.

Most important thing Phobos can do is to standardizes API's of various widespread concepts so that different independent libraries can work together cleanly. Good example would be std.experimental.logger - it doesn't provide much of "smart" logging functionality (like syslog or cyclic buffer) but allows to build one on top of Phobos bits in a way that you can be sure that any 2 loggers fetched from dub will be compatible with each other. This is the main deal.

On 25 Jan 2016 7:16 PM, "Russel Winder via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>
> On Mon, 2016-01-25 at 15:47 +0000, jmh530 via Digitalmars-d-announce wrote:
> >
> […]
> >
> > I'm sympathetic to this. I still just download Anaconda and not bother with much else.
>
> But that is the whole point I am trying to make. Anaconda (or Miniconda) is not a single massive monolithic library, it is a package management system for a Python milieu. You have a single command conda that allows you to get the bits you want. It is just pip on steroids, but with proper curation. Sadly they are still on Qt4, but…
>
> The analogy to Miniconda in Python is Dub in D.
>
> The analogy to Anaconda in Python is downloading the whole of the Dub repository before doing anything.
>
> Actually Dub is more like Pip. Continuum Analytics put a lot of effort into managing their separate repository. Very little crap, lots of good stuff. But focused on data science.
>
> --
> 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
>

Reading the whole thread here it seems we're all pretty much in agreement about lightweight phobos + dub on steroids.

- phobos should be the common glue allowing interoperability between
various libraries and apps.
- druntime should be OS abstraction?
- dub should be first or second  thing you download when using D (depends
if it can install d itself)

Perhaps:
'dub install dmd' installs dmd
'dub install ldc|gdc' ...
'dub init +gui ' could init a gui app with recommended dependencies.
'dub init +web' for Web dev.
Etc...

?

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei

Hi,

I am new to D, and having my own language implementation (based off Lua) - therefore I think I can appreciate some of the difficulties around getting more contributors to D. For what its worth below are some thoughts on the H1 2016 priorities.

I am a would be D user - D is a tool that should help me get my job done. I guess the vast majority of potential users are in this bracket. To become a contributor requires one of the following - a) it must be your day job, i.e. someone paying you to work on the language, or b) you happen to have lots of free time and deeply interested in D's development, plus have the skills needed to contribute to D. I think that getting contributors to the core of D is going to be difficult. Most other languages/compilers that have big list of contributors usually have one or more large organisations funding the people working on the language. Rust, Go, Gcc, Clang, Java, C#, all fall into this category. I am not sure about Python, but I suspect companies like Google sponsored a lot of the work done in Python.

Assuming that above is correct and that you will only have a handful of people who can contribute to core D - then it seems to me that the effort needs to be a) least wasteful, and b) highly focused. Right now, there are multiple implementations of D compiler - DMD, GDC, LDC, SDC - here you have a bunch of people who obviously have the time, the knowledge and the desire to develop D. Yet the effort is spread out into several different implementations, and therefore wasteful. Why not form a core group and settle on one implementation and everyone focus on that? I know this is very hard as no one would be willing to give up their creation, but for the greater good of D? Perhaps you could assess each implementation and settle on the one that has the most technical merit and future proofing?

As a D user who wishes to use D as a better C / C++ - my personal needs are following:

a) D should work on the three major platforms - Windows, Linux and OSX.
b) It should be possible to write code in D that one would have written in C / C++ - i.e. let the programmer have full control.
c) A good debugger on all supported platforms is essential for any complex language.
d) A good IDE is essential to attract users accustomed to Eclipse, IntelliJ, Visual Studio.
e) A core library that handles the most basic stuff.
f) Ability to easily import C libraries. I struggled with htod - haven't tried dstep yet - but implementing tooling based on Clang seems sensible.

The need to have a good standard GUI toolkit is not so great these days as users are moving away from Desktop applications.

I realise that interfacing with C++ seems like a big goal - but to be honest this isn't important to me. C++ isn't the standard for cross language interfacing ... C is.

Regards
Dibyendu

On Monday, 25 January 2016 at 18:11:24 UTC, Dibyendu Majumdar wrote:
> On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
>> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
>
> Hi,
>
> I am new to D, and having my own language implementation (based off Lua) - therefore I think I can appreciate some of the difficulties around getting more contributors to D. For what its worth below are some thoughts on the H1 2016 priorities.
>
> I am a would be D user - D is a tool that should help me get my job done. I guess the vast majority of potential users are in this bracket. To become a contributor requires one of the following - a) it must be your day job, i.e. someone paying you to work on the language, or b) you happen to have lots of free time and deeply interested in D's development, plus have the skills needed to contribute to D. I think that getting contributors to the core of D is going to be difficult. Most other languages/compilers that have big list of contributors usually have one or more large organisations funding the people working on the language. Rust, Go, Gcc, Clang, Java, C#, all fall into this category. I am not sure about Python, but I suspect companies like Google sponsored a lot of the work done in Python.
>
> Assuming that above is correct and that you will only have a handful of people who can contribute to core D - then it seems to me that the effort needs to be a) least wasteful, and b) highly focused. Right now, there are multiple implementations of D compiler - DMD, GDC, LDC, SDC - here you have a bunch of people who obviously have the time, the knowledge and the desire to develop D. Yet the effort is spread out into several different implementations, and therefore wasteful. Why not form a core group and settle on one implementation and everyone focus on that? I know this is very hard as no one would be willing to give up their creation, but for the greater good of D? Perhaps you could assess each implementation and settle on the one that has the most technical merit and future proofing?

dmd, gdc, and ldc already share a common frontend.  Walter, the main dmd developer, will never look at the llvm or gcc backends for legal reasons; the gcc devs likely won't touch anything that's not GPL; and the ldc devs likely prefer the license or implementation of llvm.  I'm not sure what motivates the sdc devs, but it's likely having a frontend written in D itself that is focused on being easily used as a library, which dmd's recently translated D frontend isn't.  Other than sdc, I doubt there's actually much code duplication going on, so I don't think this redundancy hurts.

> As a D user who wishes to use D as a better C / C++ - my personal needs are following:
>
> a) D should work on the three major platforms - Windows, Linux and OSX.
> b) It should be possible to write code in D that one would have written in C / C++ - i.e. let the programmer have full control.
> c) A good debugger on all supported platforms is essential for any complex language.
> d) A good IDE is essential to attract users accustomed to Eclipse, IntelliJ, Visual Studio.
> e) A core library that handles the most basic stuff.
> f) Ability to easily import C libraries. I struggled with htod - haven't tried dstep yet - but implementing tooling based on Clang seems sensible.

I don't think there has ever been a language that would fulfill all these requirements, let alone an OSS one that was available free of charge.  D gets you some of the way, but it cannot grant you all your wishes.

> The need to have a good standard GUI toolkit is not so great these days as users are moving away from Desktop applications.

Yeah, a couple toolkits in dub is fine.

> I realise that interfacing with C++ seems like a big goal - but to be honest this isn't important to me. C++ isn't the standard for cross language interfacing ... C is.

Which is why D long didn't support interfacing with C++.  But the leadership feels there is some untapped market out there that will warm to D once it can interface with C++ better, and I avoid C++ like the plague so I can't say if that's true or not.  I know that I personally don't care for such C++ integration- nor do many in the D community, or they wouldn't be using D already- but those who do seem to have their ear for now.

PvDda> I think improving dlangide will give us many opportunities for PvDda> what a good D native GUI library needs.

Right   you   are.   However,   it  would  be  great  if  such  a  GUI library/framework  could  be able to produce GUIs accessible to screen readers.  And  it  would be more than great if the IDE itself could be accessible.  However,  with  Dlangui  it's  not  the  case,  namely on Windows.

Andre.

On 2016-01-25 14:22, Andrew Edwards wrote:

> Glad to see your spirit is not easily broken. That, however, does not
> invalidate my statement.  One would think that 10 years after being
> dubbed the official graphics library for the language, it would be
> simple to install DMD and DWT side by side on all DMD supported
> platforms and the two just work well together. Especially since people
> that advocated it claimed that by making it official, it would
> legitimize their contributions to help improve make improvements. It is
> not even usable on what appears to be the platform you develop on/for,
> MAC OS X, and you are the main maintainer/contributer.

The only thing that happened, as far as I know, in terms of official was that Walter announced it to be the official GUI and it got its own dedicated newsgroup. It's not on the web site, there's been no coordinated releases, no contribution from the core team, nothing. I don't see how anyone could expect progress to increase at all.

-- 
/Jacob Carlborg

On 25 January 2016 at 21:44, Jacob Carlborg via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On 2016-01-25 14:22, Andrew Edwards wrote:
>
> Glad to see your spirit is not easily broken. That, however, does not
>> invalidate my statement.  One would think that 10 years after being dubbed the official graphics library for the language, it would be simple to install DMD and DWT side by side on all DMD supported platforms and the two just work well together. Especially since people that advocated it claimed that by making it official, it would legitimize their contributions to help improve make improvements. It is not even usable on what appears to be the platform you develop on/for, MAC OS X, and you are the main maintainer/contributer.
>>
>
> The only thing that happened, as far as I know, in terms of official was that Walter announced it to be the official GUI and it got its own dedicated newsgroup. It's not on the web site, there's been no coordinated releases, no contribution from the core team, nothing. I don't see how anyone could expect progress to increase at all.
>
>
With respect, I'm not sure whether anyone in core would have the slightless hint of knowing how UI works. (Not that I speak for anyone but myself :-)

On Monday, 25 January 2016 at 20:44:10 UTC, Jacob Carlborg wrote:
> On 2016-01-25 14:22, Andrew Edwards wrote:
>
>> Glad to see your spirit is not easily broken. That, however, does not
>> invalidate my statement.  One would think that 10 years after being
>> dubbed the official graphics library for the language, it would be
>> simple to install DMD and DWT side by side on all DMD supported
>> platforms and the two just work well together. Especially since people
>> that advocated it claimed that by making it official, it would
>> legitimize their contributions to help improve make improvements. It is
>> not even usable on what appears to be the platform you develop on/for,
>> MAC OS X, and you are the main maintainer/contributer.
>
> The only thing that happened, as far as I know, in terms of official was that Walter announced it to be the official GUI and it got its own dedicated newsgroup. It's not on the web site, there's been no coordinated releases, no contribution from the core team, nothing. I don't see how anyone could expect progress to increase at all.

My point exactly. Simply naming something official does not improve it's status or send contributors clamoring to assist in its improvement. It takes a deliberate effort and dedication of resources to accomplish that.