www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D future ...

reply Benjiro <benjiro benjiro.com> writes:
I split this from the "Re: A betterC modular standard library?" 
topic because my response is will be too much off-topic but the 
whole thread is irking me the wrong way. I see some of the same 
argument coming up all the time, with a level of frequency.

D has not market:
-----------------

A lot of times people complain that D has no real audience / 
market. Is D the perfect system. No... But lets compare to those 
other languages shall we? Now this is my opinion, so take it with 
a bit of salt.

Go: Its is a "simple" language. But its forced restrictions at 
times are so annoying its saps all the fun out of the coding. Its 
not really C. Its more Basic on steroids. Unfortunately while Go 
has huge amount of traction and packages ( 70k from my count ), 
the quality is also... It has a few real gems those gems are a 
result of the mass amount of packages. It has its own market. A 
scripting replacement market mostly.

Crystal: Is pure Ruby focused. Again, it draws in a lot of people 
with a Ruby background. Interesting language that is already 
splitting away from Ruby comparability.

Nim/Julia/Numpy/Numba: Are very Python like focused. Nim will 
disagree but its very clear. Again, the focus seems to draw in 
more scripting language orientated people, mostly from the Python 
area.

Rust: Promotes itself to be better C but its simply a more 
complex language design. A over active amount of fans, that do 
not understand its complex. Less fun to get into. Reminds me too 
much of Perl.

D is C++ but improved/simplified. Its not to hard to get into, 
its more easy for anybody from a C background.

Take it from a guy that spend a large part of his life in PHP. I 
feel more at home with D, then with all the other languages. The 
moment you get over a few hurdles, it becomes a very easy 
language. My point is that D does fit in a specific market. It 
fits in between C++ and scripting languages like PHP ( that has a 
more C background ).

Its not going to convert a lot of C++ people. Sorry but its true. 
C++ has been evolving, the people who invested into C++ have very 
little advantage of going to D. The whole focus on C++ people 
marketing is simply wrong! Every time this gets mentioned in 
external forums, the language gets a pounding by people with the 
same argumentation. Why go for D when C++ 20xx version does it 
also.

Trusting a person with C like scripting language ( like PHP/Java 
) background into C++, well that is fun <sarcasm>. People always 
seem to say that D has no real advantage but it has. Its easier 
C++ for people who do not come from C/C++. Maybe i am downplaying 
this but for love of the gods, the focus is wrong. I am the same 
guy that complained a while ago about the website its examples 
being too "advanced" and it scares a big potential group of 
people away.

Community:
----------

But community wise there is a real issue. People are friendly and 
help out. But it feels like everybody is doing there own thing.

I see a lot of people arguing a lot about D and sorry to say but 
at times it sounds like a kindergarten. Walter/Andrei are right 
that updates and changes need to be focused on the standard 
library. Maybe its because people who use D are more into 
proprietary software, that there is less community response with 
work going into the library. But ... see below in Walter / Andrei 
section.

Library ( and runtime bloat ):
------------------------------

But it also does not diminish some of the requests. When i write 
a simple program that uses the socket, standard, string and conv 
library. All it does is open a TCP socket and send a response 
back. This is not supposed to take 2.4MB in memory, with a 1.2MB 
compiled executable ( 450kb o file ). Full blown Nginx uses only 
one MB more for its core in memory. For something so simple, its 
a little bit crazy.

When i make a plugin in Go 1.8, it uses 10KB. A plugin ( shared C 
library ) in D uses almost 200KB. Using C++ it results into 
another 10KB file. Maybe i am a total noob but some things make 
no sense. It gives me the impression that some massive run times 
are getting added or there is some major library bloat.

Library Standardization:
------------------------

Some of the proposals sounds very correct. The library needs to 
be split. Every module needs its own GIT. People need to be able 
to add standard modules ( after approval ).

No offense but where is the standard database library for D? 
There is none. That is just a load of bull. Anybody who wants to 
program in any language expect the language to have a standard 
database library! Not that you need to search the packages for a 
standard library. I have seen one man projects that have more 
standard library support then D.

Its one of the most basic packages. How about a simple web 
server? A lot of languages offer this by default. It gets people 
going. vibe.d is not a simple web server. It's not a standard 
package.

If you are a low level programmer, sure, you can write you way 
around it. Despite my PHP handicap i am writing a Sqlite wrapper 
for my work. I do not use 3th party packages because a) i do not 
know the code b) the fear that the work will be abandoned. I can 
excuse (a), when i know its the standard library because there 
will always be people willing to work on  the standard library.

Documentation:
--------------

I do not use it. Its such a mess to read with long paragraphs and 
a LOT of stuff not even documented. Like the whole C wrappers 
etc. My personal bible is simple: Google search for examples and 
Ali's book for some rare cases.

When i compare this to my PHP background. Hmmmm, what does x 
function do again. Google function. Webpage with X function. 
Links to related function. Examples. Clear simple answers.

This automated documentation generation is the same **** i see in 
other "new" languages. Impersonal is the word to describe it. 
Sure there is some tutorial in the documentation that way too 
long ( never hear of chapters? ) but a lot of that information 
needs to be with the functions.

Maybe other developers can make more heads or tails out of the 
API documentation but like i said, i do not use it. Every time i 
need a advanced feature its hardly documented. With references 
and text buildups that is just annoying.

Editor support:
---------------

What a struggle. Visual Studio C is probably the editor with the 
best 3th party support.

IntelliJ: Hardly any plugins. Limited to IntelliJ platform and 
not the rest.
Atom: Same issue, hardly any advanced D support.
Vim: Lets not go there.
3Th party D IDE's: A lot simply are designed for local working, 
white background ( uch ), etc...

I can go on. For me it has been a struggle to find the perfect 
editor. Extended IDE's like IntelliJ have hardly support. There 
are a lot of plugins to add D to editors but most are long time 
dead or incomplete.

Try remote editing D and see how much fun it is. Most Editors or 
IDE with proper remote edit ability, have lacking D supported 
plugins.

Too many need 3th party to do something that D needs to support 
from itself:

dcd - Used for auto completion
dfmt - Used for code formatting
dscanner - Used for static code linting
...

This needs to be in the default installation of dmd! It makes no 
sense that these are not included.


Future:
--------

You want D to have traction. Marketing, more library support, 
less focus on adding even more advanced features, fixing issues ( 
like better GC ), CTFE ( Stefan is dealing with that ), 
Documentation, better Editor support...

Walter / Andrei:
----------------

No offense guys, just something that i see in a lot of posts. The 
hinting at people to add more to the standard libraries. That 
little push. But frankly, its annoying when nothing gets done.

People complain about x feature. You tell people to add to the 
standard library or bring the project in. But anybody who has 
ever read this forum sees how adding things to the language is 
LONG process and a lot of times idea's get shot down very fast.

For the standard library there is no process as far as i can 
tell. Experimental at best, where code seems to have a nice long 
death.

Just needed to get this off my chest. The problems with D are 
LONG TIME known. Anybody who spends some time reading the forums 
sees the exact same things.

My advice Walter / Andrei: Stop trying to add new things to the 
code. It works. Its not going anywhere. There are no features 
that you can add, that people can not already do. Maybe it takes 
a few longer lines but those are not the issues.

Focus on improving the other issues like stated above. Maybe also 
deal with some of the speed  bloat issues. If you ask people to 
help, give them the motivation to do so.

Bring more projects into D. When you have people like Webfreak 
making workspace-d, to simply the installation of those almost 
required editor extensions, it tells you that D has a issue.


Ilya's proposals are too extreme and need a middle ground. But he 
is not wrong.

Seb posted a massive list of modules that can be standard 
candidates. And the response is more or less ignore it. People 
who work on Standard libraries are more motivated. Bring  them 
into the fold. But it seems that they simple get ignored.

Like i said, please work on standard libraries is not the answer. 
It does not motivate people ( especially when in the same text 
you end up breaking down people there proposals ). Maybe its not 
the intention but it comes over like this.

Why is there no forum part for proposals about libraries that get 
added to Phobos ( why is it even still called that. Call it 
standard library and be done with it. It only confuses new people 
). The current forum is a pure spam forum.

You need a Standard forum. With subbranches for std.xxx, std.xxx, 
std... Let people talk about improvements there. If people want 
to add a new branch, let them put up a proposal and do NOT 
mothball it for months in discussions.

Hell, the whole "D Programming Language - Development" forum is 
so much spam, it becomes almost useless. Its a distraction to 
post each issue there with 0 responses on 95%.

End Rant:
---------

Sorry for the long text but as somebody who has been reading the 
forums for a while now, its just annoying to see some of the 
bickering.

But i simply get frustrated seeing the direction where relative 
simple things get overlooked for more complex features! D already 
is a great language but it REALLY has issue on several 
departments. It does not need more boilerplate / expansion, it 
needs focus! Most of the points that i bring up are not that 
complex. But it takes a community manager / moderator to keep 
topics a bit more focused. Not somebody who will go into endless 
discussions with people ( not naming names ... Andrei ;) ). Sorry 
guys but it feels like you are too technical focused and not 
thinking about the bigger picture. Suggesting things does not 
work when nobody gives people the chance to prove themselves.

Give people the ability to add more to std.experimental. Give it 
its own forum part. Give people actual hope that there work can 
be added. I have seen several ex-D programmers, who complained 
about D regarding issues like this. If D wants to be a community 
project, then act like a community project. Because now, its just 
a contribution project where some people have easier access to 
add stuff and other walk against a brick wall of months ( and 
give up ).

Its late... already spend almost two hours writing this, that i 
was able to spend on writing actual code. And i am going to take 
a break from reading this forum, it sucks the life out of people 
and they spending all the time on bickering over details and 
eventually not getting a darn thing done. Already overworked at 
work + my own D project.
Dec 19 2016
next sibling parent reply Tommi <tommitissari hotmail.com> writes:
 I see a lot of people arguing a lot about D and sorry to say 
 but at times it sounds like a kindergarten. Walter/Andrei are 
 right that updates and changes need to be focused on the 
 standard library.


Improve the standard library!


 Some of the proposals sounds very correct. The library needs to 
 be split. Every module needs its own GIT. People need to be 
 able to add standard modules ( after approval ).


Split the standard library! Forget that no other language does it!


 No offense but where is the standard database library for D? 
 There is none. That is just a load of bull. Anybody who wants 
 to program in any language expect the language to have a 
 standard database library! Not that you need to search the 
 packages for a standard library. I have seen one man projects 
 that have more standard library support then D.


Add to the standard library!


 Its one of the most basic packages. How about a simple web 
 server? A lot of languages offer this by default. It gets 
 people going. vibe.d is not a simple web server. It's not a 
 standard package.


Add to the standard library!


 If you are a low level programmer, sure, you can write you way 
 around it. Despite my PHP handicap i am writing a Sqlite 
 wrapper for my work. I do not use 3th party packages because a) 
 i do not know the code b) the fear that the work will be 
 abandoned. I can excuse (a), when i know its the standard 
 library because there will always be people willing to work on  
 the standard library.


Add to the standard library!


 Documentation:
 --------------

 I do not use it.


Improve documentation!


 Editor support:
 ---------------
 Too many need 3th party to do something that D needs to support 
 from itself:

 dcd - Used for auto completion
 dfmt - Used for code formatting
 dscanner - Used for static code linting
 ...

 This needs to be in the default installation of dmd! It makes 
 no sense that these are not included.


Add to the standard distribution!


 No offense guys, just something that i see in a lot of posts. 
 The hinting at people to add more to the standard libraries. 
 That little push. But frankly, its annoying when nothing gets 
 done.


Don't add to the standard library!


 People complain about x feature. You tell people to add to the 
 standard library or bring the project in. But anybody who has 
 ever read this forum sees how adding things to the language is 
 LONG process and a lot of times idea's get shot down very fast.


Don't add to the standard library!


 For the standard library there is no process as far as i can 
 tell. Experimental at best, where code seems to have a nice 
 long death.


Don't use std.experimental! It's bad!


 Just needed to get this off my chest. The problems with D are 
 LONG TIME known. Anybody who spends some time reading the 
 forums sees the exact same things.

 My advice Walter / Andrei: Stop trying to add new things to the 
 code.


Don't add anything anywhere!


 It works. Its not going anywhere. There are no features that 
 you can add, that people can not already do. Maybe it takes a 
 few longer lines but those are not the issues.


Don't add features!


 Focus on improving the other issues like stated above.


Don't work on the compiler or standard library! Don't use your 
skills! Write documentation and learn how to do editor 
integration!


 Maybe also deal with some of the speed  bloat issues. If you 
 ask people to help, give them the motivation to do so.


Work on the speed bloat! Wait, what?

Tell people what do do!


 Bring more projects into D. When you have people like Webfreak 
 making workspace-d, to simply the installation of those almost 
 required editor extensions, it tells you that D has a issue.


Do marketing!


 Ilya's proposals are too extreme and need a middle ground. But 
 he is not wrong.

 Seb posted a massive list of modules that can be standard 
 candidates. And the response is more or less ignore it. People 
 who work on Standard libraries are more motivated. Bring  them 
 into the fold. But it seems that they simple get ignored.


Respond to people on the forums!


 Like i said, please work on standard libraries is not the 
 answer.


Don't add to the standard library!


 Why is there no forum part for proposals about libraries that 
 get added to Phobos ( why is it even still called that. Call it 
 standard library and be done with it. It only confuses new 
 people ). The current forum is a pure spam forum.


Work on the standard library! But discuss in a different forum!


 You need a Standard forum. With subbranches for std.xxx, 
 std.xxx, std... Let people talk about improvements there. If 
 people want to add a new branch, let them put up a proposal and 
 do NOT mothball it for months in discussions.


Add more forums!


 Hell, the whole "D Programming Language - Development" forum is 
 so much spam, it becomes almost useless. Its a distraction to 
 post each issue there with 0 responses on 95%.


The forum "D Programming Language - Development" is spam! Even 
though it does not exist!


 Sorry for the long text but as somebody who has been reading 
 the forums for a while now, its just annoying to see some of 
 the bickering.


Stop replaying on the forums!


 But i simply get frustrated seeing the direction where relative 
 simple things get overlooked for more complex features! D 
 already is a great language but it REALLY has issue on several 
 departments. It does not need more boilerplate / expansion, it 
 needs focus!


Add more focus!


 Most of the points that i bring up are not that complex. But it 
 takes a community manager / moderator to keep topics a bit more 
 focused.


More management!


 Not somebody who will go into endless discussions with people ( 
 not naming names ... Andrei ;) ).


Stop replaying on the forums!


 Sorry guys but it feels like you are too technical focused and 
 not thinking about the bigger picture. Suggesting things does 
 not work when nobody gives people the chance to prove 
 themselves.


Don't tell people what to do!


 Give people the ability to add more to std.experimental.


Do use std.experimental! It's good!


 Give it its own forum part.


More forums!


 Give people actual hope that there work can be added.


Add to the standard library!


 I have seen several ex-D programmers, who complained about D 
 regarding issues like this. If D wants to be a community 
 project, then act like a community project. Because now, its 
 just a contribution project where some people have easier 
 access to add stuff and other walk against a brick wall of 
 months ( and give up ).


Let everyone add to the standard library!


 Its late... already spend almost two hours writing this, that i 
 was able to spend on writing actual code. And i am going to 
 take a break from reading this forum, it sucks the life out of 
 people and they spending all the time on bickering over details 
 and eventually not getting a darn thing done. Already 
 overworked at work + my own D project.


Half of the paragraphs contradict the other half. Walter must 
headbutt himself in the face reading this.
Dec 19 2016
next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 20 December 2016 at 01:45:27 UTC, Tommi wrote:

 Half of the paragraphs contradict the other half. Walter must 
 headbutt himself in the face reading this.


You may want to try to understand all paragraphs together as a 
solid text.
Dec 19 2016
prev sibling next sibling parent reply Benjiro <benjiro benjiro.com> writes:
On Tuesday, 20 December 2016 at 01:45:27 UTC, Tommi wrote:

 Improve the standard library!

 Split the standard library! Forget that no other language does 
 it!

 Add to the standard library!
 Add to the standard library!
 Add to the standard library!

 Improve documentation!

 Add to the standard distribution!

 Don't add to the standard library!

 Don't add to the standard library!

 Don't use std.experimental! It's bad!


Yea, great idea... O wait... where are people going to add things 
again? O right ... Simply keep yelling add to std when NOBODY 
WANTS TO DO THAT. Just dump everything into the one git massive 
library with no more control of the author!!!

Did you not read that D has a different crowd. That a lot of 
people using D seem to be more into propitiatory code.

No, it does not work like that. You create separate gits that are 
part of a D library where the authors can write / maintain the 
code. Its easier on them, more easy to maintain because of 
separate bug trackers and it fits in with the whole forum std 
splits / dedicated forums.


 Don't add anything anywhere!

 Don't add features!

 Don't work on the compiler or standard library! Don't use your 
 skills! Write documentation and learn how to do editor 
 integration!

 Work on the speed bloat! Wait, what?

 Tell people what do do!

 Do marketing!

 Respond to people on the forums!


 Don't add to the standard library!

 Work on the standard library! But discuss in a different forum!


 Add more forums!

 Stop replaying on the forums!

 Add more focus!


 More management!

 Stop replaying on the forums!

 Don't tell people what to do!

 Do use std.experimental! It's good!

 More forums!

 Add to the standard library!

 Let everyone add to the standard library!

 Half of the paragraphs contradict the other half. Walter must 
 headbutt himself in the face reading this.


Read everything....

If you bothered reading what i write as a whole, you can clearly 
see where the focus points need to be and what is clearly 
lacking. They do not contradict each other. Only if you decide to 
strip them in each part and then comment like a wiseass.

Do what you want with your idiotic replies. Its this attitude 
that drives people away. You want people to help, well this is 
NOT the way to motivate people.

Simply keep yelling add to standard library when people do NOT 
want that. And no offense but D there standard library is one of 
the weakest among the new languages. Yet, there is code out there 
where people WANTED to add to the library that is rotting away 
simply because nobody here does anything beyond yelling:


 Add to the standard library!
 Add to the standard library!
 Add to the standard library!
 Add to the standard library!
 Add to the standard library!


Maybe you want to freaking ask the authors of for instants 
std.database etc why they feel unwilling to add it to the 
standard library git. And if you ever did project management, you 
know exactly where. People do not like to lose control over there 
projects. That is AGAIN why you need separate gits, under the D 
lang branch, but where the authors still have control over there 
code.

F*ck this. Its like talking to walls. Anyway, do what you want. I 
have my own projects to deal with and i can write around the 
lacking libraries, documentation etc. Unfortunately, not 
everybody can and its those people you are hurting with that 
wiseass attitude. Good luck getting new people motivated in D 
like that.
Dec 20 2016
next sibling parent reply qznc <qznc web.de> writes:
On Tuesday, 20 December 2016 at 08:41:21 UTC, Benjiro wrote:

 F*ck this. Its like talking to walls. Anyway, do what you want. 
 I have my own projects to deal with and i can write around the 
 lacking libraries, documentation etc. Unfortunately, not 
 everybody can and its those people you are hurting with that 
 wiseass attitude. Good luck getting new people motivated in D 
 like that.


What did you expect with a rant like that?

You vented your anger. This is fine. Some concrete actions were 
already taken (e.g. Andrei filed an issue about writeln). People 
should do this more often, because core-devs are blind to issues 
such as writeln documentation. They never look that up. Thanks 
for that!

However, into your rant mixed proposals in a "wiseass attitude" 
with lots of bikeshedding potential. Naturally, people react to 
that and shoot it down. If you want to do something like that 
again, my advice would be: Delay the proposals until the very end 
and write in a very humble way. Describing the problems precisely 
is worth more than coming up with ideas for a solution anyways.
Dec 20 2016
parent reply Benjiro <benjiro benjiro.com> writes:
On Tuesday, 20 December 2016 at 09:33:22 UTC, qznc wrote:

 What did you expect with a rant like that?


A rant... Well. Rants have a background.


 You vented your anger.


Actually, i did not vent any anger until this morning when i 
noticed the wiseass response. All the points i wrote yesterday 
are items that actually bother a lot more people. But those same 
people who complain about it, always get shutdown with that 
typical: Do it yourself response / Improve the standard library / 
...

Documentation:
--------------

If they want some concrete examples, here are few:

https://dlang.org/library/std/socket/tcp_socket.html

https://doc.rust-lang.org/std/net/struct.TcpListener.html

Notice how much more clean the Rust documentation is. I am only 
pulling that example because its something i looked up right now.

Rust:

* Example ready on the page.
* Linked to a run environment.
* New function listed below, with versioning! So you know exactly 
what function will work with what version your running.
* Most function or variables link to pages that again have 
examples on usage.
* Cleaner / Easier to read.

Dlang:

* A long list of functions/classes/...
* Most function or variables link to pages that for 80% simply 
state the same information. 20% has expanded information or 
examples.

More:

https://doc.rust-lang.org/std/net/struct.UdpSocket.html
https://dlang.org/library/std/socket/udp_socket.html

...

And stated said, i have zero experience with Rust. Never ran it, 
just looked at a few over complicated examples in the past ( it 
actually easier then expected with proper example ).

So it took me about 30 minutes to install, figure out why the 
example did not work (  return value ) and got it running.

How long will it take anybody to create a tcp socket in D, 
without resorting to google search and looking into a lot of 
forum posts.

Answer: A few hours because i did the same work a few days ago. 
Some of the forum examples are people asking for help with mixed 
results. From there you need to figure things out. Not everything 
works because some posts are so old, that the information is 
outdated.


 Rust probably is aligned more than anyone with these goals at 
 the moment but every time > I try to learn rust my head hurts 
 and it's not enjoyable.


Actually, just playing around with it and you can configure more 
then you think. I got very fast annoyed with the enforcement of 
no parens on if statements ( it looks cleaner / easier to read 
with parens. My opinion of course ). Thinking by myself: Hello Go 
again!

But it only took a few minutes to figure out that you can control 




 1. Evolve the GC like Go has.


I fear that will require a massive rewrite / totally new GC. The 
change that will happen is very low.


 2. No overhead calling C libraries.


There will always be some overhead calling C libraries. There is 
the whole conversion of types etc.


 3. Easily composable libraries.


... Did not see a big issue with creating your own libraries in 
D. Or do you mean shared libraries. Yea, that is a massive 
difference. Go is massive more easy ( especially the 1.8 beta ).


 4. Good IDE support.


I know the feeling. How many hours struggling to try and get my 
favorite IDE's to cooperate with Dlang support. Too many are 
simply out of date / unsupported. Or at best have basic syntax 
support and that is it.

The best option right now is simply Visual Studio Code. Where 
WebFreak001 did a lot of great work on making it more easy ( 
plenty of issue at times but relative more easy ). The problem 
being that VSC is a more pure local editor and missing a lot of 
features ( SFTP comes to mind ... the 3th party plugin solution 
have issues ).

I have gone down the list of editors and its a mess of 
unsupported, incomplete or outdated plugins. Or editors with 
lacking features. Probably put in a dozen hours or more testing 
them all out. And VSC is really the only properly supported one 
with the full feature set.
Dec 20 2016
parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D
Subject: Re: D future ...
References: <gtydhqbobwljnnvvlmjc forum.dlang.org>
 <lniehufaqrwtmtaltetj forum.dlang.org> <dhizcodszmdjonrlejxf forum.dlang.org>
 <ktvuytvzpxfyioggnyfm forum.dlang.org> <wfbzmobtrnicrfjyllmd forum.dlang.org>
In-Reply-To: <wfbzmobtrnicrfjyllmd forum.dlang.org>

--omLD0vULa0sXSHr2CEJG6WrRqVPdODrt3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 12/20/2016 12:48 PM, Benjiro wrote:

 Actually, i did not vent any anger until this morning when i noticed th=


e

 wiseass response. All the points i wrote yesterday are items that
 actually bother a lot more people. But those same people who complain
 about it, always get shutdown with that typical: Do it yourself respons=


e

 / Improve the standard library / ...


Can you list specific list of actions/events you would have wanted to
see as a result of your post? Literally "person X does Y". Trying to
write it down is very likely to make obvious why no other reaction than
one you have got is possible.


--omLD0vULa0sXSHr2CEJG6WrRqVPdODrt3--
Dec 20 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/20/2016 05:53 AM, Dicebot wrote:

 On 12/20/2016 12:48 PM, Benjiro wrote:

 Actually, i did not vent any anger until this morning when i noticed the
 wiseass response. All the points i wrote yesterday are items that
 actually bother a lot more people. But those same people who complain
 about it, always get shutdown with that typical: Do it yourself response
 / Improve the standard library / ...


 Can you list specific list of actions/events you would have wanted to
 see as a result of your post? Literally "person X does Y".


That would be very helpful. -- Andrei
Dec 20 2016
prev sibling next sibling parent lurker_ <lurker_ aol.com> writes:
On Tuesday, 20 December 2016 at 08:41:21 UTC, Benjiro wrote:

 On Tuesday, 20 December 2016 at 01:45:27 UTC, Tommi wrote:



 F*ck this. Its like talking to walls. Anyway, do what you want. 
 I have my own projects to deal with and i can write around the 
 lacking libraries, documentation etc. Unfortunately, not 
 everybody can and its those people you are hurting with that 
 wiseass attitude. Good luck getting new people motivated in D 
 like that.


+100
Dec 20 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/20/16 3:41 AM, Benjiro wrote:

 [snip]


Thanks for the rant. Though it was pretty awesome, I too feel the focus 
was missing in the sense that I'm unclear on what steps we can take to 
alleviate your pain points. Do you want more or less in the language and 
the standard library? Do you want me to get on things like editor 
integration I have no expertise in? What would be Cliff's notes of this 
post?


 Maybe you want to freaking ask the authors of for instants std.database
 etc why they feel unwilling to add it to the standard library git.


Erik Smith has been on board with adding his work to the standard 
library from day one, and he has our full support. He gave a talk at 
DConf. As sadly it sometimes happens with volunteers, time is a precious 
commodity for us all and volunteer projects are the first to be dropped 
in a crunch. Framing this politically is not quite helpful.

Are you thinking of a different database package?


Thanks,

Andrei
Dec 20 2016
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Tuesday, 20 December 2016 at 12:43:38 UTC, Andrei Alexandrescu 
wrote:

 On 12/20/16 3:41 AM, Benjiro wrote:

 [snip]


 Thanks for the rant. Though it was pretty awesome, I too feel 
 the focus was missing in the sense that I'm unclear on what 
 steps we can take to alleviate your pain points. Do you want 
 more or less in the language and the standard library? Do you 
 want me to get on things like editor integration I have no 
 expertise in?


Hi,

As a long time D observer and someone who tried to use D earlier 
this year, I hope following is constructive.

D's reason for existence
------------------------

I think the landscape of programming languages has changed 
somewhat in recent years - we have new languages like Go, Swift, 

platform. It seems that D started out as better C++ but C++ is 
also evolving and taking many of the ideas from D.

So I think that D has to have a clear charter similar to say the 
charter for C 
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm).

And this needs to clarify how D is different from its competition 
and which use cases it is best for.

Is it better C?
Is it better C++?
Is it better some other language?

Project Management
---------------------

It is a bit painful to watch how D's development is managed. In 
my view, the whole of the D team (including volunteers) need to 
be very narrowly focussed on very small set of defined priorities.

Secondly the goal has to be a measurable delivery within strict 
timescales.

It seems that too many avenues are being chased while there are 
too few people to handle the workload. Why not have a much more 
restricted scope and focus everyone on that. And when this is 
achieved move to the next scope.

It is also important to keep the scope small and achievable in a 
short time (3-6 months).

Real world needs
-----------------

As a potential user of D, here are the things I looked at:

1) Can I successfully build my project?

2) Can I expose my D modules as reusable C ABI compatible shared 
libraries for use in a heterogenous environment?

3) Can I debug my programs easily?

4) Is there an IDE I can use for development?

5) Is the performance going to match C or C++?

6) Will the third party libraries I need to use work with D?

Note that in all of above, language features and D libraries did 
not count! In production usage being able to deliver counts most. 
D fell short in these areas compared to a combination of C++ and 


Final thoughts
--------------

I wish I could help, as I really like D as a language. But 
unfortunately I have to focus on getting my own work done 

(after giving up the idea of using D).

I could potentially help in project management in my spare time 
... but feel that it needs a mind set change in the D team ... 
and I fear this is unlikely.

Apologies for being one of those who offers advice but no action.


Regards
Dibyendu
Dec 20 2016
parent reply Benjiro <benjiro benjiro.com> writes:
On Tuesday, 20 December 2016 at 14:09:45 UTC, Dibyendu Majumdar 
wrote:

 Apologies for being one of those who offers advice but no 
 action.


Don't be Dibyendu ...

We "ranters" are actually D's "client base". There seem to be the 
wrong impression by the D-Team, that the "clients" are also the 
people who need to help grow D.

I do not recall seeing on the C++ and other forums this constant 
attitude from fix it yourselves or put it in the libraries or ... 
Its mostly on the smaller languages where they lack people. And 
at the same time, that is a very scary though for companies who 
want to use a language.

Like you stated, the focus seems to be spread out compared to the 
needs. Its nice that a lot of the features of D, ended up in the 
new revisions of C++. But D is not a proving ground for C++ ideas.

At some moment one needs to say slow down with the new language 
features and focus on the core. Take for example the recent DIP 
1005 proposal. Is it really needed now? Can people not work with 
D without this feature?

If there is one thing that still scares people today, is hearing 
how D split the community with the D1/D2 version. And yet, even 
more features seems to be added to the language while the rest 
seems to be more or less low priority. Lets face it, its not 
exactly sexy doing boring documentation updates, creating 
examples, creating more std classes etc. Its way more fun to 
enhance a language ( its a trap too often seen in new languages. 
Its almost like language developers are in a arms race, to outdo 
each other but sometimes as the expensive of other area's ).

Anyway, enough "ranting" for me, back to work.
Dec 20 2016
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 20 December 2016 at 15:17:56 UTC, Benjiro wrote:

 I do not recall seeing on the C++ and other forums this 
 constant attitude from fix it yourselves or put it in the 
 libraries or ... Its mostly on the smaller languages where they 
 lack people. And at the same time, that is a very scary though 
 for companies who want to use a language.


I think it's important to be realistic. One of D's limitations is 
that it does not have the money of Microsoft or Intel behind it, 
and it does not have hundreds of billion-dollar corporations 
depending on it for critical business operations. Volunteer 
organizations will be run differently from outfits that have 
large budgets to pay people to do the ugly work. This is not an 
excuse, it is simply the current state of affairs.
Dec 20 2016
parent reply timmyjose <zoltan.jose gmail.com> writes:
On Tuesday, 20 December 2016 at 15:42:16 UTC, bachmeier wrote:

 On Tuesday, 20 December 2016 at 15:17:56 UTC, Benjiro wrote:

 I do not recall seeing on the C++ and other forums this 
 constant attitude from fix it yourselves or put it in the 
 libraries or ... Its mostly on the smaller languages where 
 they lack people. And at the same time, that is a very scary 
 though for companies who want to use a language.


 I think it's important to be realistic. One of D's limitations 
 is that it does not have the money of Microsoft or Intel behind 
 it, and it does not have hundreds of billion-dollar 
 corporations depending on it for critical business operations. 
 Volunteer organizations will be run differently from outfits 
 that have large budgets to pay people to do the ugly work. This 
 is not an excuse, it is simply the current state of affairs.


I'm completely new to the D scene, but I do want to make a 
comment here. One of the reasons why a language like Rust is 
seeing a surge in popularity is because the core team in Mozilla 
are evangelising it like you wouldn't believe it. Rust is a 
fairly old language, and yet the way they present it would fool 
anybody new to the language. Some things I noticed about their 
approach (having been part of the community for a little while) -

   1). Have a nifty, minimalistic website (D has a pretty good 
website as well, but I feel it is a bit overwhelming for newbies).

   2). Present the core strengths of the language on the main page 
itself in a brief sentence (even though they are more half-truths 
than anything else).

   3). They hired someone like Steve Klabnik to give talk after 
talk, and no matter what you may think of him, he is very good at 
"connecting" with the younger folks, and like it or not, the next 
generation is the target audience that will decide if a language 
is succesful or not.
     In my opinion (also based on posts that some D users have 
made on the Rust user group), D is actually a much more coherent 
and powerful language than Rust, but most people (including 
myself) wouldn't have known about it on face value.

Self-promotion is something that needs to be done, and the Rust 
group is very good at it. Go, on the other hand, benefits from 
the Google name, of course. I doubt it would have had a quarter 
of its success just based on Rob Pike's status and the merits of 
the language itself.

Also, community-building is something that absolutely needs to be 
done to convince users to join in with fresh minds, and start 
building things in the language. Only then will a community 
really flourish, no matter how good or bad the language is.

   4). Spam the tech arena - have tons of blogs floating around 
talking about the "cool" features of the language while 
downplaying the complexity hiding around the corner, have a very 
helpful IRC channel where people answer even the silliest 
questions with a smile, and have active forums and users on 
Reddit, HN, and the like.

    5). Have regular online meetups and offline and online 
conferences as well.
Feb 19 2017
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 20/02/2017 1:25 AM, timmyjose wrote:

 On Tuesday, 20 December 2016 at 15:42:16 UTC, bachmeier wrote:

 On Tuesday, 20 December 2016 at 15:17:56 UTC, Benjiro wrote:

 I do not recall seeing on the C++ and other forums this constant
 attitude from fix it yourselves or put it in the libraries or ... Its
 mostly on the smaller languages where they lack people. And at the
 same time, that is a very scary though for companies who want to use
 a language.


 I think it's important to be realistic. One of D's limitations is that
 it does not have the money of Microsoft or Intel behind it, and it
 does not have hundreds of billion-dollar corporations depending on it
 for critical business operations. Volunteer organizations will be run
 differently from outfits that have large budgets to pay people to do
 the ugly work. This is not an excuse, it is simply the current state
 of affairs.


 I'm completely new to the D scene, but I do want to make a comment here.
 One of the reasons why a language like Rust is seeing a surge in
 popularity is because the core team in Mozilla are evangelising it like
 you wouldn't believe it. Rust is a fairly old language, and yet the way
 they present it would fool anybody new to the language. Some things I
 noticed about their approach (having been part of the community for a
 little while) -

   1). Have a nifty, minimalistic website (D has a pretty good website as
 well, but I feel it is a bit overwhelming for newbies).

   2). Present the core strengths of the language on the main page itself
 in a brief sentence (even though they are more half-truths than anything
 else).

   3). They hired someone like Steve Klabnik to give talk after talk, and
 no matter what you may think of him, he is very good at "connecting"
 with the younger folks, and like it or not, the next generation is the
 target audience that will decide if a language is succesful or not.
     In my opinion (also based on posts that some D users have made on
 the Rust user group), D is actually a much more coherent and powerful
 language than Rust, but most people (including myself) wouldn't have
 known about it on face value.

 Self-promotion is something that needs to be done, and the Rust group is
 very good at it. Go, on the other hand, benefits from the Google name,
 of course. I doubt it would have had a quarter of its success just based
 on Rob Pike's status and the merits of the language itself.

 Also, community-building is something that absolutely needs to be done
 to convince users to join in with fresh minds, and start building things
 in the language. Only then will a community really flourish, no matter
 how good or bad the language is.

   4). Spam the tech arena - have tons of blogs floating around talking
 about the "cool" features of the language while downplaying the
 complexity hiding around the corner, have a very helpful IRC channel
 where people answer even the silliest questions with a smile, and have
 active forums and users on Reddit, HN, and the like.


We do try on our Freenode channel, but answering with a smile can be 
quite hard. Especially when simple answers are ignored (I am definitely 
guilty of this).

It really doesn't help that we only have one person with OP rights who 
acts upon them. Its annoying since we get spammed every 6-8 months with 
nothing we can do assuming no Freenode admins are on (this is very common!).
Feb 19 2017
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D
Subject: Re: D future ...
References: <gtydhqbobwljnnvvlmjc forum.dlang.org>
 <lniehufaqrwtmtaltetj forum.dlang.org> <dhizcodszmdjonrlejxf forum.dlang.org>
 <o3b91o$sto$1 digitalmars.com> <crwhrrbdpaydnqfmdzfp forum.dlang.org>
 <agzhmrbfythruxstfhrd forum.dlang.org>
In-Reply-To: <agzhmrbfythruxstfhrd forum.dlang.org>

--t2bp68QBs8XhdEDkuIE2ofdERfMcP5F1d
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 12/20/2016 05:17 PM, Benjiro wrote:

 On Tuesday, 20 December 2016 at 14:09:45 UTC, Dibyendu Majumdar wrote:

 Apologies for being one of those who offers advice but no action.


=20
 Don't be Dibyendu ...
=20
 We "ranters" are actually D's "client base". There seem to be the wrong=



 impression by the D-Team, that the "clients" are also the people who
 need to help grow D.


Just how much exactly are paying to D Foundation for support to call
yourself a client? What are your support contract terms?


 I do not recall seeing on the C++ and other forums this constant
 attitude from fix it yourselves or put it in the libraries or ... Its
 mostly on the smaller languages where they lack people. And at the same=



 time, that is a very scary though for companies who want to use a langu=


age.

Yes, D is small language with no developers and no funds and C++ is huge
one with enormous corporate involvement, enough to afford big crowd of
free riders. Your point?


 Anyway, enough "ranting" for me, back to work.


I am really tired of this recurring bullshit of random guys coming up
and acting as if they have any right to demand anything. You distract
those few that are willing to do the work from focusing on it, you are
not capable of saying anything not widely known and you have no desire
to contribute yourself.


--t2bp68QBs8XhdEDkuIE2ofdERfMcP5F1d--
Dec 20 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 20 December 2016 at 15:44:03 UTC, Dicebot wrote:

 I am really tired of this recurring bullshit of random guys 
 coming up and acting as if they have any right to demand 
 anything. You distract those few that are willing to do the 
 work from focusing on it, you are not capable of saying 
 anything not widely known and you have no desire to contribute 
 yourself.

 My opinion? Fuck off.


It's a fair point, but people only know that all these rants have 
come up a million times if they've been following the newsgroup 
for a while.

It's the kind of thing where most forums have a read me that says 
something like, yes we already know about all these things and 
thread about them are considered spam.
Dec 20 2016
parent reply Chris M. <chrismohrfeld comcast.net> writes:
On Tuesday, 20 December 2016 at 18:01:23 UTC, jmh530 wrote:

 It's a fair point, but people only know that all these rants 
 have come up a million times if they've been following the 
 newsgroup for a while.

 It's the kind of thing where most forums have a read me that 
 says something like, yes we already know about all these things 
 and thread about them are considered spam.


Seb just made a giant post listing all the things that could be 
done to help improve D, that could to be pinned somewhere so that 
everyone can see it. Maybe something like that should be made 
every time a new high-level vision is made, so that people know 
where and how they can focus their efforts.
Dec 20 2016
parent reply Chris M. <chrismohrfeld comcast.net> writes:
On Tuesday, 20 December 2016 at 19:11:11 UTC, Chris M. wrote:

 Seb just made a giant post listing all the things that could be 
 done to help improve D, that could to be pinned somewhere so 
 that everyone can see it. Maybe something like that should be 
 made every time a new high-level vision is made, so that people 
 know where and how they can focus their efforts.


Well, maybe not so giant
Wish posts could be edited
Dec 20 2016
parent Madaz Hill <mhmhmh mhmh.mh> writes:
On Tuesday, 20 December 2016 at 19:15:37 UTC, Chris M. wrote:

 On Tuesday, 20 December 2016 at 19:11:11 UTC, Chris M. wrote:

 Seb just made a giant post listing all the things that could 
 be done to help improve D, that could to be pinned somewhere 
 so that everyone can see it. Maybe something like that should 
 be made every time a new high-level vision is made, so that 
 people know where and how they can focus their efforts.


 Well, maybe not so giant
 Wish posts could be edited


Remember that this is not a forum, it's a NG interface. Edition 
would mean that the email received could be potentially invalid 
and conversation would become confuse. If you're too ashamed by 
your errors, post an erratum...
Dec 20 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/20/2016 7:17 AM, Benjiro wrote:

 I do not recall seeing on the C++ and other forums this constant attitude from
 fix it yourselves or put it in the libraries or ...


Oh, it's certainly there. If you want to change C++ or the C++ Standard
Library, 
you are told to submit a proposal paper to the C++ Committee, which is a quite 
formal and arduous process and takes years.

There is no such thing as posting a complaint on comp.lang.c++ and legions of 
people jump in to take care of it for you.

D is quite a bit less formal, but still, if you want action consider that you 
aren't going to get it with any organization unless you're willing to:

1. pay others to do it

2. convince others that your important issues are more important than everyone 
else's important issues that they are already working on

3. put some effort into it yourself

This includes C, C++, Java, Go, Rust, basically every language in existence.

---

Note that pretty much every day in the D forums, people post lists of their
most 
important issues they want other people to work on. And the lists are always 
different.

When people invest time into solving the problems they complain about, that's 
evidence that those issues are more important. It's the same in C++ land - a 
common sentiment among the C++ stars is that if someone isn't willing to make
an 
effort to write a proposal to the C++ Committee, it isn't an issue worth their 
time, either.

It really can't be any other way.
Dec 20 2016
parent reply Mark <smarksc gmail.com> writes:
On Tuesday, 20 December 2016 at 16:22:43 UTC, Walter Bright wrote:

 D is quite a bit less formal, but still, if you want action 
 consider that you aren't going to get it with any organization 
 unless you're willing to:

 1. pay others to do it

 2. convince others that your important issues are more 
 important than everyone else's important issues that they are 
 already working on

 3. put some effort into it yourself

 This includes C, C++, Java, Go, Rust, basically every language 
 in existence.

 ---

 Note that pretty much every day in the D forums, people post 
 lists of their most important issues they want other people to 
 work on. And the lists are always different.

 When people invest time into solving the problems they complain 
 about, that's evidence that those issues are more important. 
 It's the same in C++ land - a common sentiment among the C++ 
 stars is that if someone isn't willing to make an effort to 
 write a proposal to the C++ Committee, it isn't an issue worth 
 their time, either.

 It really can't be any other way.


What about the first way in your list ("pay others to do it")? 
 From what I gather, this was one of the reasons for founding the 
D Foundation.

There are many "boring" tasks that few people seem interested in 
doing: improving the documentation, maintaining the website, 
improving the forum system (it lacks many important features 
IMHO), improving IDE support for D (I have no idea how one would 
go about doing this but it's important), etc. (The vision 
document in the D wiki contains many more such "boring" tasks).

And the few people that do work on the "boring" stuff seem to be 
the "wrong" people. One does not need to be a compiler expert or 
a metaprogramming guru to work on the tasks mentioned. That would 
be a bad use of that person's time - his/her skills lie 
elsewhere. If no one is interested in doing this stuff then maybe 
it's a good idea for the D Foundation to hire some people who'll 
dedicate their time to these issues. I do not think that this 
would be a bad use of the foundation's funds.
Dec 21 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2016 6:24 AM, Mark wrote:

 I do not think that this would be a bad use of the
 foundation's funds.


That is one of the purposes of the Foundation.
Dec 21 2016
prev sibling parent reply keito940 <keito940 live.jp> writes:
On Tuesday, 20 December 2016 at 01:45:27 UTC, Tommi wrote:

 Improve the standard library!


...If you improve the standard library, everything OK? If...
Next Version Request.
Add To The F Sharp Like Pipeline Operator(D Language Pipeline 
Syntax is BAD.) & SML(C Language Compatible) Like Function Syntax 
&Haskell Like Maybe Monad&Binary Execution speed Up.
Plz,Now!!!
Dec 30 2016
parent reply keito940 <keito940 live.jp> writes:
On Friday, 30 December 2016 at 09:53:25 UTC, keito940 wrote:

 ...If you improve the standard library, everything OK? If...
 Next Version Request.
 Add To The F Sharp Like Pipeline Operator(D Language Pipeline 
 Syntax is BAD.) & SML(C Language Compatible) Like Function 
 Syntax &Haskell Like Maybe Monad&Binary Execution speed Up.
 Plz,Now!!!


I also have to change the specification of the language.
First of all, we have to introduce this system!
Jan 02 2017
parent reply SC <SC gmail.com> writes:
People here under estimate the necessity to have EXCELLENT editor 
support

Without editor, nobody will want to write code in D, there are 
ton of languages now, all with great editor support (Rust, Go, 


There are 10 IDE/plugin project for d, this is too much, half are 
already dead, we go nowhere, please focus on one that is 
crossplatform (IntelliJ)

And jetbrains are working on Kotlin native, another big 
competitor..
Feb 11 2017
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2017-02-11 at 15:52 +0000, SC via Digitalmars-d wrote:

 People here under estimate the necessity to have EXCELLENT editor=C2=A0
 support
=20
 Without editor, nobody will want to write code in D, there are=C2=A0
 ton of languages now, all with great editor support (Rust, Go,=C2=A0



Cannot disagree with this.


 There are 10 IDE/plugin project for d, this is too much, half are=C2=A0
 already dead, we go nowhere, please focus on one that is=C2=A0
 crossplatform (IntelliJ)


It isn't the number of different projects that is the problem. The
problem is the lack of effort going in to the Eclipse and the IntelliJ
IDEA plugins. In terms of traction of D, having an excellent Eclipse
perspective, and an excellent IntelliJ IDEA and CLion plugin is
essential.

Personally, I favour the IntelliJ IDEA and CLion IDEs. Work is
progressing on the IntelliJ IDEA but it simply needs more people
contributing actively =E2=80=93 to my shame I haven't been able to put time
into this myself, so I am contributing to the problem. This plugin uses
Dub for build management, the CLion version needs to use CMake, so we
need the CMake-D stuff to be up to scratch as well.

I have just tried out the Rust plugin to IntelliJ IDEA, it is
excellent. JetBrains themselves have taken the Go plugin and turned it
into Gogland a complete IDE. It is not half bad. D is very definitely
losing in this IDE race, and thus in the potential for traction in the
C, C++, Go, Rust, D milieu.


 And jetbrains are working on Kotlin native, another big=C2=A0
 competitor..


Interesting, but the current competition is between Go, Rust, C++, and
D.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 11 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 11 February 2017 at 18:51:31 UTC, Russel Winder 
wrote:

 Interesting, but the current competition is between Go, Rust, 
 C++, and D.


I don't know, which fields are you thinking about? I believe the 
market is changing.

On OSX/iOS: Swift + Metal is the alternative, throw in some bits 
of Objective-C/C++ where you have long running tight inner loops.



On Linux: this is more of an open space.

Embedded: C/C++, maybe Rust for those with courage? I suspect 
moving out of vendor supported tooling is risky (e.g. 
system-on-a-chip solutions)

Numerics: Python + low level libraries, Matlab etc.

But, the way I see it TypeScript + "native libraries" has the 
potential for covering a lot of ground. The eco system is 
exploding.
Feb 14 2017
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2017-02-14 at 10:22 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-
d wrote:

 On Saturday, 11 February 2017 at 18:51:31 UTC, Russel Winder=C2=A0
 wrote:

 Interesting, but the current competition is between Go, Rust,=C2=A0
 C++, and D.


=20
 I don't know, which fields are you thinking about? I believe the=C2=A0
 market is changing.


It is also "re-tribalising" around the Rust, Go, Swift, C++17 for
native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on the JVM;
ECMAScript, TypeScript, Elm in the browser, and Python in data science
and such like. OK not orthogonal dimensions.


 On OSX/iOS: Swift + Metal is the alternative, throw in some bits=C2=A0
 of Objective-C/C++ where you have long running tight inner loops.
=20

=20
 On Linux: this is more of an open space.
=20
 Embedded: C/C++, maybe Rust for those with courage? I suspect=C2=A0
 moving out of vendor supported tooling is risky (e.g.=C2=A0
 system-on-a-chip solutions)
=20
 Numerics: Python + low level libraries, Matlab etc.
=20
 But, the way I see it TypeScript + "native libraries" has the=C2=A0
 potential for covering a lot of ground. The eco system is=C2=A0
 exploding.


An interesting perspective is who is putting money into IDEs and
JetBrains are a good measuring device for this. C/C++ with CMake got
CLion which is now getting a lot of Swift and Rust love. Go got a whole

gamut of JVM languages in IDEA =E2=80=93 where the Rust plugin gets a lot o=
f
push. Python has PyCharm.

D has some small effort in IDEA, but it needs the resourcing to get to
the level the Rust, Clojure, Scala, Groovy, Swift, Go, C++, Kotlin
languages get.

It is noticeably that many people are leaving the Eclipse environment
for the JetBrains one, Ceylon is a prime example. But Eclipse remains a
player here (unlike NetBeans?)

Emacs, VIM, SublimeText, Atom, etc. get some love but few people really
care about them compared to the Eclipse and JetBrains IDEs.

So if we measure traction by IDE and editor effort D is losing, along
with Fantom, Crystal, Pony, Nim, and all the other languages that focus
on the language to the expense of the way people use the language.
Kingsley started work on the IDEA plugin and Bruno on the Eclipse
plugin. Some people are working on the IDEA plugin (I am supposed to be
as well, but I am failing). To get D out there with traction, these,
not the compiler, should be the core focus of attention =E2=80=93 the place
where lots of resource is going in. Ceylon, Kotlin, Rust, Go have some
core resource that attracts more resource, and there is a snowball
effect.

No matter how good D and the compilers are, without high quality IDE
support, it will be a peripheral language for the core adherents.

But we have been round this time and again, with extraordinarily little
progress.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 15 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 February 2017 at 10:38:04 UTC, Russel Winder 
wrote:

 It is also "re-tribalising" around the Rust, Go, Swift, C++17 
 for native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on 
 the JVM; ECMAScript, TypeScript, Elm in the browser, and Python 
 in data science and such like. OK not orthogonal dimensions.


Yeah, it isn't orthogonal dimensions. Not quite sure what you 
mean by "re-tribalising". Do you mean that developers have broken 
up from older languages like C++98 and Objective-C and regrouped 
over Rust, Go, Swift and C++17? I guess that is a reasonable 
interpretation.

I am still not sure exactly what Rust's demographic is, but I 
guess it may be catering for those that want a high-level C with 
a preference for functional programming over templated 
programming?



 An interesting perspective is who is putting money into IDEs 
 and JetBrains are a good measuring device for this. C/C++ with 
 CMake got CLion which is now getting a lot of Swift and Rust 

 get a lot of push, as do the gamut of JVM languages in IDEA – 
 where the Rust plugin gets a lot of push. Python has PyCharm.


I haven't seen Gogland before, too bad I turned down the full 
suite IDE offering from JetBrains recently... VSCode with plugins 
is ok for Go and TypeScript though.

But it is a clear trend that newer languages are more tuned for 
IDE support, i.e. the language design is made with 
text-completion support in mind. This is one primary advantage 
with TypeScript over JavaScript for instance and alone worth the 
switch. Writing Python code with PyCharm is also quite different 
from using emacs, it is almost a "different language".

This trend will continue. Programming for iOS without XCode is 
unthinkable at this point, and similar situations exists for 
other platforms.


 Emacs, VIM, SublimeText, Atom, etc. get some love but few 
 people really care about them compared to the Eclipse and 
 JetBrains IDEs.


The cognitive load is just too high these days to use a regular 
editor if you want to be productive. The APIs are too big, there 
are too many of them, and they change too much and frequently to 
deal with "non-standard" editor issues. Just the automated 
hinting that something is deprecated and suggestions for 
replacements are invaluable time savers when upgrading codebases.


 So if we measure traction by IDE and editor effort D is losing, 
 along with Fantom, Crystal, Pony, Nim, and all the other 
 languages that focus on the language to the expense of the way 
 people use the language.


I think IDE support should be part of the core project these 
days. My impression is that Dart had a lot more enthusiastic 
following when they provided a Dart-editor (eclipse fork). 
JetBrains supports Dart, but it isn't really the same thing when 
it isn't free and directly supported by the language provider.

I noticed that the Whiley website says that they are maintaining 
an eclipse plugin as part of the project.


 Kingsley started work on the IDEA plugin and Bruno on the 
 Eclipse plugin. Some people are working on the IDEA plugin (I 
 am supposed to be as well, but I am failing). To get D out 
 there with traction, these, not the compiler, should be the 
 core focus of attention – the place where lots of resource is 
 going in.


One cannot expect volunteers to keep at it for years. And being 
left in the dark at some point in the future is not a very 
enticing prospect when adopting a language. There are currently 
more open source projects on github than (capable) developers... 
so one cannot expect others to take over either. It was different 
back in the day when emacs was the only real alternative.

Community driven development seems to no longer work reliably for 
projects that have high maintenance costs (with notable 
exceptions).

I guess this having something to do with the basic needs being 
met by the Linux ecosystem (the basic Unix toolset being 
available). Maslow's hierarchy of needs?


 Ceylon, Kotlin, Rust, Go have some core resource that attracts 
 more resource, and there is a snowball effect.


I think Go has benefitted some from having limited and stable 
language semantics and continuously improving on the 
implementation. IMO that should make it attractive in the server 
space, i.e. you get low tooling-related maintenance cost and 
still get real benefits from recompiling with new versions of the 
compiler.

I don't much about Rust and snowball effects? I thought Rust had 
stagnated, but maybe I am wrong?


 No matter how good D and the compilers are, without high 
 quality IDE support, it will be a peripheral language for the 
 core adherents.

 But we have been round this time and again, with 
 extraordinarily little progress.


The most important factor is the overall composition of the eco 
system and a good IDE makes it all come together. Kinda like a 
carpenter's workbench. You can make small scale stuff without, 
but you wouldn't do professional work on a tight schedule without 
a good stable workbench if can get one at another shop (language).

But a good IDE won't make significant change until the semantics 
for resource handling has been dealt with in a competitive 
manner... so there are several bits missing. Both Go, Swift and 
Rust provide "state of the art" memory management. D currently 
does not.
Feb 15 2017
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-02-15 17:07, Ola Fosheim Grøstad wrote:


 This trend will continue. Programming for iOS without XCode is
 unthinkable at this point, and similar situations exists for other
 platforms.


TextMate on macOS is a native macOS application (Cocoa, C++) but does 
not use Xcode to build, it's using ninja. I guess that's expected, to 
use TextMate to build TextMate.

-- 
/Jacob Carlborg
Feb 15 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 February 2017 at 16:28:00 UTC, Jacob Carlborg 
wrote:

 On 2017-02-15 17:07, Ola Fosheim Grøstad wrote:


 This trend will continue. Programming for iOS without XCode is
 unthinkable at this point, and similar situations exists for 
 other
 platforms.


 TextMate on macOS is a native macOS application (Cocoa, C++) 
 but does not use Xcode to build, it's using ninja. I guess 
 that's expected, to use TextMate to build TextMate.


It certainly is possible to build for macOS/iOS without using 
XCode, but still unthinkable for most. Even JetBrain's commercial 
offering fall short because they lag behind when Apple release a 
new OS version. If the language/framework vendor provides an IDE 
it becomes difficult to break into the market, if for no other 
reason than being sure that timeliness requirements are met.
Feb 15 2017
prev sibling next sibling parent reply Cym13 <cpicard openmailbox.org> writes:
On Wednesday, 15 February 2017 at 16:07:18 UTC, Ola Fosheim 
Grøstad wrote:

 I think Go has benefitted some from having limited and stable 
 language semantics and continuously improving on the 
 implementation. IMO that should make it attractive in the 
 server space, i.e. you get low tooling-related maintenance cost 
 and still get real benefits from recompiling with new versions 
 of the compiler.


That is a very good point, I had never considered the 
consequences of
semantics stabilization on tooling. It strenghtens (along with 
DIP1005)
my opinion that D is fine as it is and that no new feature should 
be
added before at least two years, while fixing the implementation 
should
get the focus. It doesn't mean we can't add anything new, better 
C++
integration or memory management semantics would be fine, as long 
as it
is an already begun project.

There's little point in having more features if what's already 
there is
half broken and not well-defined.
Feb 15 2017
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote:

 There's little point in having more features if what's already 
 there is half broken and not well-defined.


This is what Manu and deadalnix have been saying for the past 
three years. Its fallen on deaf ears.
Feb 15 2017
parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 15 February 2017 at 20:53:58 UTC, Jack Stouffer 
wrote:

 On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote:

 There's little point in having more features if what's already 
 there is half broken and not well-defined.


 This is what Manu and deadalnix have been saying for the past 
 three years. Its fallen on deaf ears.


Isn't that a little uncharitable?
Feb 15 2017
parent Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 15 February 2017 at 21:16:51 UTC, Meta wrote:

 Isn't that a little uncharitable?


I just spent about 20 minutes list out all of my problems with 
the language, and how somethings are pretty broken. But I deleted 
it and I'm not going to post it.

It was just another rant. One that doesn't change anything. All 
I'll say is the current language maintainers know what's broken. 
And I sincerely hope they work to fix them before adding in a 
bunch of new DIPs which will further complicate matters, 
especially with regard to function signitures.
Feb 15 2017
prev sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote:

 There's little point in having more features if what's already 
 there is
 half broken and not well-defined.


+1
Feb 15 2017
parent Soulsbane <paul acheronsoft.com> writes:
On Wednesday, 15 February 2017 at 21:07:06 UTC, Arun 
Chandrasekaran wrote:

 On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote:

 There's little point in having more features if what's already 
 there is
 half broken and not well-defined.


 +1


Indeed.
Feb 17 2017
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 15 February 2017 at 16:07:18 UTC, Ola Fosheim 
Grøstad wrote:

 This trend will continue. Programming for iOS without XCode is 
 unthinkable at this point, and similar situations exists for 
 other platforms.


For macOS, the prospect of not having to use XCode is rather a 
positive :)
Feb 16 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 17 February 2017 at 01:29:48 UTC, Guillaume Piolat 
wrote:

 For macOS, the prospect of not having to use XCode is rather a 
 positive :)


Really? I find XCode 8 to do most of what I need. Refactoring is 
somewhat limited, but otherwise it works fine.
Feb 17 2017
prev sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 14 February 2017 at 10:22:26 UTC, Ola Fosheim Grøstad 
wrote:

 But, the way I see it TypeScript + "native libraries" has the 
 potential for covering a lot of ground. The eco system is 
 exploding.


Having done a fair amount of professional development in 
typescript over the last 6 months, I have to say I'm not as 
excited about it as I used to be. Don't get me wrong, I still 
think it's the best language in its space, but the javascript 
underneath it shows through in a lot of bad places and the lack 
of real meta-programming makes it hard to get your types exactly 
how you want them. Overall I've found it a frustrating when I 
compare it to working in D, despite it having a bunch of cool 
features I'd love to use in D.
Feb 15 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 February 2017 at 11:14:11 UTC, John Colvin wrote:

 On Tuesday, 14 February 2017 at 10:22:26 UTC, Ola Fosheim 
 Grøstad wrote:

 But, the way I see it TypeScript + "native libraries" has the 
 potential for covering a lot of ground. The eco system is 
 exploding.


 Having done a fair amount of professional development in 
 typescript over the last 6 months, I have to say I'm not as 
 excited about it as I used to be. Don't get me wrong, I still 
 think it's the best language in its space, but the javascript 
 underneath it shows through in a lot of bad places and the lack 
 of real meta-programming makes it hard to get your types 
 exactly how you want them. Overall I've found it a frustrating 
 when I compare it to working in D, despite it having a bunch of 
 cool features I'd love to use in D.


The structural flow type-system of TypeScript takes time to get 
used to and it only provides limited static type checks, so it 
has rather limited generating capabilities (typing is primarily 
for correctness checks and IDE-text-completion support). The 
template-expansion area is a field where D is better off, 
certainly.

What MS did right though was to create something that is not too 

Java or Swift, yet they absorb trendy frameworks like React and 
Angular as well as all existing JavaScript libraries. Not having 
a fixed build system is a weakness, and a bit frustrating, but I 
guess this is deliberately done to absorb as many developers as 
possible with their existing preferences. Objectively a competing 
language like Dart is better, but Dart is different enough to not 
having the ability to absorb developers.

My viewpoint is that this ability to absorb existing practices 
(like build systems and code bases) is probably where TypeScript 
is gaining traction from.

I think D might be a bit like Dart in this regard. It is closely 
related to, but yet too different from C/C++ to absorb the 
existing practices.

Another example is Swift. Swift managed to take over Objective-C 
rather quickly IMO, but Swift has also absorbed the non-C 
semantics of Objective-C, thus it did not require changing 
existing practice significantly.
Feb 15 2017
parent reply bpr <brogoff gmail.com> writes:
On Wednesday, 15 February 2017 at 14:44:55 UTC, Ola Fosheim 
Grøstad wrote:

 Another example is Swift. Swift managed to take over 
 Objective-C rather quickly IMO, but Swift has also absorbed the 
 non-C semantics of Objective-C, thus it did not require 
 changing existing practice significantly.


Swift took over quickly because Apple has mandated it. While I'm 
happy about that, there's no denying that Swift wouldn't be where 
it is without the weight of Apple behind it. I'd go as far as to 
say that Swift's success is assured (unless Apple drops it, which 
looks unlikely) and that because Swift has money behind it, more 
money will follow, and so will a thriving ecosystem, on and off 
OS X.

As a PL, Swift looks nice, but they'll have to come up with a 
more complete story around concurrency.
Feb 15 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 February 2017 at 16:41:31 UTC, bpr wrote:

 Swift took over quickly because Apple has mandated it. While 
 I'm happy about that, there's no denying that Swift wouldn't be 
 where it is without the weight of Apple behind it. I'd go as 
 far as to say that Swift's success is assured (unless Apple


It may have been assured, but the adoption _rate_ comes from 
having a good match on semantics and existing practices.

Replace Swift with Haskell and the adoption would have been much 
slower.


 As a PL, Swift looks nice, but they'll have to come up with a 
 more complete story around concurrency.


Do you mean parallell execution (CPU) or concurrency as a 
modelling paradigm? One cannot really assume that Apple hardware 
has more than 2 CPUs. So as a starting point you can presume that 
one core taken by the main UI event loop and the other one taken 
by real time code. Whatever is left is for Apple's "Operation 
Queues" (dispatch queues, basically worker threads working in a 
FIFO manner IIRC).

https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/
Feb 15 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 February 2017 at 17:08:37 UTC, Ola Fosheim 
Grøstad wrote:

 modelling paradigm? One cannot really assume that Apple 
 hardware has more than 2 CPUs.


Typo: I mean't that one cannot assume that Apple hardware has 
more than 2 cores (so one has to write applications that perform 
well with only 2 cores).
Feb 15 2017
parent reply bpr <brogoff gmail.com> writes:
On Wednesday, 15 February 2017 at 17:53:43 UTC, Ola Fosheim 
Grøstad wrote:

 Typo: I mean't that one cannot assume that Apple hardware has 
 more than 2 cores (so one has to write applications that 
 perform well with only 2 cores).


You're missing what I consider to be 'the Big Picture', namely 
that Swift will become popular on non-Apple platforms, and it 
needs to be fairly capable to compete with Go, Java, and C++, and 
others. IBM is already backing server side Swift to some degree.
Feb 15 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 February 2017 at 21:46:32 UTC, bpr wrote:

 You're missing what I consider to be 'the Big Picture', namely 
 that Swift will become popular on non-Apple platforms, and it 
 needs to be fairly capable to compete with Go, Java, and C++, 
 and others. IBM is already backing server side Swift to some 
 degree.


I don't know if that will happen anytime soon. I think the 
functionality that the original creator has suggested for 
system-level programming has to be in place first. Currently the 
language/runtime  is geared towards best practices inherited from 
Foundation/Objective-C/Cocoa/macOS... Which makes sense, but 
makes Swift a second rate citizen in other environments.
Feb 15 2017
prev sibling parent Astor <astor mail.com> writes:
On Saturday, 11 February 2017 at 15:52:40 UTC, SC wrote:

 People here under estimate the necessity to have EXCELLENT 
 editor support


It's not just editor but complete setup, you shouldn't be 
required to download the compiler, then dub, then an editor.
An easy to download and install package including the compiler, 
dub and DLangIDE, plus perhaps a couple demo projects, would be 
great for curious newcomers who just want to take a look at the 
language. IMHO, of course.
Feb 16 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 Vim: Lets not go there.


Why not? If you already know vim at least, it is very easy to use 
with D - things just work quite well out of the box.


 Try remote editing D and see how much fun it is.


works in vim out of the box...
Dec 19 2016
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 12/19/2016 06:19 PM, Adam D. Ruppe wrote:

 On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 Vim: Lets not go there.


 Why not? If you already know vim at least, it is very easy to use with D
 - things just work quite well out of the box.


 Try remote editing D and see how much fun it is.


 works in vim out of the box...


No need to mention Emacs. If vi[m] can do something so can Emacs. :p

Ali
Dec 19 2016
parent timmyjose <zoltan.jose gmail.com> writes:
On Tuesday, 20 December 2016 at 02:24:28 UTC, Ali Çehreli wrote:

 On 12/19/2016 06:19 PM, Adam D. Ruppe wrote:

 On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 Vim: Lets not go there.


 Why not? If you already know vim at least, it is very easy to 
 use with D
 - things just work quite well out of the box.


 Try remote editing D and see how much fun it is.


 works in vim out of the box...


 No need to mention Emacs. If vi[m] can do something so can 
 Emacs. :p

 Ali


I, for one, concur.
Feb 19 2017
prev sibling next sibling parent reply Suliman <evermind live.ru> writes:
The whole focus on C++ people marketing is simply wrong! Every 
time this gets mentioned in external forums, the language gets a 
pounding by people with the same argumentation. Why go for D 
when C++ 20xx version does it also.


+100

I totally agree with another part of post. Plus the docs is 
really suks, not only I can't write code without copy-past 
examples, because it's simply very hard to understand how to use 
one ore another function. Even simple writeln docs very bloated 
and 80% (mostly format futures) do not needed in real life
Dec 19 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/2016 10:56 PM, Suliman wrote:

 The whole focus on C++ people marketing is simply wrong! Every time
 this gets mentioned in external forums, the language gets a pounding
 by people with the same argumentation. Why go for D when C++ 20xx
 version does it also.


 +100

 I totally agree with another part of post. Plus the docs is really suks,
 not only I can't write code without copy-past examples, because it's
 simply very hard to understand how to use one ore another function. Even
 simple writeln docs very bloated and 80% (mostly format futures) do not
 needed in real life


I took a look out of curiosity. 
https://dlang.org/library/std/stdio/writeln.html indeed has no direct 
exmaple and sends the reader to 
https://dlang.org/library/std/stdio/write.html. That one also has n 
direct example and sends the user to 
https://dlang.org/library/std/stdio/std_conv.html, which is a 404.

That's pretty bad. I'll create an issue.


Andrei
Dec 19 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote:

 On 12/19/2016 10:56 PM, Suliman wrote:

 The whole focus on C++ people marketing is simply wrong! Every time
 this gets mentioned in external forums, the language gets a pounding
 by people with the same argumentation. Why go for D when C++ 20xx
 version does it also.


 +100

 I totally agree with another part of post. Plus the docs is really suks,
 not only I can't write code without copy-past examples, because it's
 simply very hard to understand how to use one ore another function. Even
 simple writeln docs very bloated and 80% (mostly format futures) do not
 needed in real life


 I took a look out of curiosity.
 https://dlang.org/library/std/stdio/writeln.html indeed has no direct
 exmaple and sends the reader to
 https://dlang.org/library/std/stdio/write.html. That one also has n
 direct example and sends the user to
 https://dlang.org/library/std/stdio/std_conv.html, which is a 404.

 That's pretty bad. I'll create an issue.


https://issues.dlang.org/show_bug.cgi?id=16991
Dec 19 2016
parent reply Jerry <hurricane hereiam.com> writes:
On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei Alexandrescu 
wrote:

 On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote:

 On 12/19/2016 10:56 PM, Suliman wrote:

 The whole focus on C++ people marketing is simply wrong! 
 Every time
 this gets mentioned in external forums, the language gets a 
 pounding
 by people with the same argumentation. Why go for D when C++ 
 20xx
 version does it also.


 +100

 I totally agree with another part of post. Plus the docs is 
 really suks,
 not only I can't write code without copy-past examples, 
 because it's
 simply very hard to understand how to use one ore another 
 function. Even
 simple writeln docs very bloated and 80% (mostly format 
 futures) do not
 needed in real life


 I took a look out of curiosity.
 https://dlang.org/library/std/stdio/writeln.html indeed has no 
 direct
 exmaple and sends the reader to
 https://dlang.org/library/std/stdio/write.html. That one also 
 has n
 direct example and sends the user to
 https://dlang.org/library/std/stdio/std_conv.html, which is a 
 404.

 That's pretty bad. I'll create an issue.


 https://issues.dlang.org/show_bug.cgi?id=16991


Another issue onto the list of thousands, to collect dust for the 
next few years til someone decides they want to use their 
personal time to fix it. Just to highlight another problem, 
there's a lot of trivial to fix issues. Just maintenance really, 
like that one you posted. But there is no one going through 
fixing them. Well that one might end up getting fixed cause of 
the extra exposure.
Dec 19 2016
next sibling parent reply lobo <swamp.lobo gmail.com> writes:
On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote:

 On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei 
 Alexandrescu wrote:

 On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote:

 [...]


 https://issues.dlang.org/show_bug.cgi?id=16991


 Another issue onto the list of thousands, to collect dust for 
 the next few years til someone decides they want to use their 
 personal time to fix it. Just to highlight another problem, 
 there's a lot of trivial to fix issues. Just maintenance 
 really, like that one you posted. But there is no one going 
 through fixing them. Well that one might end up getting fixed 
 cause of the extra exposure.


Maybe you could fix one or two? As you say they're trivial and 
apparently no one else is doing it.

bye,
lobo
Dec 19 2016
next sibling parent Jerry <hurricane hereiam.com> writes:
On Tuesday, 20 December 2016 at 06:42:10 UTC, lobo wrote:

 On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote:

 On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei 
 Alexandrescu wrote:

 On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote:

 [...]


 https://issues.dlang.org/show_bug.cgi?id=16991


 Another issue onto the list of thousands, to collect dust for 
 the next few years til someone decides they want to use their 
 personal time to fix it. Just to highlight another problem, 
 there's a lot of trivial to fix issues. Just maintenance 
 really, like that one you posted. But there is no one going 
 through fixing them. Well that one might end up getting fixed 
 cause of the extra exposure.


 Maybe you could fix one or two? As you say they're trivial and 
 apparently no one else is doing it.

 bye,
 lobo


I have, sadly I have better things to do like the project I'm 
working on that's using D. I'd rather not soak up all my time 
fixing the tool and focus on what matters.
Dec 20 2016
prev sibling parent reply LiNbO3 <nosp m.com> writes:
On Tuesday, 20 December 2016 at 06:42:10 UTC, lobo wrote:

 On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote:

 On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei 
 Alexandrescu wrote:

 On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote:

 [...]


 https://issues.dlang.org/show_bug.cgi?id=16991


 Another issue onto the list of thousands, to collect dust for 
 the next few years til someone decides they want to use their 
 personal time to fix it. Just to highlight another problem, 
 there's a lot of trivial to fix issues. Just maintenance 
 really, like that one you posted. But there is no one going 
 through fixing them. Well that one might end up getting fixed 
 cause of the extra exposure.


 Maybe you could fix one or two? As you say they're trivial and 
 apparently no one else is doing it.

 bye,
 lobo


And have the patch wait in the PR queue until the end of time, 
not even acknowledged at all ?
The lack of focus goes hand in hand with the lack of manpower 
with some not-so-great results like we're seeing right now, at 
least IMO.
Dec 20 2016
next sibling parent lobo <swamp.lobo gmail.com> writes:
On Tuesday, 20 December 2016 at 08:20:32 UTC, LiNbO3 wrote:

 On Tuesday, 20 December 2016 at 06:42:10 UTC, lobo wrote:

 On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote:

 On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei 
 Alexandrescu wrote:

 On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote:

 [...]


 https://issues.dlang.org/show_bug.cgi?id=16991


 Another issue onto the list of thousands, to collect dust for 
 the next few years til someone decides they want to use their 
 personal time to fix it. Just to highlight another problem, 
 there's a lot of trivial to fix issues. Just maintenance 
 really, like that one you posted. But there is no one going 
 through fixing them. Well that one might end up getting fixed 
 cause of the extra exposure.


 Maybe you could fix one or two? As you say they're trivial and 
 apparently no one else is doing it.

 bye,
 lobo


 And have the patch wait in the PR queue until the end of time, 
 not even acknowledged at all ?
 The lack of focus goes hand in hand with the lack of manpower 
 with some not-so-great results like we're seeing right now, at 
 least IMO.


The perceived lack of focus is another matter, which I agree is 
disconcerting. I say perceived because I'm sure there is focus 
and a plan but it isn't visible from the outside. The core dev 
team seem to jump from one thing to the next with nothing going 
pushed thought the last 10% to completion so it all feels 90% 
complete.

bye,
lobo
Dec 20 2016
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
On Tue, 20 Dec 2016 08:20:32 +0000, LiNbO3 wrote:

 And have the patch wait in the PR queue until the end of time,
 not even acknowledged at all ?


When I've put in PRs for doc improvements, they've been reviewed 
relatively quickly.
Dec 21 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/16 11:38 PM, Jerry wrote:

 https://issues.dlang.org/show_bug.cgi?id=16991


 Another issue onto the list of thousands, to collect dust for the next
 few years til someone decides they want to use their personal time to
 fix it.


That's changing because we're starting to have permanent collaborators. 
I've kindly asked Razvan, one of our scholarship students, to take a 
look. Generally they will be focused on larger projects but fixing 
trivial bugs is a simple background activity.


 Just to highlight another problem, there's a lot of trivial to
 fix issues. Just maintenance really, like that one you posted. But there
 is no one going through fixing them. Well that one might end up getting
 fixed cause of the extra exposure.


I've just added the "trivial" keyword. If any concrete bug comes to mind 
please ascribe the keyword to it.


Thanks,

Andrei
Dec 20 2016
prev sibling next sibling parent reply Kelly Sommers <kell.sommers gmail.com> writes:
As an outsider to the D community but someone who has really 
wanted to love D the last few years I hope to shed some light 
from "outside the bubble" on why I haven't used D and why I use 
what I use and what I'm looking for. I hope this can be well 
received.

I write a lot of C and Go. But they aren't what I truly want in 
"systems" programming languages. I write high performance 
infrastructure code like databases or server software that 
handles millions of requests per second. One of my projects is an 
OSS HTTP server written in C that can serve 10 million 
requests/second.

Let's clarify a couple things about C and Go. C's 
advantages/disadvantages are:
1. Manual memory management. This could also be seen as a 
disadvantage but having the power to tailor memory access is an 
advantage for memory usage, allocation and access optimizafions. 
Let's face it, high perfowmcne code is all about memory access.
2. No GC pauses impacting request response times. Java, Go, .NET 
etc all have this problem.
3. Harder to write and write well, safely and securely.
4. Few concepts to learn.
5. Composability of libraries is poor. No package system, often 
not cross platform.
6. A lot of low level fundamental libraries are written in C like 
async I/O libraries or storage engine libraries.
7. Static compilation.

Go's advantages/disadvantages:
1. Static compilation.
2. No manual memory management.
3. Suffers from GC pauses.
4. Great composability of libraries. For example, you can easily 
"go get" a Redis protocol library, an ACID memory mapped 
persisted b+tree library and build a little database quite 
quickly.
5. Few concepts to learn.
6. Performance overhead when calling C libraries like storage 
engines.
7: The statement that Go is mostly used in scripting-like 
contexts isn't correct. It's very popular in the infrastructure 
space like databases and distributed systems implementations.
8. Lack of generics causes a lot of boilerplate code in 
comparison to other modern languages.

As an engineer who works on distributed systems in the scale of 
thousands of nodes I have to point out that GC'd languages need 
to be thought more as in the same category because of how they 
operate in production. You have to spend significant effort 
keeping these processses happy so that the GC's don't pause too 
much hurting response times. I argue all the time that GC'd 
languages are not systems languages. There's not enough control 
and you can't eliminate GC pauses completely and these GC's don't 
scale to modern physical hardware well.

But Go is popular in this category of space despite the 
GC/generics because of how composable infrastructure code is in 
the Go community. "go get" a Raft library, gossip library, 
storage library and you're off and running much faster than in 
other languages. However the overhead of calling C libraries and 
the GC impact performance. Go knows this weakness of the GC and 
has been working hard to eliminate GC pauses as much as possible. 
A great effort into sub-millisecond pauses with large heaps was 
recently achieved: 
https://github.com/golang/proposal/blob/master/design/17503-eliminate-rescan.md

What I really want is what C++ wanted to deliver but it doesn't. 
I want something better than writing C but with the same 
performance as C and the ability to interface with C without the 
performance loss and with easily composable libraries.

D in my opinion in some ways is close to these goals. It's 
simpler to understand and write than C++. It has the problem of 
being a GC'd language however and it's unclear to me if the GC in 
D is evolving like the Go GC is. I'm not happy about having to 
use a GC but if I have to I hope to see the one I'm investing on 
evolve because it most certainly impacts production systems very 
much.

The things I really want from D to really sway me would be the 
following (some already exist):
1. Evolve the GC like Go has.
2. No overhead calling C libraries.
3. Easily composable libraries.
4. Good IDE support.



likely something Go cannot solve and why there's an opportunity 
for another language to jump in with better performance.

The programming community hasn't found a good modern systems 
language yet that aligns with these tradeoffs. I actually think D 
and Swift (no GC, ARC, no calling C overhead) are closest to 
having the potential for the correct tradeoffs to be systems 
languages.

Rust probably is aligned more than anyone with these goals at the 
moment but every time I try to learn rust my head hurts and it's 
not enjoyable.

I hope this sheds some light on why I really like D but as an 
outsider what I'm looking and need in the space I build software 
and why I think D could fill a gap others aren't yet.

Thank you for reading my thoughts.
Dec 20 2016
next sibling parent qznc <qznc web.de> writes:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:

 The things I really want from D to really sway me would be the 
 following (some already exist):
 1. Evolve the GC like Go has.
 2. No overhead calling C libraries.
 3. Easily composable libraries.
 4. Good IDE support.


I agree.

1. takes surprisingly long. There is still no precise GC.

2. and 3. are already there. Well, libraries are never perfect, 
of course.

4. is proceeding, but slowly. Afaik no core dev uses an IDE.
Dec 20 2016
prev sibling next sibling parent reply thedeemon <dlang thedeemon.com> writes:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:

 What I really want is what C++ wanted to deliver but it 
 doesn't. I want something better than writing C but with the 
 same performance as C and the ability to interface with C 
 without the performance loss and with easily composable 
 libraries.

 D in my opinion in some ways is close to these goals. It's 
 simpler to understand and write than C++. It has the problem of 
 being a GC'd language however and it's unclear to me if the GC 
 in D is evolving like the Go GC is. ...

 The things I really want from D to really sway me would be the 
 following (some already exist):
 1. Evolve the GC like Go has.
 2. No overhead calling C libraries.
 ...


Bad news: without complete redesign of the language and turning 
into one more C++/CLI (where you have different kinds of pointers 
in the language for GC and non-GC), having C performance and 
Go-style low-pause GC is not really possible. You have to choose 
one. Go chose GC with short pauses but paid with slow speed 
overall and slow C interop. D chose C-level performance but paid 
for it with a slow GC.
Dec 21 2016
next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:

 On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers 
 wrote:

 [...]


 Bad news: without complete redesign of the language and turning 
 into one more C++/CLI (where you have different kinds of 
 pointers in the language for GC and non-GC), having C 
 performance and Go-style low-pause GC is not really possible. 
 You have to choose one. Go chose GC with short pauses but paid 
 with slow speed overall and slow C interop. D chose C-level 
 performance but paid for it with a slow GC.


If this is true, a blog post about it with more details is very 
welcome --Ilya
Dec 21 2016
next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko 
wrote:

 On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:

 On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers 
 wrote:

 [...]


 Bad news: without complete redesign of the language and 
 turning into one more C++/CLI (where you have different kinds 
 of pointers in the language for GC and non-GC), having C 
 performance and Go-style low-pause GC is not really possible. 
 You have to choose one. Go chose GC with short pauses but paid 
 with slow speed overall and slow C interop. D chose C-level 
 performance but paid for it with a slow GC.


 If this is true, a blog post about it with more details is very 
 welcome --Ilya


You may want to open PR for Mir Blog: 
https://github.com/libmir/blog
Dec 21 2016
prev sibling parent reply thedeemon <dlang thedeemon.com> writes:
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko 
wrote:

 On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:

 On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers 
 wrote:

 [...]


 Bad news: without complete redesign of the language and 
 turning into one more C++/CLI (where you have different kinds 
 of pointers in the language for GC and non-GC), having C 
 performance and Go-style low-pause GC is not really possible. 
 You have to choose one. Go chose GC with short pauses but paid 
 with slow speed overall and slow C interop. D chose C-level 
 performance but paid for it with a slow GC.


 If this is true, a blog post about it with more details is very 
 welcome --Ilya


Have you seen this one?
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
Dec 21 2016
next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 21 December 2016 at 14:50:31 UTC, thedeemon wrote:

 On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko 
 wrote:

 On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon 
 wrote:

 [...]


 If this is true, a blog post about it with more details is 
 very welcome --Ilya


 Have you seen this one?
 http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


Thanks for the link, will read
Dec 21 2016
prev sibling next sibling parent Jon Degenhardt <noreply noreply.com> writes:
On Wednesday, 21 December 2016 at 14:50:31 UTC, thedeemon wrote:

 On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko 
 wrote:

 On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon 
 wrote:

 On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers 
 wrote:

 [...]


 Bad news: without complete redesign of the language and 
 turning into one more C++/CLI (where you have different kinds 
 of pointers in the language for GC and non-GC), having C 
 performance and Go-style low-pause GC is not really possible. 
 You have to choose one. Go chose GC with short pauses but 
 paid with slow speed overall and slow C interop. D chose 
 C-level performance but paid for it with a slow GC.


 If this is true, a blog post about it with more details is 
 very welcome --Ilya


 Have you seen this one?
 http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


A recent blog post regarding the Go garbage collector with 
pertinent info: 
https://medium.com/ octskyward/modern-garbage-collection-911ef4f8bd8e
Dec 21 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2016 6:50 AM, thedeemon wrote:

 Have you seen this one?
 http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


Although I had called them write gates, write barriers are the same thing. Yes, 
that's the problem with implementing a generational collector in D.

I once tried to implement write barriers by using the hardware VM system. I'd 
mark the old generation pages as read-only. When the program would write to 
those pages, a seg fault happened. This would then run a handler in the GC code 
which would mark that page as "dirty", then write-enable the page, and restart 
the program at the point where it seg faulted.

This worked great. The only trouble was that the seg faulting path at runtime 
was so slow it ruined the speed advantage of not have write barriers. So I had 
to abandon it.

But that was long ago. Maybe the tradeoff is better these days with modern 
hardware. But I suspect that if other GC developers are not using this 
technique, it is still too slow.
Dec 21 2016
prev sibling next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Wed, 21 Dec 2016 11:36:14 +0000, thedeemon wrote:

 Bad news: without complete redesign of the language and turning into one
 more C++/CLI (where you have different kinds of pointers in the language
 for GC and non-GC), having C performance and Go-style low-pause GC is
 not really possible. You have to choose one. Go chose GC with short
 pauses but paid with slow speed overall and slow C interop. D chose
 C-level performance but paid for it with a slow GC.


You can implement write barriers as runtime calls, but omit them in  nogc 
code. However, this would be costly -- it's an expensive technique in 
general; the current GC mallocs each object instead of mmaping a range of 
memory; and in D you can't move heap objects safely, so you can't 
distinguish generations based on pointers (you'd have to mark GC data 
structures, and it's O(log n) to find the right one).

You can implement write barriers with mprotect. However, this won't give 
you good granularity. You just know that someone wrote something to an 8 
kilobyte block of memory that has a pointer in it somewhere. This 
requires the GC to use mmap instead of malloc, and it is strongly 
encouraged not to put pointer-free objects in the same page as objects 
with pointers.
Dec 21 2016
next sibling parent thedeemon <dlang thedeemon.com> writes:
On Thursday, 22 December 2016 at 03:57:10 UTC, Chris Wright wrote:


 You can implement write barriers as runtime calls, but omit 
 them in  nogc code.


That means redefining what  nogc means. Currently it basically 
means "does not GC-allocate" and you want to change it to "does 
not mutate GC-allocated objects" which is very different and 
hardly possible to check in compiler without further changing the 
language.


 However, this would be costly -- it's an expensive technique in 
 general;


Yep, that's what I'm saying. Fast GC has a price on the rest code 
speed. Fast code has a price on GC. Unless you separate them very 
clearly by language means.
Dec 21 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2016 7:57 PM, Chris Wright wrote:

 You can implement write barriers as runtime calls, but omit them in  nogc
 code.


 nogc code is code that doesn't allocate from the gc. It can still write to gc 
allocated objects, however, so that idea won't work.



 However, this would be costly -- it's an expensive technique in
 general; the current GC mallocs each object instead of mmaping a range of
 memory; and in D you can't move heap objects safely,


You can if using a "mostly copying" generational collector, which is what I did 
long ago. It works.


 so you can't
 distinguish generations based on pointers (you'd have to mark GC data
 structures, and it's O(log n) to find the right one).

 You can implement write barriers with mprotect. However, this won't give
 you good granularity. You just know that someone wrote something to an 8
 kilobyte block of memory that has a pointer in it somewhere. This
 requires the GC to use mmap instead of malloc, and it is strongly
 encouraged not to put pointer-free objects in the same page as objects
 with pointers.


Using mprotect works, and I wrote a generational collector using it long ago, 
but it is even slower.
Dec 21 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2016 3:36 AM, thedeemon wrote:

 Bad news: without complete redesign of the language and turning into one more
 C++/CLI (where you have different kinds of pointers in the language for GC and
 non-GC), having C performance and Go-style low-pause GC is not really possible.
 You have to choose one. Go chose GC with short pauses but paid with slow speed
 overall and slow C interop. D chose C-level performance but paid for it with a
 slow GC.


The trouble with a better GC is it usually entails changing the code generator 
to emit a "write gate" that goes along with assignments via a pointer. This 
write gate signals the GC that a particular block is being written to, so that 
block can be marked as "dirty". (Paging virtual memory systems do this 
automatically.)

What this implies is better GC performance comes at a cost of worse performance 
of the non-GC code. This strategy is effective for a language that makes very 
heavy use of the GC (like Java does), but for a language like D that uses the
GC 
lightly, it's a much more elusive benefit.
Dec 21 2016
prev sibling parent reply timmyjose <zoltan.jose gmail.com> writes:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:

 As an outsider to the D community but someone who has really 
 wanted to love D the last few years I hope to shed some light 
 from "outside the bubble" on why I haven't used D and why I use 
 what I use and what I'm looking for. I hope this can be well 
 received.

 I write a lot of C and Go. But they aren't what I truly want in 
 "systems" programming languages. I write high performance 
 infrastructure code like databases or server software that 
 handles millions of requests per second. One of my projects is 
 an OSS HTTP server written in C that can serve 10 million 
 requests/second.

 Let's clarify a couple things about C and Go. C's 
 advantages/disadvantages are:
 1. Manual memory management. This could also be seen as a 
 disadvantage but having the power to tailor memory access is an 
 advantage for memory usage, allocation and access 
 optimizafions. Let's face it, high perfowmcne code is all about 
 memory access.
 2. No GC pauses impacting request response times. Java, Go, 
 .NET etc all have this problem.
 3. Harder to write and write well, safely and securely.
 4. Few concepts to learn.
 5. Composability of libraries is poor. No package system, often 
 not cross platform.
 6. A lot of low level fundamental libraries are written in C 
 like async I/O libraries or storage engine libraries.
 7. Static compilation.

 Go's advantages/disadvantages:
 1. Static compilation.
 2. No manual memory management.
 3. Suffers from GC pauses.
 4. Great composability of libraries. For example, you can 
 easily "go get" a Redis protocol library, an ACID memory mapped 
 persisted b+tree library and build a little database quite 
 quickly.
 5. Few concepts to learn.
 6. Performance overhead when calling C libraries like storage 
 engines.
 7: The statement that Go is mostly used in scripting-like 
 contexts isn't correct. It's very popular in the infrastructure 
 space like databases and distributed systems implementations.
 8. Lack of generics causes a lot of boilerplate code in 
 comparison to other modern languages.

 As an engineer who works on distributed systems in the scale of 
 thousands of nodes I have to point out that GC'd languages need 
 to be thought more as in the same category because of how they 
 operate in production. You have to spend significant effort 
 keeping these processses happy so that the GC's don't pause too 
 much hurting response times. I argue all the time that GC'd 
 languages are not systems languages. There's not enough control 
 and you can't eliminate GC pauses completely and these GC's 
 don't scale to modern physical hardware well.

 But Go is popular in this category of space despite the 
 GC/generics because of how composable infrastructure code is in 
 the Go community. "go get" a Raft library, gossip library, 
 storage library and you're off and running much faster than in 
 other languages. However the overhead of calling C libraries 
 and the GC impact performance. Go knows this weakness of the GC 
 and has been working hard to eliminate GC pauses as much as 
 possible. A great effort into sub-millisecond pauses with large 
 heaps was recently achieved: 
 https://github.com/golang/proposal/blob/master/design/17503-eliminate-rescan.md

 What I really want is what C++ wanted to deliver but it 
 doesn't. I want something better than writing C but with the 
 same performance as C and the ability to interface with C 
 without the performance loss and with easily composable 
 libraries.

 D in my opinion in some ways is close to these goals. It's 
 simpler to understand and write than C++. It has the problem of 
 being a GC'd language however and it's unclear to me if the GC 
 in D is evolving like the Go GC is. I'm not happy about having 
 to use a GC but if I have to I hope to see the one I'm 
 investing on evolve because it most certainly impacts 
 production systems very much.

 The things I really want from D to really sway me would be the 
 following (some already exist):
 1. Evolve the GC like Go has.
 2. No overhead calling C libraries.
 3. Easily composable libraries.
 4. Good IDE support.



 likely something Go cannot solve and why there's an opportunity 
 for another language to jump in with better performance.

 The programming community hasn't found a good modern systems 
 language yet that aligns with these tradeoffs. I actually think 
 D and Swift (no GC, ARC, no calling C overhead) are closest to 
 having the potential for the correct tradeoffs to be systems 
 languages.

 Rust probably is aligned more than anyone with these goals at 
 the moment but every time I try to learn rust my head hurts and 
 it's not enjoyable.

 I hope this sheds some light on why I really like D but as an 
 outsider what I'm looking and need in the space I build 
 software and why I think D could fill a gap others aren't yet.

 Thank you for reading my thoughts.


As a complete beginner in D, your post makes a lot of sense to 
me. Also, that bit about Rust is spot on. It's nice for fancy 
little programs (and I've written quite a few of those), but 
babysitting the ownership and lifetimes system detracts away from 
the problem I'm trying to solve itself. That's too bad indeed.

I had given Go a try as well, but it does seem to have a very 
narrow focus (which Rob Pike has not been shy to claim) plus the 
lack of generics is very stultifying (at least for me). I do 
believe that Go did well for a few reasons - Rob Pike's strong 
hand in carrying out his mandate, a fabulous marketing team, and 
the simplistic but consistent nature of the language's design. In 
fact, Rust is also "popular" for very much the same marketing 
spearheaded by the likes of Steve Klabnik, but the language is 
way too complex, and the team in Mozilla just does not care about 
that.

I do love C++11 and newer, but I'd rather not use it for any new 
projects barring some weekend projects of my own. The type system 
is horrendously outdated. If they could make a clean break and 
make C++11 the basis, improve error checking, bounds-checking, 
and warning messages, and get rid of the C legacy (of course, 
that's never going to happen), it would make for a fine language.

I've come to D primarily because I want a modern safe(r) systems 
language with an excellent type system that I can use for my 
small-to-medium projects without having to spend days figuring 
out why the damned things is segfaulting all the time. I have 
been reading the threads on this forum, and not everything is 
perfect (understandably so), but it's been good going thus far!
Feb 19 2017
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 19 February 2017 at 12:12:07 UTC, timmyjose wrote:

 I do love C++11 and newer, but I'd rather not use it for any 
 new projects barring some weekend projects of my own. The type 
 system is horrendously outdated. If they could make a clean 
 break and make C++11 the basis, improve error checking, 
 bounds-checking, and warning messages, and get rid of the C 
 legacy (of course, that's never going to happen), it would make 
 for a fine language.


That language exists, it's called D. ;-)
Feb 19 2017
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 Documentation:
 --------------


You forgot one here. Dub's documentation is simply atrocious *and 
it's the official package manager*. Throw around things terms 
like "you can use Git submodules for that" as if it's a trivial 
thing. But I'm not going to say more. I realized a while back 
that this community is incapable of understanding what is wrong 
with Dub's documentation.
Dec 20 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/20/2016 2:46 AM, bachmeier wrote:

 Dub's documentation is simply atrocious *and it's the
 official package manager*. Throw around things terms like "you can use Git
 submodules for that" as if it's a trivial thing. But I'm not going to say more.
 I realized a while back that this community is incapable of understanding what
 is wrong with Dub's documentation.


We do accept pull requests, though.

Heck, just pick *one* thing that grinds your gears, like the quotation above, 
and fix it.
Dec 20 2016
parent reply bachmeier <no spam.net> writes:
On Tuesday, 20 December 2016 at 11:00:02 UTC, Walter Bright wrote:

 On 12/20/2016 2:46 AM, bachmeier wrote:

 Dub's documentation is simply atrocious *and it's the
 official package manager*. Throw around things terms like "you 
 can use Git
 submodules for that" as if it's a trivial thing. But I'm not 
 going to say more.
 I realized a while back that this community is incapable of 
 understanding what
 is wrong with Dub's documentation.


 We do accept pull requests, though.

 Heck, just pick *one* thing that grinds your gears, like the 
 quotation above, and fix it.


But I don't use Dub or Git submodules. I use R's package manager, 
which is both well-documented and does not require the user to 
write a configuration file to use the package. Of course that is 
not an option for very many D users.

I guess the bigger problem is that Dub is allowed to be the 
official package manager even though nobody bothered to write 
real documentation. In other communities, contributions have to 
meet standards for both code and documentation.
Dec 20 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/20/2016 3:12 AM, bachmeier wrote:

 Heck, just pick *one* thing that grinds your gears, like the quotation above,
 and fix it.


 But I don't use Dub or Git submodules. I use R's package manager, which is both
 well-documented and does not require the user to write a configuration file to
 use the package. Of course that is not an option for very many D users.

 I guess the bigger problem is that Dub is allowed to be the official package
 manager even though nobody bothered to write real documentation. In other
 communities, contributions have to meet standards for both code and
documentation.


If you don't want to fix anything, ok. But you can still file bugzilla issues 
for things that you find.
Dec 20 2016
parent reply bachmeier <no spam.net> writes:
On Tuesday, 20 December 2016 at 11:52:05 UTC, Walter Bright wrote:


 If you don't want to fix anything, ok. But you can still file 
 bugzilla issues for things that you find.


This is a valid point. I just did that for some std.datetime 
functions that need improved documentation.
Dec 20 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/20/2016 7:44 AM, bachmeier wrote:

 On Tuesday, 20 December 2016 at 11:52:05 UTC, Walter Bright wrote:


 If you don't want to fix anything, ok. But you can still file bugzilla issues
 for things that you find.


 This is a valid point. I just did that for some std.datetime functions that
need
 improved documentation.


Thank you. Many people look for things to help with, and this makes it easy for 
us to direct them to bugzilla to look for something they can do. It also helps 
ensure that issues don't scroll away on the n.g. and get lost.
Dec 20 2016
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 20 December 2016 at 10:46:28 UTC, bachmeier wrote:

 On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 Documentation:
 --------------


 I realized a while back that this community is incapable of 
 understanding what is wrong with Dub's documentation.


Michael Parker is working on that from last I heard.
Dec 20 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 20 December 2016 at 11:17:19 UTC, Guillaume Piolat 
wrote:


 Michael Parker is working on that from last I heard.


Yes, he is, though slowly. I can give it more priority after the 
New Year.
Dec 20 2016
next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 20 December 2016 at 14:18:38 UTC, Mike Parker wrote:

 On Tuesday, 20 December 2016 at 11:17:19 UTC, Guillaume Piolat 
 wrote:


 Michael Parker is working on that from last I heard.


 Yes, he is, though slowly. I can give it more priority after 
 the New Year.


Thanks for doing this!
Dec 20 2016
prev sibling parent bachmeier <no spam.net> writes:
On Tuesday, 20 December 2016 at 14:18:38 UTC, Mike Parker wrote:

 On Tuesday, 20 December 2016 at 11:17:19 UTC, Guillaume Piolat 
 wrote:


 Michael Parker is working on that from last I heard.


 Yes, he is, though slowly. I can give it more priority after 
 the New Year.


As I recall, you made your announcement in response to one of my 
previous complaints, and I'm excited that you are doing it. This 
is going to be a very important document for D adoption.
Dec 20 2016
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 20 December 2016 at 10:46:28 UTC, bachmeier wrote:

 I realized a while back that this community is incapable of 
 understanding what is wrong with Dub's documentation.


Many of the top folks don't use it, but I recall Andre commenting 
on trying to use it and getting frustrated.

It's better than than it was 6 months ago, but still could be 
improved.
Dec 20 2016
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 


Also on YN: https://news.ycombinator.com/item?id=13217529
Dec 20 2016
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 [...]


Also on YN: https://news.ycombinator.com/item?id=13217529
Dec 20 2016
prev sibling next sibling parent ryan <ryanlmartin gmail.com> writes:
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 I split this from the "Re: A betterC modular standard library?" 
 topic because my response is will be too much off-topic but the 
 whole thread is irking me the wrong way. I see some of the same 
 argument coming up all the time, with a level of frequency.

 D has not market:
 -----------------

 A lot of times people complain that D has no real audience / 
 market. Is D the perfect system. No... But lets compare to 
 those other languages shall we? Now this is my opinion, so take 
 it with a bit of salt.

 Go: Its is a "simple" language. But its forced restrictions at 
 times are so annoying its saps all the fun out of the coding. 
 Its not really C. Its more Basic on steroids. Unfortunately 
 while Go has huge amount of traction and packages ( 70k from my 
 count ), the quality is also... It has a few real gems those 
 gems are a result of the mass amount of packages. It has its 
 own market. A scripting replacement market mostly.

 Crystal: Is pure Ruby focused. Again, it draws in a lot of 
 people with a Ruby background. Interesting language that is 
 already splitting away from Ruby comparability.

 Nim/Julia/Numpy/Numba: Are very Python like focused. Nim will 
 disagree but its very clear. Again, the focus seems to draw in 
 more scripting language orientated people, mostly from the 
 Python area.

 Rust: Promotes itself to be better C but its simply a more 
 complex language design. A over active amount of fans, that do 
 not understand its complex. Less fun to get into. Reminds me 
 too much of Perl.

 D is C++ but improved/simplified. Its not to hard to get into, 
 its more easy for anybody from a C background.

 Take it from a guy that spend a large part of his life in PHP. 
 I feel more at home with D, then with all the other languages. 
 The moment you get over a few hurdles, it becomes a very easy 
 language. My point is that D does fit in a specific market. It 
 fits in between C++ and scripting languages like PHP ( that has 
 a more C background ).

 Its not going to convert a lot of C++ people. Sorry but its 
 true. C++ has been evolving, the people who invested into C++ 
 have very little advantage of going to D. The whole focus on 
 C++ people marketing is simply wrong! Every time this gets 
 mentioned in external forums, the language gets a pounding by 
 people with the same argumentation. Why go for D when C++ 20xx 
 version does it also.

 Trusting a person with C like scripting language ( like 
 PHP/Java ) background into C++, well that is fun <sarcasm>. 
 People always seem to say that D has no real advantage but it 
 has. Its easier C++ for people who do not come from C/C++. 
 Maybe i am downplaying this but for love of the gods, the focus 
 is wrong. I am the same guy that complained a while ago about 
 the website its examples being too "advanced" and it scares a 
 big potential group of people away.

 Community:
 ----------

 But community wise there is a real issue. People are friendly 
 and help out. But it feels like everybody is doing there own 
 thing.

 I see a lot of people arguing a lot about D and sorry to say 
 but at times it sounds like a kindergarten. Walter/Andrei are 
 right that updates and changes need to be focused on the 
 standard library. Maybe its because people who use D are more 
 into proprietary software, that there is less community 
 response with work going into the library. But ... see below in 
 Walter / Andrei section.

 Library ( and runtime bloat ):
 ------------------------------

 But it also does not diminish some of the requests. When i 
 write a simple program that uses the socket, standard, string 
 and conv library. All it does is open a TCP socket and send a 
 response back. This is not supposed to take 2.4MB in memory, 
 with a 1.2MB compiled executable ( 450kb o file ). Full blown 
 Nginx uses only one MB more for its core in memory. For 
 something so simple, its a little bit crazy.

 When i make a plugin in Go 1.8, it uses 10KB. A plugin ( shared 
 C library ) in D uses almost 200KB. Using C++ it results into 
 another 10KB file. Maybe i am a total noob but some things make 
 no sense. It gives me the impression that some massive run 
 times are getting added or there is some major library bloat.

 Library Standardization:
 ------------------------

 Some of the proposals sounds very correct. The library needs to 
 be split. Every module needs its own GIT. People need to be 
 able to add standard modules ( after approval ).

 No offense but where is the standard database library for D? 
 There is none. That is just a load of bull. Anybody who wants 
 to program in any language expect the language to have a 
 standard database library! Not that you need to search the 
 packages for a standard library. I have seen one man projects 
 that have more standard library support then D.

 Its one of the most basic packages. How about a simple web 
 server? A lot of languages offer this by default. It gets 
 people going. vibe.d is not a simple web server. It's not a 
 standard package.

 If you are a low level programmer, sure, you can write you way 
 around it. Despite my PHP handicap i am writing a Sqlite 
 wrapper for my work. I do not use 3th party packages because a) 
 i do not know the code b) the fear that the work will be 
 abandoned. I can excuse (a), when i know its the standard 
 library because there will always be people willing to work on  
 the standard library.

 Documentation:
 --------------

 I do not use it. Its such a mess to read with long paragraphs 
 and a LOT of stuff not even documented. Like the whole C 
 wrappers etc. My personal bible is simple: Google search for 
 examples and Ali's book for some rare cases.

 When i compare this to my PHP background. Hmmmm, what does x 
 function do again. Google function. Webpage with X function. 
 Links to related function. Examples. Clear simple answers.

 This automated documentation generation is the same **** i see 
 in other "new" languages. Impersonal is the word to describe 
 it. Sure there is some tutorial in the documentation that way 
 too long ( never hear of chapters? ) but a lot of that 
 information needs to be with the functions.

 Maybe other developers can make more heads or tails out of the 
 API documentation but like i said, i do not use it. Every time 
 i need a advanced feature its hardly documented. With 
 references and text buildups that is just annoying.

 Editor support:
 ---------------

 What a struggle. Visual Studio C is probably the editor with 
 the best 3th party support.

 IntelliJ: Hardly any plugins. Limited to IntelliJ platform and 
 not the rest.
 Atom: Same issue, hardly any advanced D support.
 Vim: Lets not go there.
 3Th party D IDE's: A lot simply are designed for local working, 
 white background ( uch ), etc...

 I can go on. For me it has been a struggle to find the perfect 
 editor. Extended IDE's like IntelliJ have hardly support. There 
 are a lot of plugins to add D to editors but most are long time 
 dead or incomplete.

 Try remote editing D and see how much fun it is. Most Editors 
 or IDE with proper remote edit ability, have lacking D 
 supported plugins.

 Too many need 3th party to do something that D needs to support 
 from itself:

 dcd - Used for auto completion
 dfmt - Used for code formatting
 dscanner - Used for static code linting
 ...

 This needs to be in the default installation of dmd! It makes 
 no sense that these are not included.


 Future:
 --------

 You want D to have traction. Marketing, more library support, 
 less focus on adding even more advanced features, fixing issues 
 ( like better GC ), CTFE ( Stefan is dealing with that ), 
 Documentation, better Editor support...

 Walter / Andrei:
 ----------------

 No offense guys, just something that i see in a lot of posts. 
 The hinting at people to add more to the standard libraries. 
 That little push. But frankly, its annoying when nothing gets 
 done.

 People complain about x feature. You tell people to add to the 
 standard library or bring the project in. But anybody who has 
 ever read this forum sees how adding things to the language is 
 LONG process and a lot of times idea's get shot down very fast.

 For the standard library there is no process as far as i can 
 tell. Experimental at best, where code seems to have a nice 
 long death.

 Just needed to get this off my chest. The problems with D are 
 LONG TIME known. Anybody who spends some time reading the 
 forums sees the exact same things.

 My advice Walter / Andrei: Stop trying to add new things to the 
 code. It works. Its not going anywhere. There are no features 
 that you can add, that people can not already do. Maybe it 
 takes a few longer lines but those are not the issues.

 Focus on improving the other issues like stated above. Maybe 
 also deal with some of the speed  bloat issues. If you ask 
 people to help, give them the motivation to do so.

 Bring more projects into D. When you have people like Webfreak 
 making workspace-d, to simply the installation of those almost 
 required editor extensions, it tells you that D has a issue.


 Ilya's proposals are too extreme and need a middle ground. But 
 he is not wrong.

 Seb posted a massive list of modules that can be standard 
 candidates. And the response is more or less ignore it. People 
 who work on Standard libraries are more motivated. Bring  them 
 into the fold. But it seems that they simple get ignored.

 Like i said, please work on standard libraries is not the 
 answer. It does not motivate people ( especially when in the 
 same text you end up breaking down people there proposals ). 
 Maybe its not the intention but it comes over like this.

 Why is there no forum part for proposals about libraries that 
 get added to Phobos ( why is it even still called that. Call it 
 standard library and be done with it. It only confuses new 
 people ). The current forum is a pure spam forum.

 You need a Standard forum. With subbranches for std.xxx, 
 std.xxx, std... Let people talk about improvements there. If 
 people want to add a new branch, let them put up a proposal and 
 do NOT mothball it for months in discussions.

 Hell, the whole "D Programming Language - Development" forum is 
 so much spam, it becomes almost useless. Its a distraction to 
 post each issue there with 0 responses on 95%.

 End Rant:
 ---------

 Sorry for the long text but as somebody who has been reading 
 the forums for a while now, its just annoying to see some of 
 the bickering.

 But i simply get frustrated seeing the direction where relative 
 simple things get overlooked for more complex features! D 
 already is a great language but it REALLY has issue on several 
 departments. It does not need more boilerplate / expansion, it 
 needs focus! Most of the points that i bring up are not that 
 complex. But it takes a community manager / moderator to keep 
 topics a bit more focused. Not somebody who will go into 
 endless discussions with people ( not naming names ... Andrei 
 ;) ). Sorry guys but it feels like you are too technical 
 focused and not thinking about the bigger picture. Suggesting 
 things does not work when nobody gives people the chance to 
 prove themselves.

 Give people the ability to add more to std.experimental. Give 
 it its own forum part. Give people actual hope that there work 
 can be added. I have seen several ex-D programmers, who 
 complained about D regarding issues like this. If D wants to be 
 a community project, then act like a community project. Because 
 now, its just a contribution project where some people have 
 easier access to add stuff and other walk against a brick wall 
 of months ( and give up ).

 Its late... already spend almost two hours writing this, that i 
 was able to spend on writing actual code. And i am going to 
 take a break from reading this forum, it sucks the life out of 
 people and they spending all the time on bickering over details 
 and eventually not getting a darn thing done. Already 
 overworked at work + my own D project.


Rust doesn't promote itself as a better C. It promotes itself as 
a replacement for C/C++ which is not the same thing.
Dec 20 2016
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 I split this from the "Re: A betterC modular standard library?" 
 topic because my response is will be too much off-topic but the 
 whole thread is irking me the wrong way. I see some of the same 
 argument coming up all the time, with a level of frequency.

 D has not market:
 -----------------


It has market, a broad one. Just like C++, depends on your use 
case.

 Go: Its is a "simple" language.


People are swayed by popular stuff.


 D is C++ but improved/simplified. Its not to hard to get into, 
 its more easy for anybody from a C background.


True. Every guy I showed says that.

But setting up development environment for D is not a straight 
forward thing (Undocumented stuff, huge blocker for new users).


 Take it from a guy that spend a large part of his life in PHP. 
 I feel more at home with D, then with all the other languages. 
 The moment you get over a few hurdles, it becomes a very easy 
 language. My point is that D does fit in a specific market. It 
 fits in between C++ and scripting languages like PHP ( that has 
 a more C background ).


IMO Walter/Andrea cannot do much about these stuff. "Car 
engineers are not the best riders".



 Its not going to convert a lot of C++ people. Sorry but its 
 true. C++ has been evolving, the people who invested into C++ 
 have very little advantage of going to D. The whole focus on 
 C++ people marketing is simply wrong! Every time this gets 
 mentioned in external forums, the language gets a pounding by 
 people with the same argumentation. Why go for D when C++ 20xx 
 version does it also.


Because most people here are working on proprietary/production 
code that has something to do with C/C++ or they were much into 
them before D. Requests/complains here are *mostly* either 
selfish or are assumptions on what they think will make D shine 
(of course, from their own head).


 Community:
 ----------



 But it feels like everybody is doing there own thing.


IMO, they do what will help their own workflow (what they get 
paid for). It makes sense.

However, the number of potentially helpful Dub packages is 
growing. But the incomplete/I-came-with-this-during-a-project 
packages are problematic. They are usually not well documented 
and do not tackle more use cases. This is bad for the ecosystem.

They should be marked as incomplete/not-to-be-inproved



 I see a lot of people arguing a lot about D and sorry to say


I think people argue on things they care about, directly or 
indirectly. I do too ;) Its good, as long as it's not selfish.


 Documentation:
 --------------


Documentation is a really hard/time consuming task to do. Unless 
we have a lot of hands on deck.


 I do not use it. Its such a mess to read with long paragraphs 
 and a LOT of stuff not even documented. Like the whole C 
 wrappers etc. My personal bible is simple: Google search for 
 examples and Ali's book for some rare cases.


Yeah. Difficult to see this issue if you are too/very technical.



 Editor support:
 ---------------


Will help to specify what exactly is missing (linting?, easy 
debugging?).



 Future:
 --------

 You want D to have traction.


My little experience tells me the future is attributed to SO MANY 
factors.

 Walter / Andrei:
 ----------------


Hire Steve Jobs


 End Rant:
 ---------


GC is not a blocker for me. Most people complain about GC in D 
but thats for their use case. Don't speak for everyone or say D 
will NEVER gain traction (its only in your head).


Marketing Suggestion
----------------

Go for startups/students/newbies. So many startups are establish 
everyday. They don't have huge C/C++ code base.



 Dec 20 2016



prev sibling next sibling parent reply O-N-S <ozan.nurettin.sueel gmail.com>  writes:


On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 I split this from the "Re: A betterC modular standard library?" 
 topic because my response is will be too much off-topic but the 
 whole thread is irking me the wrong way. I see some of the same 
 argument coming up all the time, with a level of frequency.


Five stars of five!

Regards, Ozan



 Dec 20 2016



  parent reply Andrey <avraliov gmail.com>  writes:


On Wednesday, 21 December 2016 at 07:47:08 UTC, O-N-S wrote:

 On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 I split this from the "Re: A betterC modular standard 
 library?" topic because my response is will be too much 
 off-topic but the whole thread is irking me the wrong way. I 
 see some of the same argument coming up all the time, with a 
 level of frequency.


 Five stars of five!

 Regards, Ozan


Read all branche of topic. See ability to make social research.

Age'meter)))

Andrei,Walter > 45;
Benjiro,Dicebot 20-27;
others - difficult to say right now; need more time;

don't want to upset anyone, just a joke )))



 Dec 21 2016



  parent  ikod <geller.garry gmail.com>  writes:


On Wednesday, 21 December 2016 at 09:35:31 UTC, Andrey wrote:

 On Wednesday, 21 December 2016 at 07:47:08 UTC, O-N-S wrote:

 On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 I split this from the "Re: A betterC modular standard 
 library?" topic because my response is will be too much 
 off-topic but the whole thread is irking me the wrong way. I 
 see some of the same argument coming up all the time, with a 
 level of frequency.


 Five stars of five!

 Regards, Ozan


 Read all branche of topic. See ability to make social research.

 Age'meter)))

 Andrei,Walter > 45;
 Benjiro,Dicebot 20-27;
 others - difficult to say right now; need more time;

 don't want to upset anyone, just a joke )))


How do you use language is more important than your age. 
Scientist or AI developer expect highest performance for 
number-crunching and don't care about fast and easy 
development/deployment/etc. Devops (like me) don't care about 
super-performance, but care about easy development (read - 
libraries availabilty, easy debugging, etc) and deployment, 
gamedev probably care about GC and I don't know what else. 
Language core team can choose to care about every or only about 
some specific categories of developers.

And one note on volunteer model of language development - it have 
obvious pro and contra. how much this "contra" affect language 
progress depends on the language creators and community goals.



 Dec 21 2016



prev sibling next sibling parent reply Chris Wright <dhasenan gmail.com>  writes:


 Library Standardization:
 ------------------------
 
 Some of the proposals sounds very correct. The library needs to be
 split. Every module needs its own GIT. People need to be able to add
 standard modules ( after approval ).


I can't agree with you there. There are a lot of dependencies between 
modules.


 No offense but where is the standard database library for D? There is
 none. That is just a load of bull. Anybody who wants to program in any
 language expect the language to have a standard database library! Not
 that you need to search the packages for a standard library. I have seen
 one man projects that have more standard library support then D.



libraries. Most other languages don't.

These interfaces don't let you connect to any database. You still need a 
library to connect to a specific database.

With the rise of document databases and alternate query systems, it's 
harder to define a generic database library. It's still possible to write 
one for SQL databases.


 I do not use 3th party packages


The standard library needs a rigorous approval process. That takes time 
and human attention for the review and to address concerns identified 
during review.

D is marginal, and that means we simply don't have the time to get these 
things done.


 Documentation:
 --------------
 
 I do not use it. Its such a mess to read with long paragraphs


Long paragraphs describing the details of what a thing does is generally 
a good thing. MSDN's documentation is like that.

The "mess" part is when we have five hundred identifiers documented in 
one web page. dpldocs.info is much better about this.


 and a LOT of stuff not even documented.


There's no excuse for that.


 This automated documentation generation is the same **** i see in other
 "new" languages.


The documentation is hand-written. We don't have a tool capable of 
annotating, say, std.string.detab with "Replace each tab character in s 
with the number of spaces necessary to align the following character at 
the next tab stop." without human intervention. That would be impressive, 
though.

The HTML is generated by a tool.


 Editor support:
 ---------------
 
 What a struggle. Visual Studio C is probably the editor with the best
 3th party support.


VS Code isn't terrible. It's got the disadvantage that it tries to 
autocomplete every possible thing -- so you get __monitor and __vptr 
first, and the other options include things you can't access.


 Too many need 3th party to do something that D needs to support from
 itself:
 
 dcd - Used for auto completion
 dfmt - Used for code formatting
 dscanner - Used for static code linting ...
 
 This needs to be in the default installation of dmd! It makes no sense
 that these are not included.


From a usability standpoint, I agree.

From a political standpoint, it's unsurprising that they're not included.


 Future:
 --------
 
 You want D to have traction.


That's *a* goal, but it's not the goal that's closest to most of our 
hearts, I think. Popularity doesn't exactly bring enjoyment -- it can 
remove some annoyances, but it's easier to work around those annoyances. 
It isn't fulfilling. And it doesn't pay the bills.


 Marketing, more library support, less focus
 on adding even more advanced features, fixing issues (
 like better GC ),


There are huge barriers to bringing D's GC to the state of the art. Some 
improvements could be made, though. For instance, the GC currently scans 
heap objects scattered about the whole heap. Using separate virtual 
address ranges for objects with pointers and objects without might 
improve efficiency somewhat.


 CTFE ( Stefan is dealing with that ), Documentation,
 better Editor support...


I think code-d could potentially be extended to install its dependencies, 
which would improve the situation there.


 Walter / Andrei:
 ----------------
 
 No offense guys, just something that i see in a lot of posts. The
 hinting at people to add more to the standard libraries. That little
 push. But frankly, its annoying when nothing gets done.
 
 People complain about x feature. You tell people to add to the standard
 library or bring the project in. But anybody who has ever read this
 forum sees how adding things to the language is LONG process and a lot
 of times idea's get shot down very fast.


The language is *very* conservative. The standard library is merely 
cautious. But since there's no cost to adding a package to dub, that 
doesn't prevent code from being written and reused. Except by those who 
refuse to go outside the standard library, and for those people, I would 



 For the standard library there is no process as far as i can tell.
 Experimental at best, where code seems to have a nice long death.


It could be much better documented.

The process for small changes:

* Make the change.
* Make a pull request.

The process for large changes:

* Propose it here, with your initial design. Get feedback.
* Implement it as a dub package.
* Ask for a formal review here.
* Address feedback.
* Make a pull request.


 Give people the ability to add more to std.experimental. Give it its own
 forum part.


Nothing stops you from adding dub packages using the namespace 
std.experimental. The tradition previously has been to use stdx for 
modules that are intended for the standard library.

An incubator organization might be appropriate as an intermediate between 
standard library and individuals' dub packages -- easier entry than the 
standard library, but multiple people are on hand to handle bugs.



 Dec 21 2016



  parent reply WebFreak001 <d.forum webfreak.org>  writes:


On Thursday, 22 December 2016 at 04:47:06 UTC, Chris Wright wrote:

 CTFE ( Stefan is dealing with that ), Documentation,
 better Editor support...


 I think code-d could potentially be extended to install its 
 dependencies, which would improve the situation there.


It does already do that though :/



 Dec 24 2016



  parent reply David Gileadi <gileadis NSPMgmail.com>  writes:


On 12/24/16 5:11 PM, WebFreak001 wrote:

 On Thursday, 22 December 2016 at 04:47:06 UTC, Chris Wright wrote:

 CTFE ( Stefan is dealing with that ), Documentation,
 better Editor support...


 I think code-d could potentially be extended to install its
 dependencies, which would improve the situation there.


 It does already do that though :/


Will it auto-update them as new versions are released, or when code-d is 
updated?



 Dec 26 2016



  parent  WebFreak001 <d.forum webfreak.org>  writes:


On Monday, 26 December 2016 at 19:37:34 UTC, David Gileadi wrote:

 On 12/24/16 5:11 PM, WebFreak001 wrote:

 On Thursday, 22 December 2016 at 04:47:06 UTC, Chris Wright 
 wrote:

 CTFE ( Stefan is dealing with that ), Documentation,
 better Editor support...


 I think code-d could potentially be extended to install its
 dependencies, which would improve the situation there.


 It does already do that though :/


 Will it auto-update them as new versions are released, or when 
 code-d is updated?


it will only update workspace-d and only when the plugin updates 
and requires a new version



 Dec 26 2016



prev sibling next sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com>  writes:


On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:

 D has not market:
 -----------------

 A lot of times people complain that D has no real audience / 
 market. Is D the perfect system. No... But lets compare to 
 those other languages shall we? Now this is my opinion, so take 
 it with a bit of salt.


People who are complaining that D has no market aren't using the 
language on the whole - or are using it for private projects and 
would like to use it for work but don't know of any professional 
opportunities where they can do so.  The latter is a high quality 
problem to have for an emerging language because it means people 
find some reason to want to use the language, and those who care 
about using good tools tend to be better programmers than those 
who don't.

Still, it's not true that D has no real market, because the 
userbase is demonstrably growing.  A complex creature matures 
more slowly than a simple one - what's significant is not that D 
does not have an official corporate sponsor of the kind that Go 
has (Sociomantic plays a different role, as I understand it), but 
that it is flourishing in spite of not having one and in spite of 
the absence of any kind of marketing orientation.  That says 
quite a lot about its intrinsic merits, and we're in an era where 
the pendulum is shifting from shiny things sponsored by large 
corporations to giving a greater chance to more grass-roots 
organic developments.

When you have a small market share, it's easy to win.  You don't 
need to appeal to "a lot of C++ people" - just a few of them, a 
few frustrated Python guys, and so on.  D fits quite well the 
Innovator's Dilemma described by Clayton Christensen.  It's a 
positive not a negative that many prefer to dismiss it since it 
makes it easier for it to gain a hold in certain niches, draw 
energy from such and then spread into adjacent niches.


 I see a lot of people arguing a lot about D and sorry to say 
 but at times it sounds like a kindergarten.


People who care about excellence will tend to argue a lot - see 
Andy Grove's 'constructive confrontation', Charles Koch's 'market 
based management', and Ray Dalio's 'Principles'.  The key thing 
is what happens in response to that.  The language and its 
documentation are better now than a year ago, and a year ago were 
better then the previous year.  It's not perfect, but life never 
is.


 Maybe its because people who use D are more into proprietary 
 software, that
 there is less community response with work going into the 
 library.


If that's true (and I think it might be), that's a very positive 
thing, because most software is proprietary software, and 
adoption by companies when successful will tend to provide a 
future source of support and energy for the ecosystem.  You can 
see this already with Sociomantic's sponsorship, but they aren't 
the only ones.  I've paid for some small improvements in dub's 
shared library support myself (-fPIC did not propagate which made 
using dub to build shared libraries on linux a bit tricky, but it 
does now, or will do once PRs are accepted), and you get to 
excellence from many little improvements of this sort.

So if you want to improve the language and its ecosystem, the 
best way is to contribute pull requests or $$$s - the Foundation 
now accepts individual donations, and it's also open to corporate 
sponsorship, I believe.  One should be a bit patient in expecting 
changes from the creation of the Foundation - it's an awful lot 
of work to set something up, and once that's done to figure out 
how to deploy resources to efficiently make a difference.  It's 
quite impressive what has been done already - very smart approach 
to start with institutions one has a personal/national connection 
with and where great people are much more available than in some 
other countries.

And on the other hand, pull requests don't need to take much 
energy.  I don't have much time, but I noticed the curl examples 
were out of date - string vs char[] if I recall right, and they 
were annoying me, so I fixed them and they were pulled pretty 
much immediately.

Most D users don't spend much time on the forums or IRC because 
they haven't time for it since they are actually using D to get 
stuff done.  Look at the list of corporate users, and look at the 
small share of the people working on D in these companies in 
forum discussions.  And that's only a subset of commercial D 
users.

Languages reach explosive takeoff not when they make a big change 
in strategy but when external conditions change in such a way 
that the problem the language solves suddenly becomes much more 
important.  Just as Japanese cars didn't used to be very good - 
and who would want a rinky dink thing like they used to be.  But 
then energy prices exploded in the 70s, and peoples' priorities 
changed - and the poor US auto-makers, complacent and bloated in 
their prior success didn't know what had hit them.  I've written 
a bit elsewhere about such changing conditions that might be 
relevant today.  Close to 250k people read it and so far I didn't 
get a good argument to the contrary.  Though it's hard to make 
predictions, especially about the future...


 If you are a low level programmer, sure, you can write you way 
 around it. Despite my PHP handicap i am writing a Sqlite 
 wrapper for my work. I do not use 3th party packages because a) 
 i do not know the code b) the fear that the work will be 
 abandoned. I can excuse (a), when i know its the standard 
 library because there will always be people willing to work on  
 the standard library.


It's not exactly much work to read the code for a basic sqlite 
wrapper and to become quite familiar with it.  (And it wouldn't 
after that be much work to improve the docs just a little bit).  
Isn't everyone reinventing the wheel somewhat part of the 
problem?  And if you're familiar with it, the work being 
abandoned isn't really such a risk.  If you force an enormous 
step change in the size of the standard library, it doesn't 
necessarily automatically bring in more resources to work on 
parts of it people didn't care about before. So I agree with 
Andrei's vision of favouring a larger standard library, but it's 
probably also the right approach to have an organic approach as 
we do.


 I do not use it. Its such a mess to read with long paragraphs 
 and a LOT of stuff not even documented. Like the whole C 
 wrappers etc. My personal bible is simple: Google search for 
 examples and Ali's book for some rare cases.


Ali's book is pretty good, and I have found it easy enough to use 
the C bindings (not sure what you mean by wrappers) - just pull 
up the C API in one window, and the source code for the binding 
in another.  Yes - a one-off upfront price in the beginning to 
become more familiar with it, but it pays off over time, at least 
in many uses.


 Editor support:


Sublime text and sometimes vim work well enough for me, though 
these things are very personal.  For the others, have you 
contributed anything - time or money in making them better?  If 
wishes were horses, beggars would ride.  And contribution of 
either has a higher value than just the thing itself, because it 
also tends to energise the project - look at the frustration 
Basil experienced regarding his IDE project.  It's good to have 
high standards, but one should have some appreciation also for 
the gift that people make of their time, work, and energy in ways 
that don't always lead to the gratitude that one might expect.

You wouldn't believe how little money or support, intelligently 
applied, it can take to indirectly lead to quite big changes...


 Try remote editing D and see how much fun it is.


vim has always worked well enough for me.  or sublime on occasion.


 Seb posted a massive list of modules that can be standard 
 candidates. And the response is more or less ignore it. People 
 who work on Standard libraries are more motivated. Bring  them 
 into the fold. But it seems that they simple get ignored.


Rome wasn't built in a year.  Great things are achieved by taking 
baby steps, compounded over time.  And if one does what little 
one can, others are inspired by it.  Enthusiasm and a 
constructive attitude are infectious in my experience.


 ;) ). Sorry guys but it feels like you are too technical 
 focused and not thinking about the bigger picture. Suggesting 
 things does not work when nobody gives people the chance to 
 prove themselves.


Yes - but languages are founded on different principles.  D is an 
organic ecosystem oriented to people who care about technical 
things.  Technical excellence brings in people with resources who 
find technical questions more important than marketing.  It takes 
time sometimes.



Laeeth.



 Dec 27 2016



  parent reply Jerry <hurricane hereiam.com>  writes:


On Tuesday, 27 December 2016 at 16:36:10 UTC, Laeeth Isharc wrote:

 On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
 So if you want to improve the language and its ecosystem, the 
 best way is to contribute pull requests or $$$s - the 
 Foundation now accepts individual donations, and it's also open 
 to corporate sponsorship, I believe.


 Editor support:


 Sublime text and sometimes vim work well enough for me, though 
 these things are very personal.  For the others, have you 
 contributed anything - time or money in making them better?  If 
 wishes were horses, beggars would ride.  And contribution of 
 either has a higher value than just the thing itself, because 
 it also tends to energise the project - look at the frustration 
 Basil experienced regarding his IDE project.  It's good to have 
 high standards, but one should have some appreciation also for 
 the gift that people make of their time, work, and energy in 
 ways that don't always lead to the gratitude that one might 
 expect.


There's only so much time and money someone can give. It isn't 
that appealing when virtually no other language out there suffers 
from this problem cause they have an actual market behind them. 
Those markets fuel money being poured into the tools of the 
lanugage. It doesn't really matter how many users you have, it 
depends on the demographic of those users. If they are all 
students still in school, then you haven't really created a 
market.

Anyways most of the IDEs out there are made by a small team or 
only one person. Not only that but they almost all (if not all) 
rely on the same projects to get the features you would expect in 
an IDE. The DCD, DScanner, DFix, DFmt etc... All those tools also 
seem to be developed primarily by the same single person. Rust 
seems to be in a similar situation but at least it seems the rust 
team has plans for adding IDE support into the compiler itself. 
Something that is probably unrealistic for D.


 Seb posted a massive list of modules that can be standard 
 candidates. And the response is more or less ignore it. People 
 who work on Standard libraries are more motivated. Bring  them 
 into the fold. But it seems that they simple get ignored.


 Rome wasn't built in a year.  Great things are achieved by 
 taking baby steps, compounded over time.  And if one does what 
 little one can, others are inspired by it.  Enthusiasm and a 
 constructive attitude are infectious in my experience.


D isn't a year old though. If the steps you take are too small, 
you can also end up being left behind.



 Dec 27 2016



 next sibling parent reply Chris Wright <dhasenan gmail.com>  writes:


On Wed, 28 Dec 2016 03:21:03 +0000, Jerry wrote:

 There's only so much time and money someone can give. It isn't that
 appealing when virtually no other language out there suffers from this
 problem cause they have an actual market behind them.


Most languages have this problem. Most languages you actually hear about 
don't, because the marketing follows the money, and you hearing about a 
language follows the marketing.

D is unusual in how complete it's become without significant corporate 
backing, and how popular it is despite lacking a killer application.



 Dec 27 2016



  parent  Laeeth Isharc <laeethnospam nospam.laeeth.com>  writes:


On Wednesday, 28 December 2016 at 06:48:09 UTC, Chris Wright 
wrote:

 On Wed, 28 Dec 2016 03:21:03 +0000, Jerry wrote:

 There's only so much time and money someone can give. It isn't 
 that appealing when virtually no other language out there 
 suffers from this problem cause they have an actual market 
 behind them.


 Most languages have this problem. Most languages you actually 
 hear about don't, because the marketing follows the money, and 
 you hearing about a language follows the marketing.

 D is unusual in how complete it's become without significant 
 corporate backing, and how popular it is despite lacking a 
 killer application.


Reminds me of markets.  A stock that has obvious disadvantages 
people will not stop talking about that keeps making new highs - 
that's not a stock you want to be short.



 Dec 28 2016



prev sibling next sibling parent reply Satoshi <satoshi rikarin.org>  writes:


On Wednesday, 28 December 2016 at 03:21:03 UTC, Jerry wrote:

 On Tuesday, 27 December 2016 at 16:36:10 UTC, Laeeth Isharc 
 wrote:

 On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
 So if you want to improve the language and its ecosystem, the 
 best way is to contribute pull requests or $$$s - the 
 Foundation now accepts individual donations, and it's also 
 open to corporate sponsorship, I believe.


 Editor support:


 Sublime text and sometimes vim work well enough for me, though 
 these things are very personal.  For the others, have you 
 contributed anything - time or money in making them better?  
 If wishes were horses, beggars would ride.  And contribution 
 of either has a higher value than just the thing itself, 
 because it also tends to energise the project - look at the 
 frustration Basil experienced regarding his IDE project.  It's 
 good to have high standards, but one should have some 
 appreciation also for the gift that people make of their time, 
 work, and energy in ways that don't always lead to the 
 gratitude that one might expect.


 There's only so much time and money someone can give. It isn't 
 that appealing when virtually no other language out there 
 suffers from this problem cause they have an actual market 
 behind them. Those markets fuel money being poured into the 
 tools of the lanugage. It doesn't really matter how many users 
 you have, it depends on the demographic of those users. If they 
 are all students still in school, then you haven't really 
 created a market.

 Anyways most of the IDEs out there are made by a small team or 
 only one person. Not only that but they almost all (if not all) 
 rely on the same projects to get the features you would expect 
 in an IDE. The DCD, DScanner, DFix, DFmt etc... All those tools 
 also seem to be developed primarily by the same single person. 
 Rust seems to be in a similar situation but at least it seems 
 the rust team has plans for adding IDE support into the 
 compiler itself. Something that is probably unrealistic for D.


 Seb posted a massive list of modules that can be standard 
 candidates. And the response is more or less ignore it. 
 People who work on Standard libraries are more motivated. 
 Bring  them into the fold. But it seems that they simple get 
 ignored.


 Rome wasn't built in a year.  Great things are achieved by 
 taking baby steps, compounded over time.  And if one does what 
 little one can, others are inspired by it.  Enthusiasm and a 
 constructive attitude are infectious in my experience.


 D isn't a year old though. If the steps you take are too small, 
 you can also end up being left behind.



I'm working on a commercial IDE and GUI framework for a year and 
half and I'm not able to release any version due to this bug[1].
But nobody cares about fixing it because it doesn't give any 
benefits in opensource way to D or what.

I don't know how there can be any others closed source/commercial 
libraries for D when the one of the key features won't work.

Actually I wasted one and half year of developing project that I 
cannot release due to the bug. When I started I didn't even know 
that future existence of my project can depend on the compiler 
itself. Please, stop adding new features to D and start fixing 
existing ones.

- Satoshi

---
[1] https://issues.dlang.org/show_bug.cgi?id=16590



 Dec 28 2016



 next sibling parent reply Jerry <hurricane hereiam.com>  writes:


On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:

 I'm working on a commercial IDE and GUI framework for a year 
 and half and I'm not able to release any version due to this 
 bug[1].
 But nobody cares about fixing it because it doesn't give any 
 benefits in opensource way to D or what.

 I don't know how there can be any others closed 
 source/commercial libraries for D when the one of the key 
 features won't work.

 Actually I wasted one and half year of developing project that 
 I cannot release due to the bug. When I started I didn't even 
 know that future existence of my project can depend on the 
 compiler itself. Please, stop adding new features to D and 
 start fixing existing ones.

 - Satoshi

 ---
 [1] https://issues.dlang.org/show_bug.cgi?id=16590


Personally I'm not really looking for an IDE, I've settled for a 
text editor with a plugin for it. IDEs tend to be bulky and not 
be very good at manipulating text or rather lacking features to 
do so.

I don't see how the interface generator is stopping you from 
releasing the IDE anyways. All it would really stop is 
potentially third party plugins. Even then you can just write the 
interface files yourself. Wouldn't be that hard, just coping the 
source file and removing function bodies for the most part. What 
you'd need to do if you were writing C++ code, but you would keep 
the header and source files in sync as you were developing.



 Dec 28 2016



  parent reply Satoshi <satoshi rikarin.org>  writes:


On Wednesday, 28 December 2016 at 09:37:06 UTC, Jerry wrote:

 Personally I'm not really looking for an IDE, I've settled for 
 a text editor with a plugin for it. IDEs tend to be bulky and 
 not be very good at manipulating text or rather lacking 
 features to do so.


It depends on specific IDE.


 I don't see how the interface generator is stopping you from 
 releasing the IDE anyways.


It's GUI framework (set of libraries) what I cannot release. IDE 
is without the libs quite useless.


All it would really stop is
 potentially third party plugins. Even then you can just write 
 the interface files yourself. Wouldn't be that hard, just 
 coping the source file and removing function bodies for the 
 most part. What you'd need to do if you were writing C++ code, 
 but you would keep the header and source files in sync as you 
 were developing.


Wouldn't be that hard but the project have 200k lines of code. 
Making header files manually is a wast of time what i don't have.

But the point is that D compiler specification[1] looks like this 
part works without a problem and is usable but it's a lie and 
nobody cares about it. Actually it will not ruin my project but 
complicates it. And this is not the way in which should business 
be made. 10 years of development and still some key features 
won't work properly.

[1] https://dlang.org/dmd-osx.html#interface-files



 Dec 28 2016



 next sibling parent reply YAHB <yahb yetanotherhumanbeing.hu>  writes:


On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:

 Making header files manually is a wast of time what i don't 
 have.


Write your own header generator. Personally I don't get the point 
of writing an IDE if at a time or another you don't start working 
a bit around you know...D syntax, D grammar. Instead you seem to 
get stuck on first issue related to the language.

But what's the real issue ? You want to release a pre-compiled 
static library with headers ? Then you could license the sources, 
simply. Personally I've been client of a commercial GUI 
framework, and we get the sources with the license. It worked, I 
mean that the developer had clients.



 Dec 28 2016



  parent reply Satoshi <satoshi rikarin.org>  writes:


On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:

 On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
 On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:

 Making header files manually is a wast of time what i don't 
 have.


 Write your own header generator.


Yes, why not to write my own language.


 Personally I don't get the point of writing an IDE if at a time 
 or another you don't start working a bit around you know...D 
 syntax, D grammar.


Actually, I written an OS in D.


 Instead you seem to get stuck on first issue related to the 
 language.


First issue? Developers of LDC can respond and fix issue in a 
real time but developers of D frontend not. And that's the thing 
what pissed me off.


 But what's the real issue ? You want to release a pre-compiled 
 static library with headers ?


Yes.


 Then you could license the sources, simply.


No, thanks.


 Personally I've been client of a commercial GUI framework, and 
 we get the sources with the license. It worked, I mean that the 
 developer had clients.





 Dec 28 2016



 next sibling parent reply YAHB <yahb yetanotherhumanbeing.hu>  writes:


On Wednesday, 28 December 2016 at 11:36:33 UTC, Satoshi wrote:

 On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:

 On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
 On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:

 Making header files manually is a wast of time what i don't 
 have.


 Write your own header generator.


 Yes, why not to write my own language.


Pfff...too hard to use an AST visitor. And that wants to release 
a commercial IDE.


 Personally I don't get the point of writing an IDE if at a 
 time or another you don't start working a bit around you 
 know...D syntax, D grammar.


 Actually, I written an OS in D.


True...an Outrageous Scam...


 Instead you seem to get stuck on first issue related to the 
 language.


 First issue? Developers of LDC can respond and fix issue in a 
 real time but developers of D frontend not. And that's the 
 thing what pissed me off.


 But what's the real issue ? You want to release a pre-compiled 
 static library with headers ?


 Yes.


 Then you could license the sources, simply.


 No, thanks.


Just think to your strategy and try to be wise. Even Qt sources 
are available. There's at least 10 ways to waste a freelance 
commercial project.


 Personally I've been client of a commercial GUI framework, and 
 we get the sources with the license. It worked, I mean that 
 the developer had clients.







 Dec 28 2016



  parent reply Satoshi <satoshi rikarin.org>  writes:


On Wednesday, 28 December 2016 at 12:03:53 UTC, YAHB wrote:

 Making header files manually is a wast of time what i don't 
 have.


 Write your own header generator.


 Yes, why not to write my own language.


 Pfff...too hard to use an AST visitor. And that wants to 
 release a commercial IDE.


Compiler design is not my business.


 Personally I don't get the point of writing an IDE if at a 
 time or another you don't start working a bit around you 
 know...D syntax, D grammar.


 Actually, I written an OS in D.


 True...an Outrageous Scam...


So funny...
https://github.com/Rikarin/Trinix


 Instead you seem to get stuck on first issue related to the 
 language.


 First issue? Developers of LDC can respond and fix issue in a 
 real time but developers of D frontend not. And that's the 
 thing what pissed me off.


 But what's the real issue ? You want to release a 
 pre-compiled static library with headers ?


 Yes.


 Then you could license the sources, simply.


 No, thanks.


 Just think to your strategy and try to be wise. Even Qt sources 
 are available. There's at least 10 ways to waste a freelance 
 commercial project.


Qt is out of dated crap mostly useless for fast GUI development. 
Anyway, it's my project and I don't want to release source codes. 
No, it's not a freelance project, I got some money for dev and I 
already have clients waiting for stable release. There will be 
info soon.


 Personally I've been client of a commercial GUI framework, 
 and we get the sources with the license. It worked, I mean 
 that the developer had clients.






I don't need to follow same rules as others do.



 Dec 28 2016



  parent reply bauss <jj_1337 live.dk>  writes:


On Wednesday, 28 December 2016 at 12:33:58 UTC, Satoshi wrote:

 On Wednesday, 28 December 2016 at 12:03:53 UTC, YAHB wrote:

 Just think to your strategy and try to be wise. Even Qt 
 sources are available. There's at least 10 ways to waste a 
 freelance commercial project.


 Qt is out of dated crap mostly useless for fast GUI 
 development. Anyway, it's my project and I don't want to 
 release source codes. No, it's not a freelance project, I got 
 some money for dev and I already have clients waiting for 
 stable release. There will be info soon.


I know this is kinda late to the game

If you want to do GUI development and don't want to use any of 
the existing things because they're outdated or anything you 
could always help contribute to my project if you want. Although 
it's nowhere near stable and not close to anything being usable, 
I'd appreciate anyone willing to help. I'm currently put up with 
tons of other work that are way more important, so haven't been 
able to do anything on it myself. If you're going to help or for 
the matter if anyone is then please don't modify the graphics and 
picture modules, as I plan on rewriting them as they were kinda 
just winged together through the development and they definitely 
need a stronger core to them. Overall it works though.

It can be found here: http://poisonengine.github.io/



 Dec 29 2016



 next sibling parent  bauss <jj_1337 live.dk>  writes:


On Thursday, 29 December 2016 at 19:54:43 UTC, bauss wrote:

 It can be found here: http://poisonengine.github.io/


I apologize I meant here: 
https://poisonengine.github.io/poison-ui/



 Dec 29 2016



prev sibling next sibling parent  Arun Chandrasekaran <aruncxy gmail.com>  writes:


On Thursday, 29 December 2016 at 19:54:43 UTC, bauss wrote:

 It can be found here: http://poisonengine.github.io/


404, here is a working link -- 
https://github.com/PoisonEngine/poison-ui



 Dec 29 2016



prev sibling  parent reply aberba <karabutaworld gmail.com>  writes:


On Thursday, 29 December 2016 at 19:54:43 UTC, bauss wrote:

 On Wednesday, 28 December 2016 at 12:33:58 UTC, Satoshi wrote:

[...]


 I know this is kinda late to the game

 If you want to do GUI development and don't want to use any of 
 the existing things because they're outdated or anything you 
 could always help contribute to my project if you want. 
 Although it's nowhere near stable and not close to anything 
 being usable, I'd appreciate anyone willing to help. I'm 
 currently put up with tons of other work that are way more 
 important, so haven't been able to do anything on it myself. If 
 you're going to help or for the matter if anyone is then please 
 don't modify the graphics and picture modules, as I plan on 
 rewriting them as they were kinda just winged together through 
 the development and they definitely need a stronger core to 
 them. Overall it works though.

 It can be found here: http://poisonengine.github.io/


Styling is similar to CSS but different. Wished someone would 
just go for a full blown CSS parser. CSS has proven its more 
capable and loved for client side styling/decoration.



 Dec 29 2016



 next sibling parent  bauss <jj_1337 live.dk>  writes:


On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:

 On Thursday, 29 December 2016 at 19:54:43 UTC, bauss wrote:

 [...]


 Styling is similar to CSS but different. Wished someone would 
 just go for a full blown CSS parser. CSS has proven its more 
 capable and loved for client side styling/decoration.


I would love to implement that and actually looked at 
implementing a sass like syntax, but decided it wasn't the 
importance right now, so maybe at a later point.



 Dec 29 2016



prev sibling next sibling parent reply Chris Wright <dhasenan gmail.com>  writes:


On Thu, 29 Dec 2016 21:41:45 +0000, aberba wrote:

 Styling is similar to CSS but different. Wished someone would just go
 for a full blown CSS parser. CSS has proven its more capable and loved
 for client side styling/decoration.


CSS is huge. It also brings in some assumptions about the layout model.

Supporting a subset of CSS would be reasonable.



 Dec 29 2016



  parent reply bauss <jj_1337 live.dk>  writes:


On Thursday, 29 December 2016 at 22:53:51 UTC, Chris Wright wrote:

 On Thu, 29 Dec 2016 21:41:45 +0000, aberba wrote:

 Styling is similar to CSS but different. Wished someone would 
 just go for a full blown CSS parser. CSS has proven its more 
 capable and loved for client side styling/decoration.


 CSS is huge. It also brings in some assumptions about the 
 layout model.

 Supporting a subset of CSS would be reasonable.


This, besides there are things in CSS that only makes sense for 
it and not necessary for this. Like the way it certain styles are 
depending on each other, the dependencies may act differently by 
CSS, than it would by my library, because I do not render things 
with the same mindset or goal as CSS. One thing that especially 
is hard is the selector scheme as it's not based on styling a 
marked up language nor any kind of language structure at all. So 
the same kind of hierarchy doesn't exist with selectors like a 
div with a div isn't a thing, it's just a container that has a 
child component that's a container, but since this targets native 
GUI development then I don't want styling to match such 
inheritance and each component should be decoupled from each 
other. I believe it's much smoother and easier to manage your 
design. The only things that won't be decoupled from components 
and their children and surroundings would be things like 
positions, margins, paddings etc. all which doesn't affect the 
design.



 Dec 29 2016



  parent reply aberba <karabutaworld gmail.com>  writes:


On Friday, 30 December 2016 at 06:22:40 UTC, bauss wrote:

 [...]


Yeah. I meant a subset. But widgets will not follow the DOM query 
syntax, it should use class attributes.

.button {
   border-color: red;
}

.container {
   ...
}

auto btn = new Button();
btn.addClass("button");
btn.addStyleFromFile("style.css");

...
container = new ...
container.addStyleFromSource(".container {…}");



 Dec 30 2016



  parent reply Bauss <jj_1337 live.dk>  writes:


On Friday, 30 December 2016 at 11:32:50 UTC, aberba wrote:

 On Friday, 30 December 2016 at 06:22:40 UTC, bauss wrote:

 [...]


 Yeah. I meant a subset. But widgets will not follow the DOM 
 query syntax, it should use class attributes.

 .button {
   border-color: red;
 }

 .container {
   ...
 }

 auto btn = new Button();
 btn.addClass("button");
 btn.addStyleFromFile("style.css");

 ...
 container = new ...
 container.addStyleFromSource(".container {…}");


Yeah it kinda follows classes right now already.

It follows a little different concept, where it's based on 
selectors and not classes.

So you give your component selectors that it acts on. There are 
of course default selectors on them such as their component type, 
name, states etc.

See:
https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L297

And:
https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L376



 Dec 30 2016



  parent  Bauss <jj_1337 live.dk>  writes:


On Friday, 30 December 2016 at 13:26:15 UTC, Bauss wrote:

 On Friday, 30 December 2016 at 11:32:50 UTC, aberba wrote:

 [...]


 Yeah it kinda follows classes right now already.

 It follows a little different concept, where it's based on 
 selectors and not classes.

 So you give your component selectors that it acts on. There are 
 of course default selectors on them such as their component 
 type, name, states etc.

 See:
 https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L297

 And:
 https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L376


And of course: 
https://github.com/PoisonEngine/poison-ui/blob/master/README.md#styling



 Dec 30 2016



prev sibling  parent reply Getald <gerald.b.nunn gmail.com>  writes:


On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:


 Styling is similar to CSS but different. Wished someone would 
 just go for a full blown CSS parser. CSS has proven its more 
 capable and loved for client side styling/decoration.


Isn't this what GTK is essentially doing already where widget 
rendering is primarily defined by CSS.



 Dec 30 2016



 next sibling parent  Bauss <jj_1337 live.dk>  writes:


On Friday, 30 December 2016 at 13:56:30 UTC, Getald wrote:

 On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:


 Styling is similar to CSS but different. Wished someone would 
 just go for a full blown CSS parser. CSS has proven its more 
 capable and loved for client side styling/decoration.


 Isn't this what GTK is essentially doing already where widget 
 rendering is primarily defined by CSS.


Yep it is



 Dec 30 2016



prev sibling  parent reply jkpl <jkpl bower2000.de>  writes:


On Friday, 30 December 2016 at 13:56:30 UTC, Getald wrote:

 On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:


 Styling is similar to CSS but different. Wished someone would 
 just go for a full blown CSS parser. CSS has proven its more 
 capable and loved for client side styling/decoration.


 Isn't this what GTK is essentially doing already where widget 
 rendering is primarily defined by CSS.


Yes but it's gtk, there's year of work behind the library. For a 
homemade GUI library CSS or not CSS is really just bikeshedding 
around the format. The real stuff is to write the rendering 
engine. It becomes particularly tricky when the engine also 
supports transformations. If something is not well done you see 
it directly after rotation and translation.



 Dec 31 2016



  parent  keito940 <keito940 live.jp>  writes:


On Saturday, 31 December 2016 at 08:14:28 UTC, jkpl wrote:

 Yes but it's gtk, there's year of work behind the library. For 
 a homemade GUI library CSS or not CSS is really just 
 bikeshedding around the format. The real stuff is to write the 
 rendering engine. It becomes particularly tricky when the 
 engine also supports transformations. If something is not well 
 done you see it directly after rotation and translation.


rendering engine...hmmm...



 Jan 02 2017



prev sibling next sibling parent reply YAHB <yahb yetanotherhumanbeing.hu>  writes:


On Wednesday, 28 December 2016 at 11:36:33 UTC, Satoshi wrote:

 On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:

 On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
 On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:
 But what's the real issue ? You want to release a pre-compiled 
 static library with headers ?


 Yes.


you'll be in front of another issue then: "dmd_personality"... 
unless you release the static library for DMD, LDC, GDC, + each 
version for each, basically debug + release...so already 6 ;]



 Dec 28 2016



  parent reply Satoshi <satoshi rikarin.org>  writes:


On Wednesday, 28 December 2016 at 12:14:02 UTC, YAHB wrote:

 But what's the real issue ? You want to release a 
 pre-compiled static library with headers ?


 Yes.


 you'll be in front of another issue then: "dmd_personality"... 
 unless you release the static library for DMD, LDC, GDC, + each 
 version for each, basically debug + release...so already 6 ;]


Nope :)
Rikarin Studio is a package of precompiled druntime, phobos, 
Rikarin Framework (Async core, GUI AppKit, basic bindings...) 
bundled with LDC and own build tool distributed as a toolkit. 
User will not be able to choose between compilers :)

This is what people need, not 800 variants of every tool where at 
least one cannot work properly.



 Dec 28 2016



  parent reply YAHB <yahb yetanotherhumanbeing.hu>  writes:


On Wednesday, 28 December 2016 at 12:44:38 UTC, Satoshi wrote:

 On Wednesday, 28 December 2016 at 12:14:02 UTC, YAHB wrote:

 But what's the real issue ? You want to release a 
 pre-compiled static library with headers ?


 Yes.


 you'll be in front of another issue then: "dmd_personality"... 
 unless you release the static library for DMD, LDC, GDC, + 
 each version for each, basically debug + release...so already 
 6 ;]


 Nope :)
 Rikarin Studio is a package of precompiled druntime, phobos, 
 Rikarin Framework (Async core, GUI AppKit, basic bindings...) 
 bundled with LDC and own build tool distributed as a toolkit. 
 User will not be able to choose between compilers :)

 This is what people need, not 800 variants of every tool where 
 at least one cannot work properly.


Sorry, to be honest I didn't take you seriously. Your bug report, 
so the starter of this off topic fork, is barely understandable: 
impossible to understand if it was a language issue, an issue of 
the header function generator...

You can open a bounty for this.



 Dec 28 2016



  parent  Satoshi <satoshi rikarin.org>  writes:


On Wednesday, 28 December 2016 at 12:55:17 UTC, YAHB wrote:

 Sorry, to be honest I didn't take you seriously. Your bug 
 report, so the starter of this off topic fork, is barely 
 understandable: impossible to understand if it was a language 
 issue, an issue of the header function generator...


Sorry, I didn't want to start OT I just want to point on some 
aspects of D from my view.
My english is bad so I'm not able to express things as 
professionally as in my native language. But I think people here 
are enough intelligent to take me seriously regardless on how I 
write. Sorry...



 Dec 28 2016



prev sibling  parent reply Chris Wright <dhasenan gmail.com>  writes:


On Wed, 28 Dec 2016 11:36:33 +0000, Satoshi wrote:


 On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:

 On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On
 Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:

 Making header files manually is a wast of time what i don't have.


 Write your own header generator.


 Yes, why not to write my own language.


It should be significantly easier with dmd's json output.



 Dec 28 2016



  parent  Chris Wright <dhasenan gmail.com>  writes:


On Wed, 28 Dec 2016 16:09:28 +0000, Chris Wright wrote:


 On Wed, 28 Dec 2016 11:36:33 +0000, Satoshi wrote:
 

 On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote:

 On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On
 Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:

 Making header files manually is a wast of time what i don't have.


 Write your own header generator.


 Yes, why not to write my own language.


 
 It should be significantly easier with dmd's json output.


My apologies; dmd's json output suffers the same problem.



 Dec 28 2016



prev sibling  parent reply Jerry <hurricane hereiam.com>  writes:


On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote:

 On Wednesday, 28 December 2016 at 09:37:06 UTC, Jerry wrote:

 Personally I'm not really looking for an IDE, I've settled for 
 a text editor with a plugin for it. IDEs tend to be bulky and 
 not be very good at manipulating text or rather lacking 
 features to do so.


 It depends on specific IDE.


 I don't see how the interface generator is stopping you from 
 releasing the IDE anyways.


 It's GUI framework (set of libraries) what I cannot release. 
 IDE is without the libs quite useless.


You don't need the source of the GUI framework to use a compiled 
program. If you are developing both the GUI and the IDE, then you 
don't need interface files. You can just use the D source code. 
Once you compile the IDE no one will have access to the interface 
files anyways, unless (like i mentioned above) for third party 
plugin developers.


 Wouldn't be that hard but the project have 200k lines of code. 
 Making header files manually is a wast of time what i don't 
 have.


That's including all the actual code bodies, you could probably 
write a regex to detect and select them. It wouldn't take as long 
as you think when you start erasing hundreds of lines of code 
with a single backspace. Anyways point is, it isn't really a 
showstopper. You could still have released your IDE without 
interface files to be used as an IDE and you could have made the 
interface files yourself if you really wanted to release the GUI.


 But the point is that D compiler specification[1] looks like 
 this part works without a problem and is usable but it's a lie 
 and nobody cares about it. Actually it will not ruin my project 
 but complicates it. And this is not the way in which should 
 business be made. 10 years of development and still some key 
 features won't work properly.

 [1] https://dlang.org/dmd-osx.html#interface-files


It's a feature that probably a few people actually use, odds are 
they forget about it when adding new features and potentially 
there are no tests for it either.



 Dec 28 2016



  parent reply Satoshi <satoshi rikarin.org>  writes:


On Wednesday, 28 December 2016 at 19:51:38 UTC, Jerry wrote:

 You don't need the source of the GUI framework to use a 
 compiled program. If you are developing both the GUI and the 
 IDE, then you don't need interface files. You can just use the 
 D source code. Once you compile the IDE no one will have access 
 to the interface files anyways, unless (like i mentioned above) 
 for third party plugin developers.


No, GUI framework is one part of project like Qt, GTK or WPF and 
IDE is an another part.


 That's including all the actual code bodies, you could probably 
 write a regex to detect and select them. It wouldn't take as 
 long as you think when you start erasing hundreds of lines of 
 code with a single backspace. Anyways point is, it isn't really 
 a showstopper. You could still have released your IDE without 
 interface files to be used as an IDE and you could have made 
 the interface files yourself if you really wanted to release 
 the GUI.


It's not so simple. I actually must know which functions can be 
called by CTFE and which not. auto functions should have stripped 
body with replaced auto for a specific type, etc.

Main part of the project is GUI framework not IDE itself. IDE is 
made just for simplify GUI development by D'n'D Interface 
Builder. Like in VS or XCode or Qt Creator.

Actually I want to release pre-alpha version of GUI framework 
just for a few people to show them progress, let them test it and 
get some feedback.

I can generate header files and then fix it manually but first I 
need a full coverage tests to recognize where bugs are. But 
still, patching header files every time when I change something 
is not real.



 Dec 28 2016



  parent  Chris Wright <dhasenan gmail.com>  writes:


On Wed, 28 Dec 2016 22:10:22 +0000, Satoshi wrote:

 It's not so simple. I actually must know which functions can be called
 by CTFE and which not. auto functions should have stripped body with
 replaced auto for a specific type, etc.


Currently, D header files don't support either of those features. You 
probably need a custom header generator, one that pays attention to UDAs 
(assuming you want to annotate functions according to whether they can be 
called at compile time; otherwise, there's a fair bit more work).

Unfortunately, DMD's json output doesn't even write UDAs, so you can't 
use that to write your own header generator.



 Dec 28 2016



prev sibling next sibling parent reply bachmeier <no spam.net>  writes:


On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:

 I'm working on a commercial IDE and GUI framework for a year 
 and half and I'm not able to release any version due to this 
 bug[1].


...


 Please, stop adding new features to D and start fixing existing 
 ones.

 - Satoshi

 ---
 [1] https://issues.dlang.org/show_bug.cgi?id=16590


You've got things reversed. The point of a company like Google or 
Sun backing a language is that things get done, like this bug 
fix, so that the language can be used for whatever that company 
needs it to do.

You claim you want to make money off the language, yet you are 
demanding that volunteers immediately fix a bug that is holding 
you back. That's an odd business model. You have three options: 
pay to fix it yourself, use a different language that allows you 
to benefit from work paid for by more profitable companies like 
Google, or wait for volunteers to do it on their schedule.

This is not unique to D. I'm reminded of Visual Studio not 
supporting C99 or Firefox not supporting certain HTML 5 features.



 Dec 28 2016



 next sibling parent  YAHB <yahb yetanotherhumanbeing.hu>  writes:


On Wednesday, 28 December 2016 at 12:43:03 UTC, bachmeier wrote:

 On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:

 I'm working on a commercial IDE and GUI framework for a year 
 and half and I'm not able to release any version due to this 
 bug[1].


 ...


 Please, stop adding new features to D and start fixing 
 existing ones.

 - Satoshi

 ---
 [1] https://issues.dlang.org/show_bug.cgi?id=16590


 You've got things reversed. The point of a company like Google 
 or Sun backing a language is that things get done, like this 
 bug fix, so that the language can be used for whatever that 
 company needs it to do.

 You claim you want to make money off the language, yet you are 
 demanding that volunteers immediately fix a bug that is holding 
 you back. That's an odd business model. You have three options: 
 pay to fix it yourself, use a different language that allows 
 you to benefit from work paid for by more profitable companies 
 like Google, or wait for volunteers to do it on their schedule.

 This is not unique to D. I'm reminded of Visual Studio not 
 supporting C99 or Firefox not supporting certain HTML 5 
 features.


That was what I thought to propose to him: he could found a 
bounty. Bounties are for a product but the founder doesn't have 
to be in the company or, like here, in the organization.



 Dec 28 2016



prev sibling  parent reply Satoshi <satoshi rikarin.org>  writes:


On Wednesday, 28 December 2016 at 12:43:03 UTC, bachmeier wrote:

 On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:

 I'm working on a commercial IDE and GUI framework for a year 
 and half and I'm not able to release any version due to this 
 bug[1].


 ...


 Please, stop adding new features to D and start fixing 
 existing ones.

 - Satoshi

 ---
 [1] https://issues.dlang.org/show_bug.cgi?id=16590


 You've got things reversed. The point of a company like Google 
 or Sun backing a language is that things get done, like this 
 bug fix, so that the language can be used for whatever that 
 company needs it to do.

 You claim you want to make money off the language, yet you are 
 demanding that volunteers immediately fix a bug that is holding 
 you back. That's an odd business model. You have three options: 
 pay to fix it yourself, use a different language that allows 
 you to benefit from work paid for by more profitable companies 
 like Google, or wait for volunteers to do it on their schedule.

 This is not unique to D. I'm reminded of Visual Studio not 
 supporting C99 or Firefox not supporting certain HTML 5 
 features.


I know that :/  I'm just responding to people who wants shift D 
to commercial companies but are doing different steps than they 
should do.

Yes, it's true that I want to make money off the language so I 
should paid for that fix but in other way you want to promote D 
to others and this is the thing what's holding me back to do the 
same. And the bug will be fixed anyway, so.



 Dec 28 2016



  parent reply rikki cattermole <rikki cattermole.co.nz>  writes:


On 29/12/2016 2:08 AM, Satoshi wrote:

 On Wednesday, 28 December 2016 at 12:43:03 UTC, bachmeier wrote:

 On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote:

 I'm working on a commercial IDE and GUI framework for a year and half
 and I'm not able to release any version due to this bug[1].


 ...


 Please, stop adding new features to D and start fixing existing ones.

 - Satoshi

 ---
 [1] https://issues.dlang.org/show_bug.cgi?id=16590


 You've got things reversed. The point of a company like Google or Sun
 backing a language is that things get done, like this bug fix, so that
 the language can be used for whatever that company needs it to do.

 You claim you want to make money off the language, yet you are
 demanding that volunteers immediately fix a bug that is holding you
 back. That's an odd business model. You have three options: pay to fix
 it yourself, use a different language that allows you to benefit from
 work paid for by more profitable companies like Google, or wait for
 volunteers to do it on their schedule.

 This is not unique to D. I'm reminded of Visual Studio not supporting
 C99 or Firefox not supporting certain HTML 5 features.


 I know that :/  I'm just responding to people who wants shift D to
 commercial companies but are doing different steps than they should do.

 Yes, it's true that I want to make money off the language so I should
 paid for that fix but in other way you want to promote D to others and
 this is the thing what's holding me back to do the same. And the bug
 will be fixed anyway, so.


If you don't hear about any fixes coming from a core dev in the next day 
or so, contact Walter directly.



 Dec 28 2016



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/28/16 8:17 AM, rikki cattermole wrote:

 If you don't hear about any fixes coming from a core dev in the next day
 or so, contact Walter directly.


Yes please. Myself too. -- Andrei



 Dec 28 2016



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/28/16 3:35 AM, Satoshi wrote:

 I'm working on a commercial IDE and GUI framework for a year and half
 and I'm not able to release any version due to this bug[1].


I'll ask the student in charge with the bug to give it priority. -- Andrei



 Dec 28 2016



prev sibling  parent  Laeeth Isharc <laeethnospam nospam.laeeth.com>  writes:


On Wednesday, 28 December 2016 at 03:21:03 UTC, Jerry wrote:

 On Tuesday, 27 December 2016 at 16:36:10 UTC, Laeeth Isharc 
 wrote:

 On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
 So if you want to improve the language and its ecosystem, the 
 best way is to contribute pull requests or $$$s - the 
 Foundation now accepts individual donations, and it's also 
 open to corporate sponsorship, I believe.


 Editor support:


 Sublime text and sometimes vim work well enough for me, though 
 these things are very personal.  For the others, have you 
 contributed anything - time or money in making them better?  
 If wishes were horses, beggars would ride.  And contribution 
 of either has a higher value than just the thing itself, 
 because it also tends to energise the project - look at the 
 frustration Basil experienced regarding his IDE project.  It's 
 good to have high standards, but one should have some 
 appreciation also for the gift that people make of their time, 
 work, and energy in ways that don't always lead to the 
 gratitude that one might expect.


 There's only so much time and money someone can give.


True.  I really have very little time myself, but I was more 
annoyed by seeing the docs wrong and took the twenty minutes or 
so it took to fix them (slow, because I wasn't used to the 
process).  My point is it's a continuum - not a question either 
of donating $500k and all of one's time or zero.


 It isn't that appealing when virtually no other language out 
 there suffers from this problem cause they have an actual 
 market behind them.


One picks one's poison and lives with the consequences.  D's 
advantage isn't shiny marketing, documentation, and polish.  Yet 
its user base seems to be growing and people are building their 
businesses around it.  I wonder why that is.

In my experience it doesn't do much good to complain about a 
problem that is well understood unless one is going to do 
something about it too.  And if one isn't contributing code, 
energy or resources in some other way that will at least make a 
dent in the problem, one shouldn't be so surprised if one's own 
preferences don't perfectly coincide with the preferences of 
those who are.


 Those markets fuel money being poured into the tools of the 
 lanugage. It doesn't really matter how many users you have, it 
 depends on the demographic of those users. If they are all 
 students still in school, then you haven't really created a 
 market.


People are using D to do real work, and there's more money 
supporting D than ever before.  It might not yet be gazillions, 
but give it time.


 Rome wasn't built in a year.  Great things are achieved by 
 taking baby steps, compounded over time.  And if one does what 
 little one can, others are inspired by it.  Enthusiasm and a 
 constructive attitude are infectious in my experience.


 D isn't a year old though. If the steps you take are too small, 
 you can also end up being left behind.


Tis possible, but I would happily bet against your view.



 Dec 28 2016



prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org>  writes:


Jack Stouffer wrote:


And I sincerely hope they work to fix them before adding in a 
bunch of new DIPs which will further complicate matters, 
especially with regard to function signitures.


so far i see that they just like to say: "we won't break user's code", 
and then silently breaking it, even without deprecation stage.

thank you, guys; guessing when "we won't break the code" really means 
something is a fun game.

you want the example? `scope` was added to `_compare_fp_t` 
from "core.stdc.stdlib". thank you for breaking ALL my code that 
is using `qsort()`. i guess nobody from core dev team really used 
`qsort()` from libc, so it is ok to break the code with it.

yeah, this was done in git, not in release. but still.

btw, for a short time compiler was unable to build itself at all,
with all that "scope spam". i.e. nobody really cares about travis, 
or travis cannot properly check commits and is useless (or how else 
patch that did broke travis builds lands in "master"?)

what i really want to say is that spamming code with shiny new stuff is 
done... too fast, and tends to disregard "we won't break users' code" 
mantra. sure, adding new features is fun, i know it, and i like to do 
it too. but please, let's do it consistently! either drop "we won't 
break" and start *really* adding features, or stop adding random 
half-finished things to compiler/druntime/phobos. at least in "master".

p.s.: please, no "don't use git HEAD" blah-blah. it is not about short 
breakages (which is normal with "bleeding edge"). it is all about lack 
of consistency and proper... practices. maybe even proper project 
vision.

p.p.s.: "mostly volunteers", "free", etc. i know. thank you all for 
your hard work. i appreciate it, and that's exactly why i don't want it 
to be spoiled by seemingly small and insignificant things.



 Feb 15 2017



  parent  Jack Stouffer <jack jackstouffer.com>  writes:


On Thursday, 16 February 2017 at 03:46:29 UTC, ketmar wrote:

 you want the example? `scope` was added to `_compare_fp_t`from 
 "core.stdc.stdlib". thank you for breaking ALL my code thatis 
 using `qsort()`. i guess nobody from core dev team really 
 used`qsort()` from libc, so it is ok to break the code with it.


Yes, I'm really disappointed with the way that DIP1000 is turning 
out. It was explicitly stated that nothing would be broken right 
away and that everything would be given a deprecation cycle.

Can you please make a bug with a level of regression for your 
specific problem?



 Feb 15 2017



prev sibling  parent reply ketmar <ketmar ketmar.no-ip.org>  writes:


Jack Stouffer wrote:


Can you please make a bug with a level of regression for your specific 
problem?


yeah.

https://issues.dlang.org/show_bug.cgi?id=17188



 Feb 15 2017



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Something is going on with your newsreader client. It's replies break the
thread.



 Feb 16 2017



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Friday, 17 February 2017 at 00:00:09 UTC, Walter Bright wrote:

 Something is going on with your newsreader client. It's replies 
 break the thread.


I would point out that if there are issues with threading, and 
you don't quote whoever you're responding to, then it may be 
connected to the wrong post - that and some folks don't even use 
threading in their viewer, so without a quote or a name, it's 
hard to know for sure who you're talking to.

- Jonathan M Davis



 Feb 16 2017



prev sibling  parent  ketmar <ketmar ketmar.no-ip.org>  writes:


Walter Bright wrote:


Something is going on with your newsreader client. It's replies break 
the thread.


ooops. created the content, but forgot to actually send it. ;-)



 Feb 16 2017