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