On 26/01/16 6:07 AM, Russel Winder via Digitalmars-d-announce wrote:
> 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.

Well whoever these people are, they are most certainly not the people I've seen. They wouldn't care or even want to look at PyPI.

>> 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.

2 years ago, but I can guarantee for students that go through that course and tutors, it won't be changing anytime soon.

>> 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…

You're 100% right that it is the people problem here.
But right now, Phobos is the only way I can emphasize reuse of the core bare-bones libraries.

On Tue, 2016-01-26 at 17:06 +1300, Rikki Cattermole via Digitalmars-d- announce wrote:
> […]
> 
> Well whoever these people are, they are most certainly not the
> people
> I've seen. They wouldn't care or even want to look at PyPI.

The people you have seen are clearly not Pythonistas. This may be by dint of their teachers/lecturer/tutors/mentors not actually understanding Python and its culture.

[…]
> 
> 2 years ago, but I can guarantee for students that go through that course and tutors, it won't be changing anytime soon.

OK, in which case I infer the teachers/lecturers/tutors/mentors really
do not understand Python, and should learn more themselves as a matter
of urgency and professionalism.

[…]
> 
> You're 100% right that it is the people problem here.
> But right now, Phobos is the only way I can emphasize reuse of the
> core
> bare-bones libraries.

I disagree (hence my comment about displacement). I think we should fix the Dub issues and the relationship between Dub, GDC, LDC, DMD, druntime and Phobos. To use Phobos as a "hack" to solve the problem in the short term will be a disservice to D in the medium to long term. 
-- 
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

I wasn't going to reply, until you tweeted.
No just no.

When dealing with tertiary institutions especially New Zealand ones, you've got to understand they have massive pressure to get through content. Every single class is standardized nationally, by law.

You're all worried about doing things best practice in an eco-system.
That is just not the case here. In these courses they are not meant to be teaching a language. But instead use said language to teach with.

The most time a student gets in ANY language is 2 semesters. By the time they reach third year (last) they only have 1 per language.
In these classes the concern is teaching some other relevant concept such as design patterns.

So you're pushing limited class time for the purpose of teaching actual class content instead of non required information for assignments.
Its a balancing act.

But you've got to understand that most of the students going through it, are just not interested in going much further then the assignments.
Simple things like trying OpenGL are beyond them and this is ok. They have a lot of things to learn and have real life requirements outside of study.

The average person learning to program is not spending half the time most D developers do on a slow week. Again this is ok. But we need to acknowledge that they won't be anywhere near us or our expectations normally.

To assume the average person will play around and learn pip ext. is just ridiculous. Especially when they have most if not all the code they need already available to them via the distribution.

These are the same people who we may barely convince to try D out. If they struggle to do basic things or at least perceived basic things then they won't bother and just say 'too hard'.
If we can make them happy, most developers over all will be happy. Even the average D developer will be glad for it.

At the end of the day, the least amount of steps to do what is perceived as basic tasks without any conflicting arguments the better.

I keep saying about perceived basic tasks. Psychology. A fourteen year old today was born in 2002. I learned to program when I was 14. In 2001 XP was just released. The people learning programming now expect GUI's and perceive it as basic. We may know better but at the end of the day, how can we appeal to them realistically?

On 2016-01-25 22:15, Iain Buclaw via Digitalmars-d-announce wrote:

> 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 :-)

And you think that I have the slightest idea of what I'm doing ;)

-- 
/Jacob Carlborg

Some of this apparently off-topic, but I will get back on-topic by the end.

On Tue, 2016-01-26 at 21:17 +1300, Rikki Cattermole via Digitalmars-d- announce wrote:
> I wasn't going to reply, until you tweeted.

Sorry for wrongly assigning geography.

> No just no.

Yes, oh yes, oh yes.

> When dealing with tertiary institutions especially New Zealand ones, you've got to understand they have massive pressure to get through content. Every single class is standardized nationally, by law.

Sounds like the NZ system is not as good a tertiary education system as it should be. Having guidelines for curriculum and examination is fine, but to stadardize at the class level is definitely too low.  UK universities went through this debate in the 1980 and managed to escape from legal enforcement.

> You're all worried about doing things best practice in an eco-system.
> That is just not the case here. In these courses they are not meant
> to
> be teaching a language. But instead use said language to teach with.

There should also be classes in applications construction. Clearly classes on specification, compilers, etc. the language is tool only and workflow and best practice of programming are irrelevant.

> The most time a student gets in ANY language is 2 semesters. By the
> time
> they reach third year (last) they only have 1 per language.
> In these classes the concern is teaching some other relevant concept
> such as design patterns.

Design patterns are not language agnostic. GoF patterns are 23 year old and many totally irrelevant with certain programming languages. However that is a different debate for a different place.

> So you're pushing limited class time for the purpose of teaching
> actual
> class content instead of non required information for assignments.
> Its a balancing act.

It sounds like the law makers are getting it wrong then. If there is no time for teaching programming best practice then graduates from the programme are not ready for employment without first doing an apprenticeship of some sort.

> But you've got to understand that most of the students going through
> it,
> are just not interested in going much further then the assignments.
> Simple things like trying OpenGL are beyond them and this is ok.
> They
> have a lot of things to learn and have real life requirements outside
> of
> study.

From my time in academia (20 years) I can pretty much agree that most computing students didn't actually give a shit about computing. Certainly 40% of them couldn't program. But because of the curriculum they get degrees, get jobs as programmers and we end up with the mass of crap code we currently have in the world.

> The average person learning to program is not spending half the time
> most D developers do on a slow week. Again this is ok. But we need
> to
> acknowledge that they won't be anywhere near us or our expectations
> normally.

Which gets on to a huge hobby horse of mine. If degrees are about knowledge then there has to be a follow on before people are employed. Medics do this: three year degree, two or three years on the job training. Effectively an apprenticeship. Sadly in computing, most employers assume graduates have the knowledge and the work practice skills. Clearly they do not.

It seems NZ is enshrining this in law. UK it is jsut what happens.

Of course most university computing academic staff cannot program either.

> To assume the average person will play around and learn pip ext. is
> just
> ridiculous. Especially when they have most if not all the code they
> need
> already available to them via the distribution.

Ridiculous is the wrong word to use here. All Python programmers should know about pip and PyPI. You are talking about students using Python to code up answers to exercises. If the academic ensures there is no need of anything other than the standard distribution, then that is a fine compromise, in that situation. But a person off that course should never claim they can program in Python, nor should tehy be considered for Python programming jobs without further training.

> These are the same people who we may barely convince to try D out.
> If
> they struggle to do basic things or at least perceived basic things
> then
> they won't bother and just say 'too hard'.
> If we can make them happy, most developers over all will be happy.
> Even
> the average D developer will be glad for it.

Mostly because they cannot be arsed.

Academic's have a responsibility here to configure things for the students. We did this with C++, Scheme, Miranda, Java, etc. Part of the initial pack for each course were detailed tested instructions for students to set up. They didn't have to think, they just had to follow the recipe.

> At the end of the day, the least amount of steps to do what is
> perceived
> as basic tasks without any conflicting arguments the better.

True.

1. Download Dub.
2. Dub install standard-distribution

should do it.

> I keep saying about perceived basic tasks. Psychology. A fourteen
> year
> old today was born in 2002. I learned to program when I was 14. In
> 2001
> XP was just released. The people learning programming now expect
> GUI's
> and perceive it as basic. We may know better but at the end of the
> day,
> how can we appeal to them realistically?

In the university context most of the problems you are pointing out land squarely at teh feet of the academic, and law makers, not the students. Students are clearly input and output being treated as cannon fodder, not as individuals wishing to learn things.

But to get back on topic.

Yes modern development is about IDEs. VIM and Emacs do not count even though a lot of programmers use them. IntelliJ IDEA (CLion, PyCharm,…), NetBeans, Visual Studio, Xcode, even Eclipse, are what people mean by IDEs.

In various Scala, Java, Python, Clojure, workshops I have forced people to use IDEs who would otherwise have used VIM or Emacs.It is amazing how much further people get in learning a language and how to use it with all the extras over and above editing that a good IDE provides. As a confirmed believer in "Emacs is the One True Editor, VIM is a scouring agent" I have been converted to good IDEs – bad IDEs get me back to Emacs very quickly.

So we need a really good, preferably lightweight, but… IDEs that really make programming, D in this context, easier and fun. The IDE should be editor, manual, guide, mentor.

The single incident that really brought this home to me was at a DevoxxUK workshop a couple of years ago, people new to Java were coding up full on good quality RxJava applications in two hours. Without the IntelliJ IDEA environment, they would have been nowhere.

So as well as DDT in Eclipse, there should be solid support for Kingsley and the IntelliJ IDEA D plugin. If we get more people using D, we will have more people willing to contribute to D development, in terms of packages on Dub and otherwise.


-- 
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 01/25/2016 11:26 AM, Russel Winder via Digitalmars-d-announce wrote:
> On Mon, 2016-01-25 at 07:44 -0500, Andrei Alexandrescu via Digitalmars-
> d-announce wrote:
>
>> Could you please back up that assertion a little bit? From all I
>> see,
>> standard libraries of most languages grow very fast with each
>> release.
>> What are your facts? -- Andrei

Thanks for answering. I want to be convinced, and even if not, to gather a more precise view.

The rhetoric is appreciated. What would be helpful here in addition to it are a few links to evidence. You make lofty claims either of status quo in different languages, or major shifts in strategy. They definitely must have left a trail on the Internet. Any chance you'd substantiate these specific claims below with evidence?

> Go has a very small core, if you want anything else you write a library
> and publish it. There is a massive and vibrant activity writing many
> versions of stuff most of which wither by lack of use. Some, usually
> one or two, in each domain thrive and become the de facto standard.
> Everything depends on Git, Mercurial, Bazaar, and go get.

I look at https://golang.org/pkg/ and see a quite substantial standard library, including things that some people argue shouldn't be part of a standard library: archives and compression, cryptography, databases, character encodings (including json and xml!), html templating, image processing, suffix arrays (sic), logging, networking, regexp, testing, tokenization. This list is _after_ I eliminated topics that I believe should be part of a standard library, such as I/O, time, and even unicode, etc.

I'd like to believe our stdlib covers a few areas that Go's doesn't, but it is obvious to me Go's stdlib does (and reportedly very well) cover a bunch of areas that we haven't set foot in yet. This doesn't quite align quite at all with your view that Go is barebones and anyone who wants anything builds it. From what I can tell, Go comes with plenty. (It is of course relative; Go's stdlib may be small compared to externally available libraries, owing to its popularity which the Go team deserves due credit for.)

> Rust threw out large tracts of what was in the original library,
> including all concurrency and parallelism things, in favour of separate
> crates. There is a massive and vibrant activity writing many versions
> of stuff most of which wither by lack of use. Some, usually one or two,
> in each domain thrive and become the de facto standard. Everything
> depends on crates.io and Cargo.

Do you have reference to relevant material (core team blog posts, forum discussions, articles) documenting the shift, boundaries, strategy, motivation etc? A look at https://doc.rust-lang.org/std/ does support your view that Rust's stdlib is minimal.

> Python used to be batteries included, then they moved to having a core
> to which only Python committers have access.  There is a massive and
> vibrant activity writing many versions of stuff most of which wither by
> lack of use. Some, usually one or two, in each domain thrive and become
> the de facto standard. Everything depends on PyPI, pip, and virtualenv.
> Or Anaconda.

Again, a few links to evidence supporting these statements would be awesome. I am sorry for my being incult; I know of pip and used it a couple of times but know nothing about all else. At the same time you'll appreciate I can't just form an opinion on your authority.

> There are many facts out there favouring distributed over centralized
> for everything except the language itself and the runtime system, you
> just have to look. Calling for an explicit, detailed catalogue is not a
> way forward in this debate.

I am truly sorry but is appealing to your own authority a better alternative?

> Dub needs to be front and centre, it represents D, not DMD, LDC, GDC,
> druntime, Phobos. The core of a D distribution is Dub. In this D is
> like Rust, Ceylon, Python, and JVM. And unlike Go. Go is too
> libertarian in my view. Rust, Ceylon, Python, JVM have the right view
> for me: centralized repository and management of distributed projects.
> What Rust and Ceylon are missing that PyPI has is an highly opinionated
> metric that helps you decide what is good and what is dross.
>
> Of course Dub needs a better story around executables rather than
> library packages. Go (go install) and Rust (Cargo build) do this so
> much better. But then Go has a project structure model, and Rust uses
> TOML.

I do agree with Dub's importance. What's unclear to me is what are reasonable criteria for including some given functionality within the stdlib vs. an external one.


Andrei

On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote:
> Ouch yes, seen that before. I just would prefer the base library to be exactly that a base.

I agree. Imagine if all the effort put into Phobos' extras was put into the compiler and tooling...

On 2016-01-26 13:38, Andrei Alexandrescu wrote:

> Thanks for answering. I want to be convinced, and even if not, to gather
> a more precise view.
>
> The rhetoric is appreciated. What would be helpful here in addition to
> it are a few links to evidence. You make lofty claims either of status
> quo in different languages, or major shifts in strategy. They definitely
> must have left a trail on the Internet. Any chance you'd substantiate
> these specific claims below with evidence?

I don't really have an opinion but I found this [1] for Ruby.

[1] https://redmine.ruby-lang.org/projects/ruby/wiki/StdlibGem

-- 
/Jacob Carlborg

On Tuesday, 26 January 2016 at 10:52:17 UTC, Russel Winder wrote:
> Design patterns are not language agnostic. GoF patterns are 23 year old and many totally irrelevant with certain programming languages. However that is a different debate for a different place.

I found GoF underwhelming when I first read it as I had discovered many/most of those patterns on my own, but then someone said that the usefulness was in giving the pattern names. And that made sense.

On Tuesday, 26 January 2016 at 12:46:23 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote:
>> Ouch yes, seen that before. I just would prefer the base library to be exactly that a base.
>
> I agree. Imagine if all the effort put into Phobos' extras was put into the compiler and tooling...

It's not like you could just reallocate all the effort that goes into Phobos towards the compiler and stuff.

Especially with the compiler itself, most people are unqualified or uninterested in working on it. If it were suddenly announced that Phobos was "finished", I guarantee a lot of volunteers would just walk away (likely including myself).