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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20160125/8b9685e9/attachment.sig>