Re: Vision for the first semester of 2016

[Piotrek via Digitalmars-d-announce]

On Friday, 29 January 2016 at 02:18:38 UTC, Rikki Cattermole 
wrote:
Right now, image library is more or less ready for next 
feedback.
Windowing is almost there, really just needs a bit of testing 
and its done.


So in other words, the hold up, is me.


Where can I find the code to be tested? You have too many 
projects on github :)


Piotrek

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 07/02/16 4:23 AM, Piotrek wrote:

On Friday, 29 January 2016 at 02:18:38 UTC, Rikki Cattermole wrote:

Right now, image library is more or less ready for next feedback.
Windowing is almost there, really just needs a bit of testing and its
done.

So in other words, the hold up, is me.


Where can I find the code to be tested? You have too many projects on
github :)

Piotrek


https://github.com/rikkimax/alphaPhobos

Re: Vision for the first semester of 2016

[Tofu Ninja via Digitalmars-d-announce]

On Wednesday, 3 February 2016 at 11:22:50 UTC, Márcio Martins 
wrote:


How would you select the package version you want to use. 
Obviously it would be fine for small scripts to pick the latest 
version, but no so much for non-trivial projects.


Somewhat related: I would love to be able to install packages 
with dub "globally", and then have them automatically added to 
the compiler's search paths and working with import with rdmd 
and dmd.


I install version 0.1 of package X globally and now all my 
programs pick that up with import. If the package is a library, 
dub would (re)compile then upon installation and put the 
resulting libs in the correct places so that all my programs 
can simply link to them.
I should also be able to override the global import with a 
different version at the project level if I which to do so. 
Similar to what dub.selections.json currently does.


Having dub fully integrated with the compiler and it's 
configuration would be a major quality of life improvement, and 
a nice step towards the "it just works" state. Much like C/C++ 
libraries get installed by Linux's package managers and just 
work, but for D.


Right now the easiest way to boot up a new project is to copy 
one that already exists, rename it, and edit the dub.json file 
to add/remove any dependencies. This gets old really quickly 
and is the only reason why D doesn't really feel like a 
scripting language for small projects, because setting up the 
environment and frequently used dependencies takes longer than 
writing the script, and you need a project directory instead of 
a single .d file that just uses all your common imports.


There are a few problems with it. For instance dub packages have 
no information about the files in them, you can't ask dub for 
derelict.opengl3.gl3.d, you ask it for the package derelict-gl3. 
So for something like this to work, there would need to be some 
type of syntax to import the package.


Probably something simple could be done like pragma(dub, 
"derelict-gl3", "==1.0.12");. As far as I can tell a dub pragma 
could be 100% ignored by the compiler unless a flag gets passed 
to print the dub dependencies. Then a tool like rdmd that gets 
all the imports for a file could also get all the dub 
dependencies and call out to dub to download them and pass the 
import paths for the dub dependencies to the final invocation of 
dmd. Otherwise the dub pragma would really do nothing other than 
be a signifier to outside tools. Tools like dcd could even use 
the pragmas to automatically call out to dub to find the paths of 
the dependencies and start indexing them for auto completion.


Really would be a great day to have that all automatically work. 
Also dub could be packaged with dmd and make all this more simple.


Right now the easiest way to use dub is to make a .json for your 
own project and build with dub, but honestly that sucks a lot 
because really the only thing people want to use dub for is the 
dependencies, the rest of it kinda gets in the way and is 
annoying as hell to use. Like trying to figure out how to build 
projects for x64 or unittests or whatever with dub is a pain. Its 
not really what people want to use dub for, but it tries to pass 
itself off as a build system which it sucks at.

Re: Vision for the first semester of 2016

[Tofu Ninja via Digitalmars-d-announce]

On Wednesday, 3 February 2016 at 23:35:21 UTC, Tofu Ninja wrote:

...


Actually now that I think about it, you can do with out the 
pragma and just define something like this...


mixin template DubDependency(string dependency, string vers)
{
// Does nothing but print a dependency
version(Dub_Dependency){
		pragma(msg, "DubDependency: \"" ~ dependency ~ "\" \"" ~ vers ~ 
"\"");

}
}


Then whenever you need it you just put:
mixin DubDependency!("derelict-gl3", "==1.0.12");

And to get the dependencies for a file you can just do
dmd test.d -o- -version=Dub_Dependency

Re: Vision for the first semester of 2016

[Matt Elkins via Digitalmars-d-announce]

On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
In theory it's completely irrelevant as to whether is something 
is in the standard library or can just be imported via dub or a 
git clone, but in practice that's not the case.


In support of this statement in particular I'd like to point out 
that there are many environments which, for various reasons of 
security and policy, often require that any 3rd-party libraries 
not included as a language's standard be explicitly vetted by 
teams of very slow-moving people who seem to actively enjoy 
paperwork. In practice this means that non-standard libraries 
simply don't get used in those environments. That said, if a 
library gets popular enough (Boost, parts of Apache), they might 
manage to get pre-vetted and still used in these situations.


I'm not really offering a good solution to the debate, I just 
wanted to make a note of this.

Re: Vision for the first semester of 2016

[Chris Wright via Digitalmars-d-announce]

On Thu, 04 Feb 2016 01:23:14 +, Tofu Ninja wrote:

> Actually, nvm, wouldn't actually work because as soon as you add an
> import derelict.opengl3.gl3; it would error out because it cant find the
> file and it wouldn't print the dependencies.

You could do it with libdparse, since it doesn't do semantic analysis.

Re: Vision for the first semester of 2016

[Tofu Ninja via Digitalmars-d-announce]

On Thursday, 4 February 2016 at 00:50:43 UTC, Tofu Ninja wrote:

On Wednesday, 3 February 2016 at 23:35:21 UTC, Tofu Ninja wrote:

...


Actually now that I think about it, you can do with out the 
pragma and just define something like this...


mixin template DubDependency(string dependency, string vers)
{
// Does nothing but print a dependency
version(Dub_Dependency){
		pragma(msg, "DubDependency: \"" ~ dependency ~ "\" \"" ~ vers 
~ "\"");

}
}


Then whenever you need it you just put:
mixin DubDependency!("derelict-gl3", "==1.0.12");

And to get the dependencies for a file you can just do
dmd test.d -o- -version=Dub_Dependency


Actually, nvm, wouldn't actually work because as soon as you add 
an import derelict.opengl3.gl3; it would error out because it 
cant find the file and it wouldn't print the dependencies.

Re: Vision for the first semester of 2016

[Andre Polykanine via Digitalmars-d-announce]

PvDda> I hope D GUI will be usable some day for me and other people not
PvDda> wanting to fight with tools (and external libraries).

Oh  yeah!  I  find  this  library  the  most  adequate  (and  the most
accessible, btw). But unfortunately it seems abandoned :(.


Andre

Re: Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 1/29/16 11:07 AM, Adam D. Ruppe wrote:

I'd love it if you could do `import thirdparty.independent;` and it
magically works too - without even need for a configuration file or an
install command. And the docs are right there and tutorials are written
however the author feels like writing them.


I suggested that at a point, it was destroyed. -- Andrei

Re: Vision for the first semester of 2016

[Chris Wright via Digitalmars-d-announce]

On Fri, 29 Jan 2016 16:07:48 +, Adam D. Ruppe wrote:

> I'd love it if you could do `import thirdparty.independent;` and it
> magically works too - without even need for a configuration file or an
> install command. And the docs are right there and tutorials are written
> however the author feels like writing them.

That's how Go does it. It's not the case that Go doing things one way 
means that you should do the opposite, but it is an indication that you 
should look for other examples before following suit.

In the case of dependencies, they should always be versioned. The 
language and standard library should be stable enough that you don't have 
to specify a version you  depend on -- though that isn't always true. So 
are you going to include a version specifier in import statements now? 
That would be awkward.

Re: Vision for the first semester of 2016

[earthfront via Digitalmars-d-announce]

On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:
When you do `import std.string;` you expect it to just work, 
and you find std.string's docs easily from dmd.


I'd love it if you could do `import thirdparty.independent;` 
and it magically works too - without even need for a 
configuration file or an install command. And the docs are 
right there and tutorials are written however the author feels 
like writing them.


OMG I would love this.
Often I write short scripts and use rdmd for rapid prototyping.

Having to dub initialize and pull in libraries is a pain for 
this. Python got it right with their package manager(s)

Re: Vision for the first semester of 2016

[David Nadlinger via Digitalmars-d-announce]

On Monday, 1 February 2016 at 11:42:54 UTC, Daniel Murphy wrote:
The process will be complete when you've backported the 
entirety of 2.068.


From what I recall, 2.068 was fairly painless to merge anyway 
compared to other releases.


 — David

Re: Vision for the first semester of 2016

[Daniel Murphy via Digitalmars-d-announce]

On 1/02/2016 8:46 AM, Iain Buclaw via Digitalmars-d-announce wrote:


I know, I've been hitting bug after bug in 2.067, and the answer has always
been to backport from 2.068.  I already have backported druntime's object.d
from 2.068 because 2.067's object module has drifted so far out of sync
with it's hidden implementation, I couldn't build anything!  So I might as
well backport the rest of the druntime library.  Nothing much has changed
as it was a "bugfix" release.



The process will be complete when you've backported the entirety of 2.068.

Re: Vision for the first semester of 2016

[Iain Buclaw via Digitalmars-d-announce]

On 29 January 2016 at 22:29, Tofu Ninja via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 29 January 2016 at 20:30:35 UTC, Iain Buclaw wrote:
>
>> How much of it actually depends on the compiler though?  I'd be a little
>> surprised if we couldn't backport at least 80% of phobos to 2.067/2.068
>> with zero changes.
>>
>
> I have no idea, I think you are probably right. But having a compiler and
> phobos out of sync sounds even worse than the way it is now. A better
> solution for me would be to just stick with a version and wait for gdc to
> catch up but honestly it seems like as soon as a new version comes out I
> hit some bug that is only fixed in the latest version, forcing me to
> upgrade.
>
> For example this literally happened days ago, I am currently at 2.069 and
> the other day I needed to call some winapi stuff, only to realize the
> winapi bindings are way outdated, well guess what they are updated in
> 2.070. Its amazing how often I hit a problem and then find out its fixed in
> the next version.
>

I know, I've been hitting bug after bug in 2.067, and the answer has always
been to backport from 2.068.  I already have backported druntime's object.d
from 2.068 because 2.067's object module has drifted so far out of sync
with it's hidden implementation, I couldn't build anything!  So I might as
well backport the rest of the druntime library.  Nothing much has changed
as it was a "bugfix" release.

Iain.

Re: Vision for the first semester of 2016

[Adam D. Ruppe via Digitalmars-d-announce]

On Thursday, 28 January 2016 at 12:40:56 UTC, Ola Fosheim Grøstad 
wrote:
I think that Sonke received too much "negative motivation" for 
his contributions recently, if I had been in his shoes I'd 
probably found working on vibe.d more fun. IRRC Ruppe also have 
voiced that he want to work on libraries which he has more 
freedom with.


Yeah, I think getting in Phobos is a waste of time and likely a 
net negative on the library due to how much harder it is to 
change phobos vs changing your own file.


In my perfect world, quality third party apps - as determined 
just by usage stats or something - would be automatically 
downloadable and their documentation searchable as if it was 
standard.


When you do `import std.string;` you expect it to just work, and 
you find std.string's docs easily from dmd.


I'd love it if you could do `import thirdparty.independent;` and 
it magically works too - without even need for a configuration 
file or an install command. And the docs are right there and 
tutorials are written however the author feels like writing them.



Then the line between "standard library" and other library 
basically disappears.



While that isn't likely to happen, we could at least start 
promoting third party stuff more equally.


An frankly, as APIs have to be vetted on large applications in 
maintenance mode a lot of the effort put into arguing the 
design "perfect Phobos libraries" most likely will be in vain.


This is a reason why I tend to only write libs that I actually 
use myself - at least then I know every function has one happy 
user.

Re: Vision for the first semester of 2016

[Tofu Ninja via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


Just out of curiosity, is getting the different compilers in sync 
still a priority? Right now we have dmd at 2.070, ldc at 2.068. 
and gdc at 2.066.

Re: Vision for the first semester of 2016

[Iain Buclaw via Digitalmars-d-announce]

On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> 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
>
>
> Just out of curiosity, is getting the different compilers in sync still a
priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.

If anyone wants to help out...

I have to also juggle working on GCC and GDB. :-)

When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect
it to stay there for a while...

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:
In my perfect world, quality third party apps - as determined 
just by usage stats or something - would be automatically 
downloadable and their documentation searchable as if it was 
standard.


I've noticed that curated lists of libraries are popping up on 
github for various languages:

https://github.com/search?utf8=%E2%9C%93=awesome

If D gets more users maybe there would be a market for a 
commercial IDE with a reviewed repository with globally 
searchable reference documentation and cookbook recipes.


For popular languages stack overflow is pretty ok, but over time 
it is getting more chaotic.


Imagine an intelligent IDE that looks at the probability of a 
match between a cookbook recipe and what you type. A.I. 
templating of sorts.


Then the line between "standard library" and other library 
basically disappears.


I usually prefer to download from github for commercial code and 
put it in my project archive. I want to check out if the library 
programmers are maintaining it and have enough people as well. 
Then I lock that version until I find a reason to upgrade.


For me automatic downloading (dub etc) fits more with hobby 
projects and experiments.


While that isn't likely to happen, we could at least start 
promoting third party stuff more equally.


Yep, a curated list like those awesome-lists found on github 
would be a start.


Then write tutorials that only use libraries from that list.

This is a reason why I tend to only write libs that I actually 
use myself - at least then I know every function has one happy 
user.


Yeah, I find myself constantly wanting to improve on even the 
simplest libraries for better interaction with the kind of code 
the functions/objects seem to be most used with.


More of a discovery process of usability than "mathematical 
deduction".

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Friday, 29 January 2016 at 23:41:47 UTC, Ola Fosheim Grøstad 
wrote:




Yep, a curated list like those awesome-lists found on github 
would be a start.




I've got one before there were many awesome-lists: 
https://github.com/zhaopuming/awesome-d

Re: Vision for the first semester of 2016

[Tofu Ninja via Digitalmars-d-announce]

On Friday, 29 January 2016 at 20:30:35 UTC, Iain Buclaw wrote:
How much of it actually depends on the compiler though?  I'd be 
a little surprised if we couldn't backport at least 80% of 
phobos to 2.067/2.068 with zero changes.


I have no idea, I think you are probably right. But having a 
compiler and phobos out of sync sounds even worse than the way it 
is now. A better solution for me would be to just stick with a 
version and wait for gdc to catch up but honestly it seems like 
as soon as a new version comes out I hit some bug that is only 
fixed in the latest version, forcing me to upgrade.


For example this literally happened days ago, I am currently at 
2.069 and the other day I needed to call some winapi stuff, only 
to realize the winapi bindings are way outdated, well guess what 
they are updated in 2.070. Its amazing how often I hit a problem 
and then find out its fixed in the next version.

Re: Vision for the first semester of 2016

[Jon D via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


A couple comments:
a) No mention of targeting increased organizational participation 
(academic, corporate, etc). Not trying to suggest it should or 
shouldn't be a goal. Just that if it is goal meaningful effort 
will be directed toward in H1 then it'd be worth including in the 
writeup.


b) More specificity in the roadmap and priorities, to the extent 
they are known - As a potential D adopter, it'd be useful to have 
better insight into where the language might be a year or two 
out. For example, what forms of C++ integration might be 
available, or if the major components of the standard library are 
likely to be available nogc. However, it's hard to discern this 
from the writeup. Perhaps in many cases it would be premature to 
establish such goals, but to the extent there has been concrete 
thought it'd be useful to write it up. This comment is similar to 
a number of others suggesting a preference for more concrete 
goals.


--Jon

Re: Vision for the first semester of 2016

[Tofu Ninja via Digitalmars-d-announce]

On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote:
On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" 
< digitalmars-d-announce@puremagic.com> 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



Just out of curiosity, is getting the different compilers in 
sync still a
priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc 
at 2.066.


If anyone wants to help out...

I have to also juggle working on GCC and GDB. :-)

When gdc reaches 2.068 (GCC 7.1 is the target release next 
year) - expect it to stay there for a while...


It would be nice if keeping them in sync was a priority, I would 
love to use GDC so I could use GDB, but not having the latest 
fixes is simply not worth it. Even simple things dont work when 
you go back just a few versions, like in 2.066 isForwardRange is 
not correct and does not work properly, something as simple as 
that does not work. Not to mention using the new stuff like 
allocators.

Re: Vision for the first semester of 2016

[Iain Buclaw via Digitalmars-d-announce]

On 29 January 2016 at 21:14, Tofu Ninja via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote:
>
>> On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" <
>> digitalmars-d-announce@puremagic.com> 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

>>>
>>>
>>> Just out of curiosity, is getting the different compilers in sync still a
>>>
>> priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.
>>
>> If anyone wants to help out...
>>
>> I have to also juggle working on GCC and GDB. :-)
>>
>> When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect
>> it to stay there for a while...
>>
>
> It would be nice if keeping them in sync was a priority, I would love to
> use GDC so I could use GDB, but not having the latest fixes is simply not
> worth it. Even simple things dont work when you go back just a few
> versions, like in 2.066 isForwardRange is not correct and does not work
> properly, something as simple as that does not work. Not to mention using
> the new stuff like allocators.
>

How much of it actually depends on the compiler though?  I'd be a little
surprised if we couldn't backport at least 80% of phobos to 2.067/2.068
with zero changes.

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Thursday, 28 January 2016 at 16:12:44 UTC, jmh530 wrote:
the standard library or not. As discussed elsewhere, there are 
clearly benefits to putting some things in phobos (if only for 
providing a framework for others), and there are costs as it 
gets too large.


That's the maintenance costs, but there are other related costs:

1. It takes a lot of work to get it in, you have to negotiate 
with non-domain experts to get in improvements.


2. The presence of sub-optimal standard functionality discourage 
development of slightly better functionality as a third party 
solution. So you loose evolutionary advantages.


3. You cannot easily modify it as it is distributed with the 
compiler. A standard library is essentially an API with a 
reference implementation, but compilers can do whatever they want 
in terms of implementation. Changes can therefore lead to 
incompatibilities between compilers.


4. You cannot easily fix bugs, because applications depends on 
the old behaviour. So a bug fix is a breaking change. You have to 
deprecate and provide the same functionality under a new name 
instead.


External libraries can avoid a lot of these issues by versioning. 
Selecting between many different versions of submodules of a 
standard library is way too complicated.

Re: Vision for the first semester of 2016

[jmh530 via Digitalmars-d-announce]

On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:


I do like the building-block idea you suggest, but one must 
think about the deeper reasons for why things are owned by 
which people.  (I have found the Coase theorem and work on 
industrial organisation to be quite stimulating in thinking 
about this question).


In theory it's completely irrelevant as to whether is something 
is in the standard library or can just be imported via dub or a 
git clone, but in practice that's not the case.




Sigh...

The Coase Theorem is about externalities. The whole point of the 
Coase theorem is that when one person is causing a nuisance or 
polluting it is costly to bargain so the efficient allocation may 
not result. The law/courts should assign property rights in such 
a way to maximize efficiency. This does not seem relevant.


Based on the second paragraph, I think you meant Ronald Coase's 
work in the paper The Nature of the Firm. This paper asks the 
question why things are made in a firm or contracted to other 
firms. This clearly parallels your discussion of why things are 
included in phobos or not.


However, the whole point of the Nature of the Firm is that 
transaction costs exist in the real world. Firms trade-off the 
transaction costs of contracting business outside the firm with 
the benefits of doing things in house. These pressures lead to 
constraints on the maximum size of a firm.


Coming back to phobos and the fact that there are transaction 
costs in the real world (discussions on the forum about the 
future of D are clearly transaction costs), this implies that "in 
theory" it is not irrelevant as to whether something is in the 
standard library or not. As discussed elsewhere, there are 
clearly benefits to putting some things in phobos (if only for 
providing a framework for others), and there are costs as it gets 
too large.

Re: Vision for the first semester of 2016

[Adam D. Ruppe via Digitalmars-d-announce]

On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
As you yourself have mentioned, the size of the D community as 
it stands today presents some impediment to the possible 
maintenance and stability of alternative libraries.  If 
something is in Phobos you know that you can depend on it, that 
bugs will get fixed, and that changes to the language won't 
stop the code from compiling (since it will be fixed).



On the other hand, Phobos is so tightly coupled to dmd that if 
you want a Phobos bugfix, you might also be stuck with a dmd 
regression and get nowhere.


Moreover, Phobos doesn't really get all that many bug fixes. It 
lags on the release cycle and a few modules are basically just 
abandoned. Third party alternatives have been available the whole 
time though.


The bus factor is high for external libraries - people get 
sick, divorced, change interest, and so on.


But there's nothing stopping you from forking it yourself...

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Wednesday, 27 January 2016 at 21:00:41 UTC, Martin Nowak wrote:
A good criteria is whether some area has an established and 
hard to debate solution, then it can go into the standard 
library. But if there are many different ways around the same 
topic you should leave the decision to the users.


I don't think this is the right criteria. Take a good hard look 
at the C++ standard library.
Plenty of things in there that nobody use, but which one would 
hope that almost everyone would use. Like for numerics.


When a good external numerics library emerge it will displace 
whatever numerics functionality the standard library provides.


D has too few users to see high quality external libraries, but 
that is not a good reason to bloat the standard library.


The argument that some functionality is needed on a daily basis 
is also misguided. Different applications have different needs.


What the standard library should support is essential interfacing 
with the system and what you need to interface with libraries, 
like basic types/iterators.


Once you have something in the standard library you have to 
maintain it forever. If something is in the standard library and 
it turns out to be impossible to implement it efficiently on a 
specific hardware platform then all libraries using that 
functionality will be dog slow on that platform.


So for example there are 3 established ways to parse something, 
dom, stax and event based parsers. So you can add those parsers 
as sth. like std.xml or std.json.


There is no reason for xml or json to be in the standard library. 
You can have a set of recommended libraries, allowing for more 
efficient APIs to emerge over time.


Only functionality where you get unbreakable interdependencies 
between standard modules need to be in standard library.


Parsers and compressors have low levels of inter-library 
dependencies. DSP functionality has only internal dependencies. 
No need for such things in the standard library.



Scripting languages like Python is a horrible example to follow. 
Scripting languages require all C-implemented functionality to be 
in the standard library for the sake of being able to deploy pure 
python code on machines where you don't get to install binaries.

Re: Vision for the first semester of 2016

[Twenty Two via Digitalmars-d-announce]

On Thursday, 28 January 2016 at 02:36:55 UTC, Joakim wrote:

On Thursday, 28 January 2016 at 00:28:26 UTC, Twenty Two wrote:
Parkinson's Law: work expands so as to fill the time available 
for its completion.


[...]


I agree.  Some of the core team uses trello for this:

https://trello.com/b/XoFjxiqG/active

However, that's not really meant for noobs and a lot of the 
core team, including Walter, doesn't really use it.


Judging by the activity log, it's mostly just Martin... poor dawg.

Putting something together people will actually use is pretty 
hard, almost as hard as keeping the momentum to get people to 
keep using whatever you've put in place. Trello's not a bad tool 
but it's useless if there's no traction and no one's being 
reminded to use it. It's hard to attract contributors if you 
don't spell out who/what/when/where/how and funnel them all to 
the one place.


Maybe the core team could discuss among themselves what kind of 
workflow they think would really bring out their potential 
productivity and attract more hands to lighten the load. It seems 
unfair that some people get lumped with doing big jobs purely 
because there isn't really a good way to ask someone else to do 
pieces of it for them.


I'm certain there are lots more people who would get involved if 
only there was a lower barrier to entry. Something not over 
complicated and visible would really move things along, I think.

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
I do like the building-block idea you suggest, but one must 
think about the deeper reasons for why things are owned by 
which people.


It is much easier to get motivated if you have a certain level 
autonomy. Clearly, the "D foundation" should have criterions for 
making a recommendation, like API guidelines, Boost license and 
commitment to maintaining it for a period of time.


For instance, Ponce has made some efforts on audio. You and 
others have made some effort on economic modelling (?). I am 
interested in audio. Then we have an opportunity to form a team 
that builds a shared numerics library, with some input from some 
Phobos coordinator so that ranges are supported in a consistent 
matter.


But here is the key point: we don't have to get input from all D 
programmers. We can form consensus and take ownership and make 
faster decisions. And we can scrap it in two years, learn from 
our mistakes and create a much better API.


I think that Sonke received too much "negative motivation" for 
his contributions recently, if I had been in his shoes I'd 
probably found working on vibe.d more fun. IRRC Ruppe also have 
voiced that he want to work on libraries which he has more 
freedom with.


An frankly, as APIs have to be vetted on large applications in 
maintenance mode a lot of the effort put into arguing the design 
"perfect Phobos libraries" most likely will be in vain.


 (I have found the Coase theorem and work on industrial 
organisation to be quite stimulating in thinking about this 
question).


I noticed you and the other economic theory guys in the thread 
mentioning some interesting models. I'd like to look at those 
later when I have more time :-). Always nice to find some shared 
language for expressing system dynamics.


In theory it's completely irrelevant as to whether is something 
is in the standard library or can just be imported via dub or a 
git clone, but in practice that's not the case.


Well, but if something is in the standard library, other 
libraries will build upon it and add dependencies to it even if 
they don't really have to. Meaning, they will pull in 
dependencies and bloat and make Phobos costly to maintain as you 
will end up with std.json, std.json2, std.json3 etc.


As you yourself have mentioned, the size of the D community as 
it stands today presents some impediment to the possible 
maintenance and stability of alternative libraries.


No, I don't think so. I think that D has nurtured the idea that 
Phobos should provide everything and therefore the modus operandi 
is to complain that Phobos does not provide it.


The bus factor is high for external libraries - people get 
sick, divorced, change interest, and so on.


Recommended libraries should have at least 3-6 people behind them

It would be nice to have SIMD intrinsics, and in the time you 
have spent arguing over the years perhaps it would have been 
possible to help the process of having a high quality and 
consistent implementation along.


SIMD isn't critical to me at this point in time. I am currently 
using C++ for what I would have liked to use D for. D needs more 
compiler developers, a strategy to get there and someone to take 
D there with focused leadership.


The main challenge is not code, it is process.

It really doesn't do any good to worry about what the crowd 
says and the applause you receive.  If you focus on doing good


I don't worry about applause. Describe the key issues and explain 
it from various angels whenever it comes up and people start to 
develop a shared understanding of what needs to be done.


Without a timeline, why invest? The vision for 2016 looks pretty 
good, but there it lacks the details of what and when. What are 
the estimates. What are the explicit goals? How many man hours 
(min/max) are needed. Goals and estimates.


excited about.  I should say that John Colvin is a contractor 
for me, but I am not talking up dlangscience because he is 
helping me, but rather I asked him to help me because I was 
impressed by what he is doing.


That's great! :-)

It strikes me as a bit silly to get hung up over language 
specifications as some kind of mystical talisman.


It brings unfortunate inconsistencies and implementation effects 
to the foreground so that they can be addressed. It is near 
impossible to discuss the design without one.


debating about what people should do, when there is no army of 
troops that can be commanded to implement things they are not 
interested in doing anyway.


Attract more developers.

1. Find out why they don't come.
2. Find out why they leave.
3. Address the issues they have with D.

In my case and for many others the reason go along the lines of: 
memory management, language inconsistencies, a refusal to add 
builtin tuples and platform support.

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

This is what a good system programming standard library should 
provide:


1. Types needed to specify library APIs.

2. Functionality for accessing hardware in a non-emulated fashion.

3. Functionality that most _libraries_ need to build on (like 
arrays/iterators/ranges).


4. Functionality that is tied to the individual compiler (like 
intrinsics).


5. Memory management.


The primary goal of the standard library should not be to support 
building applications, but to enable building frameworks and 
libraries and the interaction between them.



So if one user says "My app needs to read WAV which is RIFF, 
therefore RIFF should be in the standard library" then the 
sensible response is: "Do most _libraries_ need RIFF? Why don't 
you use the recommended audio library which has optimized WAV 
support.".


Surely everyone uses string processing on a daily basis?

No. I personally almost never do string processing in system 
level programming languages, what I need is binary serializing 
support. Or Collada support. Or audio file format support.


I'd be happy to use a recommended string procesessing library 
when or if I need it.


But a standard library MUST have great support for SIMD 
intrinsics, i.e. interfacing the hardware,  that is much more 
critical for system level programming and is tied to the specific 
compiler.

Re: Vision for the first semester of 2016

[Piotrek via Digitalmars-d-announce]

On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole 
wrote:

That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on 
both) there is no way a GUI toolkit is going in. And from what 
I know there will be a LOT of work to update it.


I've read this thread partially and I agree with you. In my 
opinion the key to the success is a good standard library with 
batteries included.


The opinion that this approach is outdated is very subjective.

I hope D GUI will be usable some day for me and other people not 
wanting to fight with tools (and external libraries).


If there is something from your project ready for test drive let 
me know.


Piotrek

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 29/01/16 6:40 AM, Piotrek wrote:

On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole wrote:

That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on both)
there is no way a GUI toolkit is going in. And from what I know there
will be a LOT of work to update it.


I've read this thread partially and I agree with you. In my opinion the
key to the success is a good standard library with batteries included.

The opinion that this approach is outdated is very subjective.

I hope D GUI will be usable some day for me and other people not wanting
to fight with tools (and external libraries).

If there is something from your project ready for test drive let me know.

Piotrek


Right now, image library is more or less ready for next feedback.
Windowing is almost there, really just needs a bit of testing and its done.

So in other words, the hold up, is me.

Re: Vision for the first semester of 2016

[Twenty Two via Digitalmars-d-announce]

Parkinson's Law: work expands so as to fill the time available 
for its completion.


Having a set of vague tasks to finish within 6 months is great, 
but having a weekly more specific priority list to go along with 
it would be better. If, in addition, there was some 
accountability (not with negative implications, just a 
designation of responsibility) that would further narrow focus 
and ramp up productivity.


As a draft proposal, something like a weekly sticky TODO thread 
with clear goals could work. You'd list a few high priority items 
and ask for a volunteers for each and list them as they come in. 
You'd have bigger medium priority item list and ask for 
volunteers but only half of them need to be assigned to someone 
and completed. Then you'd have a much longer lower priority list 
that can be a bit more vague that people are encouraged to work 
on but that they don't need to volunteer for, just submit their 
pull requests (but they can flag an item and have it ticked off 
if they want). On top of that have a weekly pull request goal 
that updates daily (with a time stamp) and an overview of pull 
request numbers from previous weeks.


If an item isn't completed it gets rolled over to the next week 
with an asterisk (if it's medium or high priority) for each time 
it's been rolled over and the previous volunteer listed as such 
(and they can volunteer for the same item the next week giving 
them the perfect opportunity to say where they're at, what needs 
to be done, if the task should be broken down further, etc). 
It'll make it clear if whoever volunteered for a task needs some 
help or encouragement, or if certain high priority tasks need a 
volunteer or to be broken down into more manageable chunks even 
if someone drops off the face of the earth. With a one item at a 
time rule you're going to cut down on stagnation.


I'm sure there are lots of people who'd like to help out but 
they're not really sure what needs to be done or who else is 
doing it or if they'll step on toes, etc. Anyone wondering what's 
being worked on can take a look and help out themselves rather 
than getting upset in the forums about feature x never seeing the 
light of day. If they want feature x done they can take a look at 
the priority list and pick where it should go in the scheme of 
things, maybe even break it down - turn negative energy into 
productive energy :)

Re: Vision for the first semester of 2016

[Chris Wright via Digitalmars-d-announce]

On Wed, 27 Jan 2016 21:01:47 +, Martin Nowak wrote:

> On Monday, 25 January 2016 at 16:26:36 UTC, Russel Winder wrote:
>> PyPI has is an highly opinionated metric that helps you decide what is
>> good and what is dross.
> 
> Could you help us on designing one for code.dlang.org as well?

I'd want to use the number of releases, how recent the most recent 
release was, the longevity of the project, and the number of other 
projects that depend on it. If people are willing to let dub submit 
anonymous usage information, the number of builds depending on a project 
is also an indicator of its value.

Longevity is an awkward one. If I create a project, do nothing with it 
for four years, then make a release, will that count as well as making a 
release once a month for four years? But the other metrics should account 
for that.

If possible, I'd include when the project last compiled and whether it 
passes its unittests. This requires setting up a continuous integration 
service for untrusted code. I've seen other people's designs for that, 
and I think I could replicate it without too much trouble.

Re: Vision for the first semester of 2016

[jmh530 via Digitalmars-d-announce]

On Wednesday, 27 January 2016 at 22:36:37 UTC, Chris Wright wrote:


Longevity is an awkward one. If I create a project, do nothing 
with it for four years, then make a release, will that count as 
well as making a release once a month for four years? But the 
other metrics should account for that.




Code I wrote below incorporates some of what you're talking about.

For simplicity, I represented the date of each release as a 
dynamic array of doubles. I applied a weighting function to each 
and then calculated the entropy. The score is 1 if you only have 
one release. The score is higher, the more releases you have. If 
you have one release five years ago and one release recently, 
then your score is only marginally higher than 1. But if you have 
lots of recent releases, then the score is much more favorable.


You could probably adjust this in a number of ways. For instance, 
adjusting the denominator in

return weight.map!(a => a / weight.sum());
you could make it so that a release today is better than a 
release five years ago.



auto weight(double[] x, double lambda)
{
import std.algorithm : sum, map;
import std.math : exp;
import std.array : array;

	auto weight = x.map!(a => lambda * exp(-lambda * a));	// weights 
given by

// exponential
// distribution
return weight.map!(a => a / weight.sum());
}

double entropy(T)(T x)
{
import std.algorithm : sum, map;
import std.math : exp, log;

auto e = x.map!(a => a * log(a));
return exp(-sum(e));
}

double calc_score(double[] x, double lambda)
{
return x.weight(lambda).entropy();
}

void main()
{
import std.stdio : writeln;

double lambda = 0.5; // controls decay in weighting function
double[] x;  // represents years since last update
x = [0.1, 0.25, 1, 2, 5];

auto score = calc_score(x, lambda);

writeln(score);
}

Re: Vision for the first semester of 2016

[Joakim via Digitalmars-d-announce]

On Thursday, 28 January 2016 at 00:28:26 UTC, Twenty Two wrote:
Parkinson's Law: work expands so as to fill the time available 
for its completion.


[...]


I agree.  Some of the core team uses trello for this:

https://trello.com/b/XoFjxiqG/active

However, that's not really meant for noobs and a lot of the core 
team, including Walter, doesn't really use it.

Re: Vision for the first semester of 2016

[Laeeth Isharc via Digitalmars-d-announce]

On Wednesday, 27 January 2016 at 09:15:27 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc 
wrote:
On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim 
Grøstad wrote:


I am not sure if that is the right motivation. Sounds like 
recipe for bloat. Good libraries evolve from being used in 
real applications. Many applications.


sayeth a low-level guy (if I understand correctly), which will 
certainly create a distinct perspective about what you would 
like to see in the standard library, and yet this may not be 
the right thing for the language as a whole.


I am both low-level and high level, but D's primary advantage 
is that it allows low level programming.


Surely, that is C's primary advantage!  The whole point of D is 
that it doesn't just have one primary advantage, and that is why 
the front page no longer describes it is as a systems language, 
even though it's approaching suitable as such.


fwiw, people that do use D on a serious scale have remarked 
that the richness of the standard library (even as it stands 
today) was a major advantage - in bioinformatics, at a London 
hedge fund, and I think AdRoll.


Do you consider Angular to be low level? It was used in 100s if 
not 1000s of applications, but was considered inadequate and 
scrapped in favour of Angular2. This is the typical pattern for 
libraries and frameworks.


I really don't see how this relates to the point at hand.  You 
seemed to suggest that the standard library should be small, and 
I pointed out that many serious users in industries that are 
likely to be key markets for D do say that they find what's 
provided in the standard library to be quite appealing.  Nothing 
lasts forever, and all is change - that's something I agree with. 
 But it doesn't seem to have much bearing on the decision about 
what to put in the standard library.  Your suggestions that 
because some cloud environments don't have a conventional file 
system, D perhaps shouldn't even have this in the standard 
library really seemed to me to be a reductio ad absurdum of your 
own argument.  Of course there will be lots there that one 
doesn't need and can't use.  But over time things that were once 
cutting edge become bog standard, and it makes sense to have 
coherence and convenience rather than to have to search out the 
best library for the purpose each time.

Re: Vision for the first semester of 2016

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 12:38:09 UTC, Andrei Alexandrescu 
wrote:
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.


See my answer below, most of these are standard solutions that 
you need on a daily basis (except for the suffix array).


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.


A good criteria is whether some area has an established and hard 
to debate solution, then it can go into the standard library. But 
if there are many different ways around the same topic you should 
leave the decision to the users.


So for example there are 3 established ways to parse something, 
dom, stax and event based parsers. So you can add those parsers 
as sth. like std.xml or std.json.


There are about 500 different configuration file formats, so 
anything that isn't as established as xml or json should be left 
for libraries.


Likewise there are plenty of different GUI toolkits (taking 
imperative or declarative approaches). Leave it to people to pick 
one that suites their need.


You could discuss endlessly about the syntax of html templating, 
but how such a library should work is clear. This is at the edge 
of standardizable, b/c by putting it into std, you're making a 
decision for all language users. It's albeit possible, just like 
declaring a particular code style as standard.


Anything that is highly innovative or experimental should never 
go into standard libraries.

Re: Vision for the first semester of 2016

[Martin Nowak via Digitalmars-d-announce]

On Monday, 25 January 2016 at 16:26:36 UTC, Russel Winder wrote:
PyPI has is an highly opinionated metric that helps you decide 
what is good and what is dross.


Could you help us on designing one for code.dlang.org as well?

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc 
wrote:
On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim 
Grøstad wrote:


I am not sure if that is the right motivation. Sounds like 
recipe for bloat. Good libraries evolve from being used in 
real applications. Many applications.


sayeth a low-level guy (if I understand correctly), which will 
certainly create a distinct perspective about what you would 
like to see in the standard library, and yet this may not be 
the right thing for the language as a whole.


I am both low-level and high level, but D's primary advantage is 
that it allows low level programming.


fwiw, people that do use D on a serious scale have remarked 
that the richness of the standard library (even as it stands 
today) was a major advantage - in bioinformatics, at a London 
hedge fund, and I think AdRoll.


Do you consider Angular to be low level? It was used in 100s if 
not 1000s of applications, but was considered inadequate and 
scrapped in favour of Angular2. This is the typical pattern for 
libraries and frameworks.

Re: Vision for the first semester of 2016

[Russel Winder via Digitalmars-d-announce]

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 

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

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?

Re: Vision for the first semester of 2016

[Jacob Carlborg via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Jacob Carlborg via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[tsbockman via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 20:38:16 UTC, tsbockman wrote:
It's not like you could just reallocate all the effort that 
goes into Phobos towards the compiler and stuff.


My impression is that the majority of the contributors to Phobos 
are capable D programmers.


DMD is implemented in D now, no longer C++, so with refactoring 
and documentation I think a lot more programmers are qualified to 
hack on the compiler.

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote:
Also, you skipped past the "uninterested" part - this is a 
volunteer project, remember?


I didn't think it was a relevant argument as you can still write 
libraries for distribution. Keep in mind that the standard 
library has to be maintained and API's cannot easily be 
redesigned because of backwards compatibility.


Even if C/C++ have small standard libraries they provide a 
depressing amount of low quality functionality that one should 
avoid. But it is kept in for backwards compatibility and 
sometimes even updated and extended...


That not a good thing.

Re: Vision for the first semester of 2016

[tsbockman via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 21:47:41 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote:
Also, you skipped past the "uninterested" part - this is a 
volunteer project, remember?


I didn't think it was a relevant argument as you can still 
write libraries for distribution. Keep in mind that the 
standard library has to be maintained and API's cannot easily 
be redesigned because of backwards compatibility.


Even if C/C++ have small standard libraries they provide a 
depressing amount of low quality functionality that one should 
avoid. But it is kept in for backwards compatibility and 
sometimes even updated and extended...


That not a good thing.


There are certainly disadvantages to the standard library model 
of distribution and maintenance.


On the other hand:

1) The prospect of getting something into the standard library is 
a huge motivator for (at least some) potential contributors.


Why? Because building a library that no one knows about/trusts is 
wasted effort. Getting something into `std` is among the most 
effective forms of marketing available, and requires little 
non-programming-related skill or effort on the part of the 
contributor.


2) Standard libraries don't enforce backwards compatibility (and 
high code quality in general) just for the sake of bureaucracy - 
they do so because these are highly desirable characteristics for 
basic infrastructure. People shouldn't have to rewrite their 
entire stack every 6 months just because someone thought of a 
better API for some low-level component.


Making it through D's formal review process typically raises code 
quality quite a lot, and the knowledge that backwards 
compatibility is a high priority makes outsiders much more likely 
to invest in actually using a library module.


In short, while you make some valid points, your analysis seems 
very lopsided; it completely glosses over all of the positives 
associated with the status quo.

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:
1) The prospect of getting something into the standard library 
is a huge motivator for (at least some) potential contributors.


I am not sure if that is the right motivation. Sounds like recipe 
for bloat. Good libraries evolve from being used in real 
applications. Many applications.


characteristics for basic infrastructure. People shouldn't have 
to rewrite their entire stack every 6 months just because 
someone thought of a better API for some low-level component.


Then don't use libraries from unreliable teams.

Making it through D's formal review process typically raises 
code quality quite a lot, and the knowledge that backwards 
compatibility is a high priority makes outsiders much more 
likely to invest in actually using a library module.


Code quality is one thing, but if it has not been used in many 
applications, how can you then know if the abstraction is 
particularly useful?


There is nothing wrong with having a set of recommended 
libraries, e.g. a DSP library with FFT. But having things like 
FFT in the standard library is just crap. Even Apple does not do 
that, they have a separate library called Accelerate for such 
things. There is no way you can have the same interface for FFT 
across platforms. The structure of the data is different, the 
accuracy is different, all for max performance.


In general the standard library should just be the most basic 
things, even file system support is tricky for a system level 
programming language. For instance, on some cloud platforms you 
don't get to read/write parts of a file. You do it as one big 
atomic write/read.

Re: Vision for the first semester of 2016

[tsbockman via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:
characteristics for basic infrastructure. People shouldn't 
have to rewrite their entire stack every 6 months just because 
someone thought of a better API for some low-level component.


Then don't use libraries from unreliable teams.


Just using the standard library whenever possible is a simple and 
efficient way of accomplishing this - if the standard library 
actually has anything in it...


Making it through D's formal review process typically raises 
code quality quite a lot, and the knowledge that backwards 
compatibility is a high priority makes outsiders much more 
likely to invest in actually using a library module.


Code quality is one thing, but if it has not been used in many 
applications, how can you then know if the abstraction is 
particularly useful?


This is why requiring modules to spend some time on DUB and/or in 
`std.experimental` before freezing the API is important.


In general the standard library should just be the most basic 
things, even file system support is tricky for a system level 
programming language. For instance, on some cloud platforms you 
don't get to read/write parts of a file. You do it as one big 
atomic write/read.


Targeting 100% generality with APIs is pretty much always a bad 
idea.


Standard libary modules should endeavor to meet the needs of at 
least, say, 80% of potential users; they're not supposed to 
completely eliminate the need for specialized third-party 
libraries entirely. This is OK, because if you don't use a 
module, the compiler won't include it in the final executable.

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 23:04:57 UTC, tsbockman wrote:
This is why requiring modules to spend some time on DUB and/or 
in `std.experimental` before freezing the API is important.


Well, there aren't enough D applications written to ensure the 
usefulness of the API. Just take a look at widely adopted 
frameworks, they are "the one true thing" for a few years with 
100s or 1000s of applications using them. However as applications 
grow problems emerge. What happens? The entire framework is 
scrapped and replaced with something else.


Targeting 100% generality with APIs is pretty much always a bad 
idea.


Making a system level programming library based on what a current 
PC operating systems offers is also a bad idea. On Apple systems 
you are supposed to no longer use paths, but switch to URLs for 
files. Ok, you can do that by requiring URLs on all platforms, 
but what if you designed the API 10 years ago?


Operating systems changes, hardware changes. System level 
programming languages shouldn't provide an abstract machine, 
unlike the JVM.


I'm not at all convinced that D isn't tied too heavily to 
x86/POSIX/Windows. It isn't obvious that future systems will 
bother with POSIX.

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

Or let me put it this way. If the standard library requires 
POSIX, then it isn't really a standard library, but a POSIX 
abstraction library...

Re: Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Russel Winder via Digitalmars-d-announce]

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.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 01/25/2016 02:03 AM, Russel Winder via Digitalmars-d-announce wrote:

If the Python, Rust, Go, etc. stories tell us anything, it is that the
days of "batteries included" distributions is long, long dead. DVCS
changes the game.


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

Re: Vision for the first semester of 2016

[maik klein via Digitalmars-d-announce]

On Monday, 25 January 2016 at 13:08:18 UTC, Rory McGuire wrote:
On Mon, Jan 25, 2016 at 2:46 PM, Andrei Alexandrescu via 
Digitalmars-d-announce  
wrote:


On 01/25/2016 04:17 AM, Rory McGuire via 
Digitalmars-d-announce wrote:




Looking at the way we have things now, it would actually be 
quite simple to make two downloads, one with everything and 
one with the bare minimum.


If we changed phobos to compile like the recent vibe.d 
version does then we can even pick and choose sections of 
phobos. I suppose "he who has the vision" can do either type 
of release with our current tools.




What would be the benefits of this? My knee-jerk reaction is 
this is a large and disruptive project with no palpable 
benefits. -- Andrei



Yep, thats kind of what I was saying in the end. If someone 
wanted to they could make such a release independently.


I'm trying to hack on the compiler, personally I wish all those 
with the know how would put their efforts into documenting how 
the compiler works and what the different parts do, that way we 
could have more contributors.


+1 On lifetime management and tooling. I would like to see a lot 
of improvements for DCD also tools for refactoring would also be 
extremely useful.


As for splitting up everything into small packages, I don't think 
D is there yet. I am still new but I already found several 
libraries that I wanted to use that not follow the "official" D 
Style guide.


I would not want to include N different libraries that use N 
different coding styles. Look at Rust for example, you will find 
that pretty much every library uses the "official" style guide.


I think that is because it is mostly "enforced" by the compiler 
as a warning.


I really don't care how I write my code, but I care deeply about 
consistency.


Another point is that I couldn't find any metaprogramming library 
for D yet. Yes there is std.meta but it is extremely lacking, 
this is quite obvious if you look into the std.


For example in "zip"

return mixin (q{ElementType(%(.moveAt(ranges[%s], n)%|, 
%))}.format(iota(0, R.length)));


This could be easily expressed as a general metafunction. Also 
std.meta mostly focusses on compile time stuff but I don't think 
there is anything for a "Tuple".


Some inspiration could be found here 
https://github.com/boostorg/hana

Re: Vision for the first semester of 2016

[Andrew Edwards via Digitalmars-d-announce]

On Monday, 25 January 2016 at 10:53:29 UTC, Jacob Carlborg wrote:

On 2016-01-25 07:39, Andrew Edwards wrote:

I truly doubt that. It would be truly amazing if that were to 
occur but
history has proven otherwise. The sentiment was expressed so 
many times
that Walter was finally moved to sanction DWT as the official 
GUI for D
in 2006. Even a newsgroup was made for it. It's ten years 
later. DWT

anyone?


DWT is still working perfectly fine. Just compiled it recently 
with the latest beta, 2.070.


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.

Re: Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 01/25/2016 04:17 AM, Rory McGuire via Digitalmars-d-announce wrote:


Looking at the way we have things now, it would actually be quite simple
to make two downloads, one with everything and one with the bare minimum.

If we changed phobos to compile like the recent vibe.d version does then
we can even pick and choose sections of phobos. I suppose "he who has
the vision" can do either type of release with our current tools.


What would be the benefits of this? My knee-jerk reaction is this is a 
large and disruptive project with no palpable benefits. -- Andrei

Re: Vision for the first semester of 2016

[Rory McGuire via Digitalmars-d-announce]

On Mon, Jan 25, 2016 at 2:46 PM, Andrei Alexandrescu via
Digitalmars-d-announce  wrote:

> On 01/25/2016 04:17 AM, Rory McGuire via Digitalmars-d-announce wrote:
>
>>
>> Looking at the way we have things now, it would actually be quite simple
>> to make two downloads, one with everything and one with the bare minimum.
>>
>> If we changed phobos to compile like the recent vibe.d version does then
>> we can even pick and choose sections of phobos. I suppose "he who has
>> the vision" can do either type of release with our current tools.
>>
>
> What would be the benefits of this? My knee-jerk reaction is this is a
> large and disruptive project with no palpable benefits. -- Andrei
>
>
Yep, thats kind of what I was saying in the end. If someone wanted to they
could make such a release independently.

I'm trying to hack on the compiler, personally I wish all those with the
know how would put their efforts into documenting how the compiler works
and what the different parts do, that way we could have more contributors.

Re: Vision for the first semester of 2016

[JohnCK via Digitalmars-d-announce]

On Monday, 25 January 2016 at 16:34:15 UTC, Daniel Kozak wrote:

I guess you mean GUI not IDE?


Yes GUI... my fault, thanks!

JohnCK.

Re: Vision for the first semester of 2016

[Joakim via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[JohnCK via Digitalmars-d-announce]

On Monday, 25 January 2016 at 06:39:54 UTC, Andrew Edwards wrote:

On Monday, 25 January 2016 at 03:21:51 UTC, Puming 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


[snip]

For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide seems a good candidate(native D, 
crossplatform). A good official supported GUI library will 
attract many people.


I truly doubt that. It would be truly amazing if that were to 
occur but history has proven otherwise. The sentiment was 
expressed so many times that Walter was finally moved to 
sanction DWT as the official GUI for D in 2006. Even a 
newsgroup was made for it. It's ten years later. DWT anyone?


Aurora was a recent attempt that was shelved for the sole 
author's personal reasons. Result?


Sadly, dlangui/dlangide is no different. It has one developer. 
If that individual gets discouraged, like so many others have 
so far, what becomes of it?


Until members of the community starts combining efforts and 
working together to improve the situation, it will not improve. 
You have Adam working on working on simpledisplay, Mike working 
on Derelict, Felix working on three-d, Vladimir working on 
ae-graphics, Martin on freeimage, Vadim on dlangui/dlangide and 
who knows what else is out there in the wood works

...
I'm convinced that without such a deliberate effort, this 
situation will not change for years to come. Even if a 
particular library is dubbed "The One." Like I've said earlier, 
that was already done ten years ago.



Well, I think the question is: IDE is a main thing today? If you 
take the languages that emerged along the years, some of them are 
backed most on web toolkit/Internet.


Please don't get me wrong and I'm not saying this is NOT 
important. But today I think perhaps this kind of thing is 
turning into a niche.


I think vibe.d or whatever web toolkit should get more attention.

JohnCK.

Re: Vision for the first semester of 2016

[Russel Winder via Digitalmars-d-announce]

On Mon, 2016-01-25 at 15:47 +, 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.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 26/01/16 5:49 AM, Russel Winder via Digitalmars-d-announce wrote:

On Mon, 2016-01-25 at 20:34 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:



[…]

I had a long post replying to Russel and to put it bluntly, its just
wrong.
We are most definitely losing people simply because they expect
certain
code in the standard library. Like windowing and image.
Things like sockets are lower on their priority list.


It sounds like we will just have to disagree. Either than or agree that
you are wrong. ;-)

Most languages benefit from libraries that wrap and abstract OS APIs,
everything else can be handled by libraries (many of them) as long as
there is a single central resource that enables people to find and
trivially use. This message comes from Rust, Ceylon, other JDK
languages, and Python. Go is weird. The counter example is C++. D just
needs to get it's Dub act together properly.


In their mind we are not even a 'programming language'.


Actually I think the core problem is that there is fashion and hype
around D. By simple observation Go and Rust got huge impetus via hype.
This led to a huge amount of activity most of which died a death, but
left a huge acceleration of real traction. Whilst usage figures are
dwarfed by Java, C, C++, and Python, Go and Rust have huge distributed
activity bases. By sheer volume of activity some good stuff appears.
Especially the stuff that gets funded, because some company is taking a
punt.

Consider the one obvious case of Cloudflare. Originally a PHP company,
Go was introduced by guerilla processes, and now Go is central to their
operation. Such they they fund meetings and conferences. There are many
other companies using Go who put money into meetings, conferences,
general marketing, etc. because they want the best programmers. I
suspect the same will happen with Rust in a couple of years. It is
already the case with Python.

This is the core of the issue with D for me: there isn't enough
corporate activity and will to put money into the D milieu.


Phobos does need to be bigger, but not fully inclusive.
If most people won't use something, don't add it.


Wouldn't it be better to be explicit about what has to be in Phobos and
what can be separate? Let me start a list:

Data structures that are not in the language. Phobos more or less has
most of the core ones. The job here is to define an architecture, which
is has in ranges.

OS APIs. The point here is to abstract away from Windows, OSX, Linux,
UNIX,… I am not sure Linux DVB API should be in here, it is more
threads, input/output, networking, memory management. Phobos host most
stuff here already doesn't it?


So windowing, image library and audio handling.
They are core to any modern OS.

It wasn't until very recently that Windows Server ripped out all of the 
GUI aspects of its sdk for core edition.



Signals and slots systems so as to be able to write asynchronous
systems.

Concurrency and Parallelism libraries.

Not a lot else.


Sure there is arguments against this, but there is a certain amount
we
must standardize and agree upon as a community. Phobos most certainly
is
the place to do this. Otherwise we will be going round in circles for
a
much longer period then we should and not growing much.


What needs to be standardized? Data structure architecture. Already in
Phobos. Cross platform Input/Output. Already in Phobos.

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.

In so many ways vibe.d shows what can be right about D, and graphics
all that is wrong.

Of course in the end D just does not have the corporate backing that
Go, Rust, Python, Java, etc. are getting. Until that happens plus ça
change, plus c'est la même chose.

Re: Vision for the first semester of 2016

[Russel Winder via Digitalmars-d-announce]

On Mon, 2016-01-25 at 20:34 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:
> 
[…]
> I had a long post replying to Russel and to put it bluntly, its just
> wrong.
> We are most definitely losing people simply because they expect
> certain 
> code in the standard library. Like windowing and image.
> Things like sockets are lower on their priority list.

It sounds like we will just have to disagree. Either than or agree that
you are wrong. ;-)

Most languages benefit from libraries that wrap and abstract OS APIs,
everything else can be handled by libraries (many of them) as long as
there is a single central resource that enables people to find and
trivially use. This message comes from Rust, Ceylon, other JDK
languages, and Python. Go is weird. The counter example is C++. D just
needs to get it's Dub act together properly. 

> In their mind we are not even a 'programming language'.

Actually I think the core problem is that there is fashion and hype
around D. By simple observation Go and Rust got huge impetus via hype.
This led to a huge amount of activity most of which died a death, but
left a huge acceleration of real traction. Whilst usage figures are
dwarfed by Java, C, C++, and Python, Go and Rust have huge distributed
activity bases. By sheer volume of activity some good stuff appears.
Especially the stuff that gets funded, because some company is taking a
punt. 

Consider the one obvious case of Cloudflare. Originally a PHP company,
Go was introduced by guerilla processes, and now Go is central to their
operation. Such they they fund meetings and conferences. There are many
other companies using Go who put money into meetings, conferences,
general marketing, etc. because they want the best programmers. I
suspect the same will happen with Rust in a couple of years. It is
already the case with Python.

This is the core of the issue with D for me: there isn't enough
corporate activity and will to put money into the D milieu.

> Phobos does need to be bigger, but not fully inclusive.
> If most people won't use something, don't add it.

Wouldn't it be better to be explicit about what has to be in Phobos and
what can be separate? Let me start a list:

Data structures that are not in the language. Phobos more or less has
most of the core ones. The job here is to define an architecture, which
is has in ranges.

OS APIs. The point here is to abstract away from Windows, OSX, Linux,
UNIX,… I am not sure Linux DVB API should be in here, it is more
threads, input/output, networking, memory management. Phobos host most
stuff here already doesn't it?

Signals and slots systems so as to be able to write asynchronous
systems.

Concurrency and Parallelism libraries.

Not a lot else.

> Sure there is arguments against this, but there is a certain amount
> we 
> must standardize and agree upon as a community. Phobos most certainly
> is 
> the place to do this. Otherwise we will be going round in circles for
> a 
> much longer period then we should and not growing much.

What needs to be standardized? Data structure architecture. Already in
Phobos. Cross platform Input/Output. Already in Phobos.

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.

In so many ways vibe.d shows what can be right about D, and graphics
all that is wrong.

Of course in the end D just does not have the corporate backing that
Go, Rust, Python, Java, etc. are getting. Until that happens plus ça
change, plus c'est la même chose.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Vision for the first semester of 2016

[Dicebot via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Rory McGuire via Digitalmars-d-announce]

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 +, 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.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@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...

?

Re: Vision for the first semester of 2016

[Dibyendu Majumdar via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Iain Buclaw via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Andrew Edwards via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Jacob Carlborg via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Rory McGuire via Digitalmars-d-announce]

On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
Digitalmars-d-announce  wrote:

> On 25/01/16 8:16 PM, tsbockman wrote:
>
>> On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:
>>
>>> The strategy should be "get rid of anything in Phobos that can be put
>>> out as a separate library".
>>>
>>
>> This makes no sense as a standard: since neither DMD nor druntime is
>> allowed to depend upon Phobos, everything in Phobos *could* be put into
>> a separate library.
>>
>
> I had a long post replying to Russel and to put it bluntly, its just wrong.
> We are most definitely losing people simply because they expect certain
> code in the standard library. Like windowing and image.
> Things like sockets are lower on their priority list.
>
> In their mind we are not even a 'programming language'.
>
> Phobos does need to be bigger, but not fully inclusive.
> If most people won't use something, don't add it.
>
> Sure there is arguments against this, but there is a certain amount we
> must standardize and agree upon as a community. Phobos most certainly is
> the place to do this. Otherwise we will be going round in circles for a
> much longer period then we should and not growing much.
>

I'm going to quote you there: to put it bluntly you are plain wrong.

We do not, and no one does, need a kitchen sink standard library. Look at
python, look at Go, these are two of the fastest growing languages out
there. They are:
- Extremely easy to pick up and use.
- Have excellent documentation and simple naming conventions
- Have fantastic 3rd party open source libraries

How does one find the "right" library for a task?
- The community refers devs to their preferred / popular libs
- There are excellent tutorials / how-tos that show case the library

If we spent less time fussing of what gets into phobos and more time making
good libraries for code.dlang.org and let the best ones win out we'd get
much better stuff much quicker.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 9:21 PM, Rory McGuire via Digitalmars-d-announce wrote:


On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
Digitalmars-d-announce > wrote:

On 25/01/16 8:16 PM, tsbockman wrote:

On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:

The strategy should be "get rid of anything in Phobos that
can be put
out as a separate library".


This makes no sense as a standard: since neither DMD nor druntime is
allowed to depend upon Phobos, everything in Phobos *could* be
put into
a separate library.


I had a long post replying to Russel and to put it bluntly, its just
wrong.
We are most definitely losing people simply because they expect
certain code in the standard library. Like windowing and image.
Things like sockets are lower on their priority list.

In their mind we are not even a 'programming language'.

Phobos does need to be bigger, but not fully inclusive.
If most people won't use something, don't add it.

Sure there is arguments against this, but there is a certain amount
we must standardize and agree upon as a community. Phobos most
certainly is the place to do this. Otherwise we will be going round
in circles for a much longer period then we should and not growing much.


I'm going to quote you there: to put it bluntly you are plain wrong.

We do not, and no one does, need a kitchen sink standard library. Look
at python, look at Go, these are two of the fastest growing languages
out there. They are:
- Extremely easy to pick up and use.
- Have excellent documentation and simple naming conventions
- Have fantastic 3rd party open source libraries


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.


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.


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.


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.

The community in general misses the point here time and time again.
It wasn't until recently that Adam saw how bad things were just to add 
some context.



How does one find the "right" library for a task?
- The community refers devs to their preferred / popular libs
- There are excellent tutorials / how-tos that show case the library

If we spent less time fussing of what gets into phobos and more time
making good libraries for code.dlang.org  and let
the best ones win out we'd get much better stuff much quicker.


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.

Re: Vision for the first semester of 2016

[Robert M. Münch via Digitalmars-d-announce]

On 2016-01-25 07:03:35 +, Russel Winder via Digitalmars-d-announce said:


Phobos the library needs to go to be replaced by a library search and
use system. Oh we already have one, Dub.

The strategy should be "get rid of anything in Phobos that can be put
out as a separate library".


I see it exactly the other way: I want phobos to provide 90% of 
everything I need out-of-the-box. The linker will only bring in stuff I 
use and the rest is left out. So, what's the problem?


I just don't want to walk around until I find out, which parts 
(external libs) fit together just to cover the common 90%. That's 
wasting time.


Make it as simple as possible to get things done. Install, code, 
compile, deliver. That's it. One EXE, done.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Vision for the first semester of 2016

[Rory McGuire via Digitalmars-d-announce]

On Mon, Jan 25, 2016 at 10:31 AM, Rikki Cattermole via
Digitalmars-d-announce  wrote:

> On 25/01/16 9:21 PM, Rory McGuire via Digitalmars-d-announce wrote:
>
>>
>> On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
>> Digitalmars-d-announce > > wrote:
>>
>> On 25/01/16 8:16 PM, tsbockman wrote:
>>
>> On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:
>>
>> The strategy should be "get rid of anything in Phobos that
>> can be put
>> out as a separate library".
>>
>>
>> This makes no sense as a standard: since neither DMD nor druntime
>> is
>> allowed to depend upon Phobos, everything in Phobos *could* be
>> put into
>> a separate library.
>>
>>
>> I had a long post replying to Russel and to put it bluntly, its just
>> wrong.
>> We are most definitely losing people simply because they expect
>> certain code in the standard library. Like windowing and image.
>> Things like sockets are lower on their priority list.
>>
>> In their mind we are not even a 'programming language'.
>>
>> Phobos does need to be bigger, but not fully inclusive.
>> If most people won't use something, don't add it.
>>
>> Sure there is arguments against this, but there is a certain amount
>> we must standardize and agree upon as a community. Phobos most
>> certainly is the place to do this. Otherwise we will be going round
>> in circles for a much longer period then we should and not growing
>> much.
>>
>>
>> I'm going to quote you there: to put it bluntly you are plain wrong.
>>
>> We do not, and no one does, need a kitchen sink standard library. Look
>> at python, look at Go, these are two of the fastest growing languages
>> out there. They are:
>> - Extremely easy to pick up and use.
>> - Have excellent documentation and simple naming conventions
>> - Have fantastic 3rd party open source libraries
>>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> The community in general misses the point here time and time again.
> It wasn't until recently that Adam saw how bad things were just to add
> some context.
>
> How does one find the "right" library for a task?
>> - The community refers devs to their preferred / popular libs
>> - There are excellent tutorials / how-tos that show case the library
>>
>> If we spent less time fussing of what gets into phobos and more time
>> making good libraries for code.dlang.org  and let
>> the best ones win out we'd get much better stuff much quicker.
>>
>
> 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.
>
>

Ouch yes, seen that before. I just would prefer the base library to be
exactly that a base. In fact if dub came with dmd, or if you downloaded dub
and it could install dmd/gdc/ldc I would be much happier, phobos could be
just another library on code.dlang.org. That why the one app to rule them
all could just be dub and newbies and veterans alike could be happy that
their needed libraries were just there. Something like:
- download dub
- double click installer
- present with options to install, defaults to dmd and phobos must be
installed (if not found)
  - other option to create blank project
  - opens project with a basic ide that uses dcd etc and allows compile and
run with a simple example that outputs to a console and opens a window with
the D logo.

(Just thinking out loud) :D


PS: Can you make sure its easy to do transparent shaped windows in your
bare bones windowing implementation?

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 9:57 PM, Rory McGuire via Digitalmars-d-announce wrote:


On Mon, Jan 25, 2016 at 10:31 AM, Rikki Cattermole via
Digitalmars-d-announce > wrote:

On 25/01/16 9:21 PM, Rory McGuire via Digitalmars-d-announce wrote:


On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
Digitalmars-d-announce 
>> wrote:

 On 25/01/16 8:16 PM, tsbockman wrote:

 On Monday, 25 January 2016 at 07:03:35 UTC, Russel
Winder wrote:

 The strategy should be "get rid of anything in
Phobos that
 can be put
 out as a separate library".


 This makes no sense as a standard: since neither DMD
nor druntime is
 allowed to depend upon Phobos, everything in Phobos
*could* be
 put into
 a separate library.


 I had a long post replying to Russel and to put it bluntly,
its just
 wrong.
 We are most definitely losing people simply because they expect
 certain code in the standard library. Like windowing and image.
 Things like sockets are lower on their priority list.

 In their mind we are not even a 'programming language'.

 Phobos does need to be bigger, but not fully inclusive.
 If most people won't use something, don't add it.

 Sure there is arguments against this, but there is a
certain amount
 we must standardize and agree upon as a community. Phobos most
 certainly is the place to do this. Otherwise we will be
going round
 in circles for a much longer period then we should and not
growing much.


I'm going to quote you there: to put it bluntly you are plain wrong.

We do not, and no one does, need a kitchen sink standard
library. Look
at python, look at Go, these are two of the fastest growing
languages
out there. They are:
- Extremely easy to pick up and use.
- Have excellent documentation and simple naming conventions
- Have fantastic 3rd party open source libraries


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.

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.

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.

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.

The community in general misses the point here time and time again.
It wasn't until recently that Adam saw how bad things were just to
add some context.

How does one find the "right" library for a task?
- The community refers devs to their preferred / popular libs
- There are excellent tutorials / how-tos that show case the library

If we spent less time fussing of what gets into phobos and more time
making good libraries for code.dlang.org 
 and let
the best ones win out we'd get much better stuff much quicker.


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.



Ouch yes, seen that before. I just would prefer the base library to be
exactly that a base. In fact if dub came with dmd, or if you downloaded
dub and it could install dmd/gdc/ldc I would be much happier, phobos
could be just another library on code.dlang.org .
That why the one app to rule them all could just be dub and newbies and
veterans alike could be happy that their needed libraries were just
there. Something like:
- download dub
- double click installer
- present with options to install, defaults to dmd and phobos must be

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

I've had a bit more of a looksie into splash screens and I think I would 
prefer if it was completely separate actually.

Its not too hard, but its has semi incompatible features as to a window.

Re: Vision for the first semester of 2016

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-01-25 07:39, Andrew Edwards wrote:


I truly doubt that. It would be truly amazing if that were to occur but
history has proven otherwise. The sentiment was expressed so many times
that Walter was finally moved to sanction DWT as the official GUI for D
in 2006. Even a newsgroup was made for it. It's ten years later. DWT
anyone?


DWT is still working perfectly fine. Just compiled it recently with the 
latest beta, 2.070.


--
/Jacob Carlborg

Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 3:37 PM, Andrei Alexandrescu wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


There is a couple of things I want on there.

1. scope to be fixed and fully implemented
   (I'll bring some use cases to the table)
2. @assumenogc or something similar.
   That way IAllocator can be @nogc. Which to me is a requirement 
before it is out of experimental.


Number 1 is the most important for me. Otherwise there will be no 
review/PR for image library this year.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 4:13 PM, Andrei Alexandrescu wrote:

On 01/24/2016 10:07 PM, Rikki Cattermole wrote:


1. scope to be fixed and fully implemented
(I'll bring some use cases to the table)
2. @assumenogc or something similar.
That way IAllocator can be @nogc. Which to me is a requirement
before it is out of experimental.


Both are under the larger headline "Memory Management." -- Andrei


Okay, I like specifics since then you can tick it off for next round ;)

Re: Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 01/24/2016 10:07 PM, Rikki Cattermole wrote:


1. scope to be fixed and fully implemented
(I'll bring some use cases to the table)
2. @assumenogc or something similar.
That way IAllocator can be @nogc. Which to me is a requirement
before it is out of experimental.


Both are under the larger headline "Memory Management." -- Andrei

Re: Vision for the first semester of 2016

[tsbockman via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


Something went wrong here:

We fell short of our 2000 pull requests goal in H2 2015. We 
have had only 1 1378 pull requests.


In addition to the extraneous "1", the link is bad: "No results 
matched your search."

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


For PRs, I suggest the goal to be number of PRs MERGED instead of 
created. That may provide the core team a subconsious incentive 
to look at long pending PRs and hit a good cycle.


For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide seems a good candidate(native D, crossplatform). 
A good official supported GUI library will attract many people.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 4:21 PM, Puming 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


For PRs, I suggest the goal to be number of PRs MERGED instead of
created. That may provide the core team a subconsious incentive to look
at long pending PRs and hit a good cycle.

For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
seems a good candidate(native D, crossplatform). A good official
supported GUI library will attract many people.


That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on both) there 
is no way a GUI toolkit is going in. And from what I know there will be 
a LOT of work to update it.

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole 
wrote:

On 25/01/16 4:21 PM, Puming 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


For PRs, I suggest the goal to be number of PRs MERGED instead 
of
created. That may provide the core team a subconsious 
incentive to look

at long pending PRs and hit a good cycle.

For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide
seems a good candidate(native D, crossplatform). A good 
official

supported GUI library will attract many people.


That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on 
both) there is no way a GUI toolkit is going in. And from what 
I know there will be a LOT of work to update it.


Well I'm not saying that a GUI toolkit should go into Phobos.
I'd rather it stand alone, while taking some official support, 
say, link in D frontpage(like visualD).

Re: Vision for the first semester of 2016

[Andrew Edwards via Digitalmars-d-announce]

On Monday, 25 January 2016 at 03:21:51 UTC, Puming 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


[snip]

For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide seems a good candidate(native D, 
crossplatform). A good official supported GUI library will 
attract many people.


I truly doubt that. It would be truly amazing if that were to 
occur but history has proven otherwise. The sentiment was 
expressed so many times that Walter was finally moved to sanction 
DWT as the official GUI for D in 2006. Even a newsgroup was made 
for it. It's ten years later. DWT anyone?


Aurora was a recent attempt that was shelved for the sole 
author's personal reasons. Result?


Sadly, dlangui/dlangide is no different. It has one developer. If 
that individual gets discouraged, like so many others have so 
far, what becomes of it?


Until members of the community starts combining efforts and 
working together to improve the situation, it will not improve. 
You have Adam working on working on simpledisplay, Mike working 
on Derelict, Felix working on three-d, Vladimir working on 
ae-graphics, Martin on freeimage, Vadim on dlangui/dlangide and 
who knows what else is out there in the wood works. All of this 
is admirable and appreciated but imagine what would be possible 
if these minds teamed up, mapped out a graphic solution for the 
language and united efforts in implementing it!


I'm convinced that without such a deliberate effort, this 
situation will not change for years to come. Even if a particular 
library is dubbed "The One." Like I've said earlier, that was 
already done ten years ago.

Re: Vision for the first semester of 2016

[Russel Winder via Digitalmars-d-announce]

On Mon, 2016-01-25 at 16:49 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:
> 
[…]
> That won't be happening anytime soon.
> Until we have image and windowing in Phobos (I'm working on both)
> there 
> is no way a GUI toolkit is going in. And from what I know there will
> be 
> a LOT of work to update it.

How about we have a D library infrastructure such that Phobos gets
smaller and smaller providing only absolutely necessary core things
over druntime.

If the Python, Rust, Go, etc. stories tell us anything, it is that the
days of "batteries included" distributions is long, long dead. DVCS
changes the game.

Phobos the library needs to go to be replaced by a library search and
use system. Oh we already have one, Dub.

The strategy should be "get rid of anything in Phobos that can be put
out as a separate library".
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Vision for the first semester of 2016

[tsbockman via Digitalmars-d-announce]

On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:
The strategy should be "get rid of anything in Phobos that can 
be put

out as a separate library".


This makes no sense as a standard: since neither DMD nor druntime 
is allowed to depend upon Phobos, everything in Phobos *could* be 
put into a separate library.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 7:39 PM, Andrew Edwards wrote:

On Monday, 25 January 2016 at 03:21:51 UTC, Puming 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


[snip]


For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
seems a good candidate(native D, crossplatform). A good official
supported GUI library will attract many people.


I truly doubt that. It would be truly amazing if that were to occur but
history has proven otherwise. The sentiment was expressed so many times
that Walter was finally moved to sanction DWT as the official GUI for D
in 2006. Even a newsgroup was made for it. It's ten years later. DWT
anyone?

Aurora was a recent attempt that was shelved for the sole author's
personal reasons. Result?

Sadly, dlangui/dlangide is no different. It has one developer. If that
individual gets discouraged, like so many others have so far, what
becomes of it?

Until members of the community starts combining efforts and working
together to improve the situation, it will not improve. You have Adam
working on working on simpledisplay, Mike working on Derelict, Felix
working on three-d, Vladimir working on ae-graphics, Martin on
freeimage, Vadim on dlangui/dlangide and who knows what else is out
there in the wood works. All of this is admirable and appreciated but
imagine what would be possible if these minds teamed up, mapped out a
graphic solution for the language and united efforts in implementing it!

I'm convinced that without such a deliberate effort, this situation will
not change for years to come. Even if a particular library is dubbed
"The One." Like I've said earlier, that was already done ten years ago.


I agree.
This is why everything I'm doing right now for windowing and image 
library builds upon what has come before but in a Phobos quality way.


Unless it is in Phobos, its not good enough as a base IMO.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 7:18 PM, Puming wrote:

On Monday, 25 January 2016 at 05:50:34 UTC, Rikki Cattermole wrote:


I want us to hold off on that as well.


I agree that we need a more solid base.


I want people to really have a go with making GUI toolkits in D
without the worry about how to do the cross platformy technical things.


Is dlangui a good start on this?


No, too much code for what the base needs.
For windowing you want it just above what the OS does in a cross 
platform abstracted way.


So no controls support or any other gruff that a GUI toolkit provides.



We just don't know what could be done yet and I'm looking forward to
finding out.


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


No, it already has its core code. By in large what you want to innovate 
is the core code, not what a specific control does.


I'm not saying dlangui is the wrong way to go. We just don't know which 
way is right just yet and that is ok.

Re: Vision for the first semester of 2016

[Chris Wright via Digitalmars-d-announce]

On Sun, 24 Jan 2016 21:37:40 -0500, Andrei Alexandrescu wrote:

> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei

I'm not fond of the militaristic terminology for participants. Novice, 
adept, master, maybe?

The section on safety is pretty short. I'd like to see in it:
* Guidelines for what should be made @trusted in Phobos (should we trust 
Win/Posix API functions? should we only trust wrappers that take D arrays 
rather than pointers? can we, for instance, create a @trusted wrapper 
around curl?)
* Efficiency / safety tradeoff guidelines (should Phobos provide a 
slightly faster implementations of things that aren't @safe? In those 
cases, should it provide both @safe and fast alternatives?)
* @safe / @trusted IO as a goal

As is, there are a smattering of things in Phobos that aren't @safe but 
seem like they could or should be, with no explanation and no safe 
alternatives. I think almost all IO is @system. This makes it hard and 
sometimes confusing to try to write @safe code.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 6:47 PM, Puming wrote:

On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole wrote:

On 25/01/16 4:21 PM, Puming 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


For PRs, I suggest the goal to be number of PRs MERGED instead of
created. That may provide the core team a subconsious incentive to look
at long pending PRs and hit a good cycle.

For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
seems a good candidate(native D, crossplatform). A good official
supported GUI library will attract many people.


That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on both)
there is no way a GUI toolkit is going in. And from what I know there
will be a LOT of work to update it.


Well I'm not saying that a GUI toolkit should go into Phobos.
I'd rather it stand alone, while taking some official support, say, link
in D frontpage(like visualD).


I want us to hold off on that as well.
I want people to really have a go with making GUI toolkits in D without 
the worry about how to do the cross platformy technical things.


We just don't know what could be done yet and I'm looking forward to 
finding out.

Re: Vision for the first semester of 2016

[Jack Stouffer via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


My biggest issue with these documents is that they have good 
ideas but rarely have plans to achieve them. As a consequence, 
most of these documents say how half or more of the previous 
goals were not achieved.


I believe the best way to fix this is to simply have more focus. 
Have one large goal that can be broken down into smaller subsets, 
e.g. "2016 will be the year of a GC free Phobos". Something that 
has a very clear way of quantifying its success and a clear path 
to that goal.


Not that that the other things are not important, but if you 
constantly find yourself failing to meet your goals, the only 
rational option is to become more realistic in your plans.

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Monday, 25 January 2016 at 05:50:34 UTC, Rikki Cattermole 
wrote:


I want us to hold off on that as well.


I agree that we need a more solid base.

I want people to really have a go with making GUI toolkits in D 
without the worry about how to do the cross platformy technical 
things.


Is dlangui a good start on this?



We just don't know what could be done yet and I'm looking 
forward to finding out.


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