www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Community Rant

reply Jonathan Shamir <jonathan weka.io> writes:
https://dlang.org/htod.html

I click download and get an exe!

And in the bugs section:
No linux version.

I'll start with the productive part. If anyone can point me out 
to the sources of htod I would love to compile for linux + osx. 
Any task seems more attractive to me than manually converting a 
1000 line header to D.

I'm a D lover and advocate. I actually get a salary writing D 
code for a cutting-edge startup.

But lets be honest. If I was just interested to learn about this 
"modern system programming language" that is C++ done right, I 
would dismiss D very quickly. We need to get together as a 
community and rethink your priorities, because with problems like 
this we're making it very hard for newcomers to trust in this 
very poorly adapted language.

Programming tools used by day to day programmers should be a 
priority. Because everyone expects valgrind to work.

The standard library should be a priority. It's far from complete 
(hopefully my company will contribute in this respect in the near 
future).

The DUB package repository is horrible! More often than not, the 
packages are so poorly written I end up just writing my own 
implementation. Adding the ability to "rate" packages would go a 
long way in improving the situation.

I understand hacking the frontend is way more interesting to most 
of the community. But if we don't find the time to improve on our 
visibility and language maturity, D will never get the attention 
it deserves.

P.S. I don't know you guys (except Ali and Andrei which I had the 
honor to meet). I don't follow the forums. I'm sure you often 
speak about these topics here. So - if I offended anyone know 
it's not personal (I don't know who you are). I just want to 
share my impressions and experience as an actual day to day D 
user.
Aug 22 2017
next sibling parent reply ixid <adamsibson gmail.com> writes:
On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote:

 various.


Out of interest did you pick up D before or after joining the 
start up? If before did you introduce D to them or were they 
already using it?
Aug 22 2017
next sibling parent Jonathan Shamir <jonathan weka.io> writes:
On Tuesday, 22 August 2017 at 15:24:54 UTC, ixid wrote:

 On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir 
 wrote:

 various.


 Out of interest did you pick up D before or after joining the 
 start up? If before did you introduce D to them or were they 
 already using it?


I work at weka.io. I learned D at weka, same as most of our 
workers (including the founders that looked for a powerful system 
programming language).
Aug 22 2017
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 08/22/2017 08:24 AM, ixid wrote:

 On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote:

 various.


 Out of interest did you pick up D before or after joining the start up?
 If before did you introduce D to them or were they already using it?


Weka uses D after their CTO Liran's evaluation of a number of 
programming languages. Liran explains why he chose D and why he still 
thinks D was the right choice in his a couple of DConf talks.

I worked at Weka for a while where I met many wonderful people like 
Jonathan. Although they were being "forced" to use D, nobody was 
seriously complaining. :)

Now I work with an ex-Weka employee as an ex-Weka employee myself. That 
other person insisted that he should use D in his piece of the product. 
Sanity exists... ;)

Ali
Aug 23 2017
parent XavierAP <n3minis-git yahoo.es> writes:
On Wednesday, 23 August 2017 at 18:20:19 UTC, Ali Çehreli wrote:

 Weka uses D after their CTO Liran's evaluation of a number of 
 programming languages. Liran explains why he chose D and why he 
 still thinks D was the right choice in his a couple of DConf 
 talks.

 I worked at Weka for a while where I met many wonderful people 
 like Jonathan. Although they were being "forced" to use D, 
 nobody was seriously complaining. :)

 Now I work with an ex-Weka employee as an ex-Weka employee 
 myself. That other person insisted that he should use D in his 
 piece of the product. Sanity exists... ;)


It's great news that such a company with such technology is 
building it on top of D :)

Too bad D doesn't get the free publicity from being in the 
"technology providers" listing :p only big sexy industry names 
there...
Aug 24 2017
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Other possibilities can be dstep or cpp2d from visuald project. 
Though don't know if the latter can work on linux.
Aug 22 2017
parent Jonathan Shamir <jonathan weka.io> writes:
On Tuesday, 22 August 2017 at 15:48:17 UTC, Kagamin wrote:

 Other possibilities can be dstep or cpp2d from visuald project. 
 Though don't know if the latter can work on linux.


So I guess someone should pick one and put it on the site. And 
make sure the source code is available. Having a link to a broken 
unusable utility on the main language website looks bad, to say 
the least.
Aug 22 2017
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, August 22, 2017 15:14:33 Jonathan Shamir via Digitalmars-d 
wrote:

 https://dlang.org/htod.html

 I click download and get an exe!

 And in the bugs section:
 No linux version.

 I'll start with the productive part. If anyone can point me out
 to the sources of htod I would love to compile for linux + osx.
 Any task seems more attractive to me than manually converting a
 1000 line header to D.



From what I recall, it works pretty poorly anyway. As unpleasant as it may


seem, the only way that I'd really consider converting a C header file would
be by hand. If you want an automated solution though, dstep is probably the
better way to go.

http://code.dlang.org/packages/dstep

I'm not sure tha anyone has touched htod in years. dstep certainly will have
issues (as will any automated solution), but I believe that it's better
maintained and would expect it to do a better job.


 The DUB package repository is horrible! More often than not, the
 packages are so poorly written I end up just writing my own
 implementation.


Well, that depends entirely on the individual package maintainers. At least
there's actually a place to go find such projects now. It used to be that
there really wasn't a good place to go find any D libraries, and there
weren't very many around. So, while the situation may not be ideal and could
certainly use some improvement, it has improved considerably in recent
years.


 Adding the ability to "rate" packages would go a
 long way in improving the situation.


It's been brought up before, and I expect that it will happen at some point.
But it's the kind of thing that not many folks want to work on, so it's
likely to suffer. It's probably the sort of thing where it would make sense
for the dlang foundation to pay someone to do that now that they're able to
do that at least occassionally. Someone would probably still have to show
interest in doing the work though.


 I understand hacking the frontend is way more interesting to most
 of the community. But if we don't find the time to improve on our
 visibility and language maturity, D will never get the attention
 it deserves.


Honestly, I think that the library gets more attention than the compiler.
But in general, what gets done is what the person doing the work wants done
regardless of whether that's the best thing to be doing for the community as
a whole, and that's often how it goes with open source projects. Certainly,
if you're looking for large additions to the standard library, that requires
quite a big commitment in terms of time and effort to get it through the
Phobos review process, and it seems that most folks these days simply don't
want to do that. They'd rather just put their code up on code.dlang.org. A
lot of small stuff does get done to Phobos all the time though. And if you
compare what D's standard library has to what C++'s standard library has, D
really doesn't look that bad. It has a lot of stuff that C++ doesn't. But
there are some areas that C++ does better that we need to improve upon (e.g.
containers - though supposedly Andrei and/or is supervising one of his
students on them; they'd made some progress that they talked about at the
last dconf, but whatever they're up to hasn't matured enough to make it into
Phobos yet).

If you're looking to have the amount of stuff that a language like Java or

to be disappointed. There simply isn't enough manpower for that to happen,
and it would likely require folks being paid fulltime to work on a lot of
it, and that certainly isn't happening. Almost all of what gets done for the
compiler and standard libraries is what folks are doing in their free time.

- Jonathan M Davis
Aug 22 2017
prev sibling next sibling parent Guillaume Piolat <contact spam.com> writes:
On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote:

 The DUB package repository is horrible! More often than not, 
 the packages are so poorly written I end up just writing my own 
 implementation. Adding the ability to "rate" packages would go 
 a long way in improving the situation.


+1
There are lots of hidden gems in code.dlang.org and (maybe) some 
metrics to consider to measure relevance: frequency of 
tags/commits, number of contributors, Github stars or forks, 
number of dependent packages, download count per week...
Aug 22 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/22/2017 8:14 AM, Jonathan Shamir wrote:

 https://dlang.org/htod.html
 
 I click download and get an exe!
 
 And in the bugs section:
 No linux version.
 
 I'll start with the productive part. If anyone can point me out to the sources 
 of htod I would love to compile for linux + osx. Any task seems more
attractive 
 to me than manually converting a 1000 line header to D.


You're right about htod, and it's on me. It's built out of the DMC++ front end. 
I haven't gotten around yet to releasing it as open source.

The second problem is the DMC++ front end is tuned to deal with Windows
compiler 
extensions, not Linux compiler extensions. So compiling it and running it on 
Linux will fail because every non-trivial C header file writer is unable to 
resist using every extension.

There's also the gcc problem with its reliance on many hundreds (!) of 
predefined macros that are turned on/off by various gcc compiler switches. It's 
a madhouse. And, of course, every gcc on every platform has a different set of 
these. The situation was so bad that when I developed Warp (a fast C 
preprocessor) I left the predefined list up to the user to load from a special
file.

gcc on Ubuntu has 240 predefined macros when using the default switches. Who 
knows what the full list actually is.

     gcc -dM -E - </dev/null

will print the list.

https://stackoverflow.com/questions/2224334/gcc-dump-preprocessor-defines
Aug 22 2017
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 22 August 2017 at 17:15:27 UTC, Walter Bright wrote:

 On 8/22/2017 8:14 AM, Jonathan Shamir wrote:

 [...]


 You're right about htod, and it's on me. It's built out of the 
 DMC++ front end. I haven't gotten around yet to releasing it as 
 open source.

 [...]


Use Clang frontend?
Aug 22 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-08-22 19:47, 12345swordy wrote:


 Use Clang frontend?


DStep [1] is doing that. It handles both GCC and Microsoft extensions.

[1] https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg
Aug 22 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 22 August 2017 at 19:55:53 UTC, Jacob Carlborg wrote:

 On 2017-08-22 19:47, 12345swordy wrote:


 Use Clang frontend?


 DStep [1] is doing that. It handles both GCC and Microsoft 
 extensions.

 [1] https://github.com/jacob-carlborg/dstep


"Doesn't translate C++ at all"

That's very disappointing. IMO, it should at least aim for the 
c++ 11 feature via using clang.
Aug 23 2017
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 23 August 2017 at 13:25:20 UTC, 12345swordy wrote:

 "Doesn't translate C++ at all"

 That's very disappointing. IMO, it should at least aim for the 
 c++ 11 feature via using clang.


Very disappointing? It's not trivial to call C++ from another 
language.
Aug 23 2017
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 23 August 2017 at 14:12:55 UTC, jmh530 wrote:

 On Wednesday, 23 August 2017 at 13:25:20 UTC, 12345swordy wrote:

 "Doesn't translate C++ at all"

 That's very disappointing. IMO, it should at least aim for the 
 c++ 11 feature via using clang.


 Very disappointing?


Yes I find it disappointing. Does my disappointment bother you?
Aug 23 2017
prev sibling next sibling parent reply lobo <swamplobo gmail.com> writes:
On Wednesday, 23 August 2017 at 13:25:20 UTC, 12345swordy wrote:

 On Tuesday, 22 August 2017 at 19:55:53 UTC, Jacob Carlborg 
 wrote:

 On 2017-08-22 19:47, 12345swordy wrote:


 Use Clang frontend?


 DStep [1] is doing that. It handles both GCC and Microsoft 
 extensions.

 [1] https://github.com/jacob-carlborg/dstep


 "Doesn't translate C++ at all"

 That's very disappointing. IMO, it should at least aim for the 
 c++ 11 feature via using clang.


Do you know another language or tool that can call C++ natively? 
I'm looking for native C++ interop either built in or via tooling.

bye,
lobo
Aug 23 2017
parent reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
 Do you know another language or tool that can call C++ natively?


nim:
it supports both targetting C++ (as well as C or javascript) and also
calling C++ via foreign function interface, eg here are some links:
https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim
https://stackoverflow.com/questions/29526958/wrapping-nested-templated-types-in-nim
https://forum.nim-lang.org/t/1056

for D, there's a project to support full C++ natively using clang
library is calypso, unfortunalty I haven't been able to use it, either
from OSX or ubuntu: it's blocked by
https://github.com/Syniurge/Calypso/issues/41, hoping someone can help
here!



On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 23 August 2017 at 13:25:20 UTC, 12345swordy wrote:

 On Tuesday, 22 August 2017 at 19:55:53 UTC, Jacob Carlborg wrote:

 On 2017-08-22 19:47, 12345swordy wrote:


 Use Clang frontend?



 DStep [1] is doing that. It handles both GCC and Microsoft extensions.

 [1] https://github.com/jacob-carlborg/dstep



 "Doesn't translate C++ at all"

 That's very disappointing. IMO, it should at least aim for the c++ 11
 feature via using clang.



 Do you know another language or tool that can call C++ natively? I'm looking
 for native C++ interop either built in or via tooling.

 bye,
 lobo
Aug 23 2017
parent reply lobo <swamp.lobo gmail.com> writes:
On Thursday, 24 August 2017 at 01:51:25 UTC, Timothee Cour wrote:

 [...]


 nim:
 it supports both targetting C++ (as well as C or javascript) 
 and also
 calling C++ via foreign function interface, eg here are some 
 links:
 https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim
 https://stackoverflow.com/questions/29526958/wrapping-nested-templated-types-in-nim
 https://forum.nim-lang.org/t/1056

 for D, there's a project to support full C++ natively using 
 clang library is calypso, unfortunalty I haven't been able to 
 use it, either from OSX or ubuntu: it's blocked by 
 https://github.com/Syniurge/Calypso/issues/41, hoping someone 
 can help here!



 On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 [...]




Thanks, I'll revisit Nim. As a team we're testing new languages 
as a larger plan to switch from C++. Nim we struck off 6 months 
ago because we found it not quite production ready.

bye,
lobo
Aug 23 2017
parent reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, Aug 23, 2017 at 10:38 PM, lobo via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 24 August 2017 at 01:51:25 UTC, Timothee Cour wrote:

 [...]



 nim:
 it supports both targetting C++ (as well as C or javascript) and also
 calling C++ via foreign function interface, eg here are some links:
 https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim

 https://stackoverflow.com/questions/29526958/wrapping-nested-templated-types-in-nim
 https://forum.nim-lang.org/t/1056

 for D, there's a project to support full C++ natively using clang library
 is calypso, unfortunalty I haven't been able to use it, either from OSX or
 ubuntu: it's blocked by https://github.com/Syniurge/Calypso/issues/41,
 hoping someone can help here!



 On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 [...]





 Thanks, I'll revisit Nim. As a team we're testing new languages as a larger
 plan to switch from C++. Nim we struck off 6 months ago because we found it
 not quite production ready.

 bye,
 lobo


Would love to hear more about your reasoning as I'm also occasionally
re-visiting it, do you have any writeup?
Aug 23 2017
parent reply lobo <swamp.lobo gmail.com> writes:
On Thursday, 24 August 2017 at 05:56:02 UTC, Timothee Cour wrote:

 On Wed, Aug 23, 2017 at 10:38 PM, lobo via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 On Thursday, 24 August 2017 at 01:51:25 UTC, Timothee Cour 
 wrote:

 [...]



 nim:
 it supports both targetting C++ (as well as C or javascript) 
 and also
 calling C++ via foreign function interface, eg here are some 
 links:
 https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim

 https://stackoverflow.com/questions/29526958/wrapping-nested-te
plated-types-in-nim https://forum.nim-lang.org/t/1056

 for D, there's a project to support full C++ natively using 
 clang library is calypso, unfortunalty I haven't been able to 
 use it, either from OSX or ubuntu: it's blocked by 
 https://github.com/Syniurge/Calypso/issues/41, hoping someone 
 can help here!



 On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 [...]





 Thanks, I'll revisit Nim. As a team we're testing new 
 languages as a larger plan to switch from C++. Nim we struck 
 off 6 months ago because we found it not quite production 
 ready.

 bye,
 lobo


 Would love to hear more about your reasoning as I'm also 
 occasionally re-visiting it, do you have any writeup?


No write up I can release at this stage because there are some 
business confidential aspects in the final report. We're ~30 
Python, Java and C++ programmers.

Our testing involved 1 developer month in each language 
implementing scripts to parse into data, a basic library read and 
interpolate data on a 3D regular grid, a small GUI application to 
display regular grids and tool chain testing where we produced a 
metric tonne of autogenerated code to see how well we could 
integrate into our existing build infrastructure and what build 
times would be like.

 From memory Nim had four main issues:

a) 4 compiler ICEs. Our metric was >2 during testing and it was 
out, so this alone blew Nim away; we were deliberately harsh. D 
had 1 ICE that was a known issue with core team member comments 
on the bug report.

b) Nim compilation was slower than other languages (we count the 
C compilation as part of the same package)

c) Our Python devs found Nim was not Pythonic enough compared to 
other languages for hack n' slash quick scripts while keeping it 
maintainable and clean.

d) Our developers (Python, Java and C++ people) preferred other 
language syntax

bye,
lobo
Aug 24 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/24/2017 12:53 AM, lobo wrote:

  D had 1 ICE that was a known
 issue with core team member comments on the bug report.


What's the bugzilla issue number?
Aug 24 2017
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-08-23 15:25, 12345swordy wrote:


 "Doesn't translate C++ at all"
 
 That's very disappointing. IMO, it should at least aim for the c++ 11 
 feature via using clang.


Pull requests are welcome :). BTW, to my knowledge D doesn't support any 
features added after C++98/03.

-- 
/Jacob Carlborg
Aug 24 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 24 August 2017 at 08:11:52 UTC, Jacob Carlborg wrote:

 On 2017-08-23 15:25, 12345swordy wrote:


 "Doesn't translate C++ at all"
 
 That's very disappointing. IMO, it should at least aim for the 
 c++ 11 feature via using clang.


 Pull requests are welcome :). BTW, to my knowledge D doesn't 
 support any features added after C++98/03.


They have plans to add c++ support?
Aug 24 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-08-24 17:02, 12345swordy wrote:


 They have plans to add c++ support?


D can already link with C++, but not all features are supported. Like 
lambdas, for example, are not supported.

-- 
/Jacob Carlborg
Aug 24 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/24/2017 12:08 PM, Jacob Carlborg wrote:

 D can already link with C++, but not all features are supported. Like lambdas, 
 for example, are not supported.


I have no idea how that would even work. Since lambdas are nested functions,
how 
would one write one in D and have it nested inside C++ code?
Aug 24 2017
next sibling parent Biotronic <simen.kjaras gmail.com> writes:
On Friday, 25 August 2017 at 00:43:56 UTC, Walter Bright wrote:

 On 8/24/2017 12:08 PM, Jacob Carlborg wrote:

 D can already link with C++, but not all features are 
 supported. Like lambdas, for example, are not supported.


 I have no idea how that would even work. Since lambdas are 
 nested functions, how would one write one in D and have it 
 nested inside C++ code?


Like this:

// C++

void foo(std::function<char*(int)> fn) {
     printf("%s", fn(3));
}


// D

extern(C++)
void foo(char* delegate(int) fn);

--
   Biotronic
Aug 24 2017
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-08-25 02:43, Walter Bright wrote:


 I have no idea how that would even work. Since lambdas are nested 
 functions, how would one write one in D and have it nested inside C++ code?


I thought C++ lambdas were implemented as structs with the call operator 
overloaded.

-- 
/Jacob Carlborg
Aug 25 2017
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 25 August 2017 at 08:31:57 UTC, Jacob Carlborg wrote:

 On 2017-08-25 02:43, Walter Bright wrote:


 I have no idea how that would even work. Since lambdas are 
 nested functions, how would one write one in D and have it 
 nested inside C++ code?


 I thought C++ lambdas were implemented as structs with the call 
 operator overloaded.


Correct, the lambda syntax is just syntatic sugar. But how would 
D support that? The name of the compiler-generated struct is 
known only to the compiler, there'd be no way to link to the code.

Atila
Aug 25 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-08-25 13:07, Atila Neves wrote:


 Correct, the lambda syntax is just syntatic sugar. But how would D 
 support that? The name of the compiler-generated struct is known only to 
 the compiler, there'd be no way to link to the code.


I don't know. I haven't suggested this should be implemented.

-- 
/Jacob Carlborg
Aug 25 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/25/2017 1:31 AM, Jacob Carlborg wrote:

 On 2017-08-25 02:43, Walter Bright wrote:
 

 I have no idea how that would even work. Since lambdas are nested functions, 
 how would one write one in D and have it nested inside C++ code?


 
 I thought C++ lambdas were implemented as structs with the call operator 
 overloaded.


Right, but please show me an example of how that might be used.
Aug 25 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-08-25 16:58, Walter Bright wrote:


 Right, but please show me an example of how that might be used.


I've never suggested that this should be implemented.

-- 
/Jacob Carlborg
Aug 27 2017
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Thursday, 24 August 2017 at 19:08:04 UTC, Jacob Carlborg wrote:

 On 2017-08-24 17:02, 12345swordy wrote:


 They have plans to add c++ support?


 D can already link with C++, but not all features are 
 supported. Like lambdas, for example, are not supported.


I am not asking that, I'm asking regarding the project mention 
earlier.
Aug 26 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-08-26 23:32, 12345swordy wrote:


 I am not asking that, I'm asking regarding the project mention earlier.


Adding support for C++ to DStep is a long term goal, yes. But the 
compiler still needs to support those features. Unless DStep is going to 
generate C wrappers, which I would like to avoid.

-- 
/Jacob Carlborg
Aug 27 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 28 August 2017 at 06:30:53 UTC, Jacob Carlborg wrote:

 On 2017-08-26 23:32, 12345swordy wrote:


 I am not asking that, I'm asking regarding the project mention 
 earlier.


 Adding support for C++ to DStep is a long term goal, yes. But 
 the compiler still needs to support those features. Unless 
 DStep is going to generate C wrappers, which I would like to 
 avoid.


What compiler are you referring to? Clang? LDC? DMD?
Aug 28 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-08-28 20:24, 12345swordy wrote:


 What compiler are you referring to? Clang? LDC? DMD?


The D compilers, DMD and LDC.

-- 
/Jacob Carlborg
Aug 28 2017
prev sibling next sibling parent Jonathan Shamir <jonathan weka.io> writes:
On Tuesday, 22 August 2017 at 17:15:27 UTC, Walter Bright wrote:


 You're right about htod, and it's on me. It's built out of the 
 DMC++ front end. I haven't gotten around yet to releasing it as 
 open source.


We can discuss possible ways of implementing htod.

Instead, I'd rather discuss how we can make D more approachable 
and attractive to people thinking of picking up the language.

In that respect, as far as htod goes, I think it should be 
removed from the site (it could still be available online). D 
can't have an official command line utility that doesn't work.

Small steps.
Aug 22 2017
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/22/17 1:15 PM, Walter Bright wrote:

 On 8/22/2017 8:14 AM, Jonathan Shamir wrote:

 https://dlang.org/htod.html

 I click download and get an exe!

 And in the bugs section:
 No linux version.

 I'll start with the productive part. If anyone can point me out to the 
 sources of htod I would love to compile for linux + osx. Any task 
 seems more attractive to me than manually converting a 1000 line 
 header to D.


 
 You're right about htod, and it's on me. It's built out of the DMC++ 
 front end. I haven't gotten around yet to releasing it as open source.


I downloaded it. The exe is last modified April 28, 2010, corresponding 
with DMD version 2.044.

This can't possibly produce valid D headers for 2.075.1. I think it 
should be either updated or removed from the web site.

-Steve
Aug 22 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/22/2017 11:23 AM, Steven Schveighoffer wrote:

 I downloaded it. The exe is last modified April 28, 2010, corresponding with
DMD 
 version 2.044.
 
 This can't possibly produce valid D headers for 2.075.1. I think it should be 
 either updated or removed from the web site.


It doesn't correspond to the D version, it corresponds to the C compiler 
version, which is stable.
Aug 22 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/22/17 5:17 PM, Walter Bright wrote:

 On 8/22/2017 11:23 AM, Steven Schveighoffer wrote:

 I downloaded it. The exe is last modified April 28, 2010, 
 corresponding with DMD version 2.044.

 This can't possibly produce valid D headers for 2.075.1. I think it 
 should be either updated or removed from the web site.


 
 It doesn't correspond to the D version, it corresponds to the C compiler 
 version, which is stable.


But it is generating D code, no?

-Steve
Aug 22 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/22/2017 2:50 PM, Steven Schveighoffer wrote:

 On 8/22/17 5:17 PM, Walter Bright wrote:

 On 8/22/2017 11:23 AM, Steven Schveighoffer wrote:

 I downloaded it. The exe is last modified April 28, 2010, corresponding with 
 DMD version 2.044.

 This can't possibly produce valid D headers for 2.075.1. I think it should be 
 either updated or removed from the web site.


 It doesn't correspond to the D version, it corresponds to the C compiler 
 version, which is stable.


 
 But it is generating D code, no?


Sure. And the C subset of D has been very stable, too.
Aug 22 2017
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 22 August 2017 at 22:50:46 UTC, Walter Bright wrote:

 On 8/22/2017 2:50 PM, Steven Schveighoffer wrote:

 But it is generating D code, no?


 Sure. And the C subset of D has been very stable, too.


Used the tool 2 years ago. Worked like a charm.
Aug 23 2017
prev sibling next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 22.08.2017 um 17:14 schrieb Jonathan Shamir:

 The DUB package repository is horrible! More often than not, the 
 packages are so poorly written I end up just writing my own 
 implementation. Adding the ability to "rate" packages would go a long 
 way in improving the situation.


We are working on this point. There will be some form of popularity and 
quality measures, as well as top lists to discover notable projects.
Aug 22 2017
prev sibling next sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 But lets be honest. If I was just interested to learn about 
 this "modern system programming language" that is C++ done 
 right, I would dismiss D very quickly. We need to get together 
 as a community and rethink your priorities, because with 
 problems like this we're making it very hard for newcomers to 
 trust in this very poorly adapted language.

 Programming tools used by day to day programmers should be a 
 priority. Because everyone expects valgrind to work.

 The standard library should be a priority. It's far from 
 complete (hopefully my company will contribute in this respect 
 in the near future).

 The DUB package repository is horrible! More often than not, 
 the packages are so poorly written I end up just writing my own 
 implementation. Adding the ability to "rate" packages would go 
 a long way in improving the situation.

 I understand hacking the frontend is way more interesting to 
 most of the community. But if we don't find the time to improve 
 on our visibility and language maturity, D will never get the 
 attention it deserves.


+1
Aug 23 2017
prev sibling parent reply Mark <smarksc gmail.com> writes:
On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote:

 [...]

 But lets be honest. If I was just interested to learn about 
 this "modern system programming language" that is C++ done 
 right, I would dismiss D very quickly. We need to get together 
 as a community and rethink your priorities, because with 
 problems like this we're making it very hard for newcomers to 
 trust in this very poorly adapted language.

 Programming tools used by day to day programmers should be a 
 priority. Because everyone expects valgrind to work.

 [...]


This kind of criticism comes up fairly often in the forums, maybe 
once every few weeks. I can link to the recent threads on the 
matter, but I'm sure you can make an educated guess about the 
responses therein. The gist of it, in my view, is that:

"[Making] D more approachable and attractive to people thinking 
of picking up the language."

just isn't a high priority right now.
Aug 23 2017
next sibling parent reply Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 8/23/2017 3:58 PM, Mark via Digitalmars-d wrote:

 On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote:

 [...]

 But lets be honest. If I was just interested to learn about this 
 "modern system programming language" that is C++ done right, I would 
 dismiss D very quickly. We need to get together as a community and 
 rethink your priorities, because with problems like this we're making 
 it very hard for newcomers to trust in this very poorly adapted language.

 Programming tools used by day to day programmers should be a priority. 
 Because everyone expects valgrind to work.

 [...]


 
 This kind of criticism comes up fairly often in the forums, maybe once 
 every few weeks. I can link to the recent threads on the matter, but I'm 
 sure you can make an educated guess about the responses therein. The 
 gist of it, in my view, is that:
 
 "[Making] D more approachable and attractive to people thinking of 
 picking up the language."
 
 just isn't a high priority right now.


That's one way to look at it.

Another, slightly more accurate and nuanced version is that there are 
many areas for improvement, and those that are doing work to improve 
things are doing them in areas they believe are important and useful for 
their work.  That there's not more in the area <X>, that you (and 
others) believe is important, merely shows that the number that believe 
<X> is important enough to work on right now is close to zero.  That 
doesn't mean that <X> isn't also important, just that it's not at the 
top of the priority list for those getting things done.

Convince someone that <X> is higher priority than the things they're 
working on then you might see some movement on those fronts.  Or 
convince yourself that it's important enough to engage in yourself. 
This isn't really a community level issue so much as a very personal 
level issue.  It's not sufficient for something to be declared a 
community level priority if no one at the personal level is interested 
enough to contribute their time.
Aug 23 2017
parent Mark <smarksc gmail.com> writes:
On Wednesday, 23 August 2017 at 23:27:22 UTC, Brad Roberts wrote:

 On 8/23/2017 3:58 PM, Mark via Digitalmars-d wrote:

 
 This kind of criticism comes up fairly often in the forums, 
 maybe once every few weeks. I can link to the recent threads 
 on the matter, but I'm sure you can make an educated guess 
 about the responses therein. The gist of it, in my view, is 
 that:
 
 "[Making] D more approachable and attractive to people 
 thinking of picking up the language."
 
 just isn't a high priority right now.


 That's one way to look at it.

 Another, slightly more accurate and nuanced version is that 
 there are many areas for improvement, and those that are doing 
 work to improve things are doing them in areas they believe are 
 important and useful for their work.  That there's not more in 
 the area <X>, that you (and others) believe is important, 
 merely shows that the number that believe <X> is important 
 enough to work on right now is close to zero.  That doesn't 
 mean that <X> isn't also important, just that it's not at the 
 top of the priority list for those getting things done.

 Convince someone that <X> is higher priority than the things 
 they're working on then you might see some movement on those 
 fronts.  Or convince yourself that it's important enough to 
 engage in yourself. This isn't really a community level issue 
 so much as a very personal level issue.  It's not sufficient 
 for something to be declared a community level priority if no 
 one at the personal level is interested enough to contribute 
 their time.


That's the longer version of what I meant to say.

I don't think the concept of a community level priority has any 
meaning in this context- there is no centralized decision making 
mechanism in the D community. The "priority" I was referring to 
in my previous post is just a simple average of the personal 
priorities of language contributors.
Aug 24 2017
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, August 23, 2017 16:27:22 Brad Roberts via Digitalmars-d wrote:

 On 8/23/2017 3:58 PM, Mark via Digitalmars-d wrote:

 On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote:

 [...]

 But lets be honest. If I was just interested to learn about this
 "modern system programming language" that is C++ done right, I would
 dismiss D very quickly. We need to get together as a community and
 rethink your priorities, because with problems like this we're making
 it very hard for newcomers to trust in this very poorly adapted
 language.

 Programming tools used by day to day programmers should be a priority.
 Because everyone expects valgrind to work.

 [...]


 This kind of criticism comes up fairly often in the forums, maybe once
 every few weeks. I can link to the recent threads on the matter, but I'm
 sure you can make an educated guess about the responses therein. The
 gist of it, in my view, is that:

 "[Making] D more approachable and attractive to people thinking of
 picking up the language."

 just isn't a high priority right now.


 That's one way to look at it.

 Another, slightly more accurate and nuanced version is that there are
 many areas for improvement, and those that are doing work to improve
 things are doing them in areas they believe are important and useful for
 their work.  That there's not more in the area <X>, that you (and
 others) believe is important, merely shows that the number that believe
 <X> is important enough to work on right now is close to zero.  That
 doesn't mean that <X> isn't also important, just that it's not at the
 top of the priority list for those getting things done.

 Convince someone that <X> is higher priority than the things they're
 working on then you might see some movement on those fronts.  Or
 convince yourself that it's important enough to engage in yourself.
 This isn't really a community level issue so much as a very personal
 level issue.  It's not sufficient for something to be declared a
 community level priority if no one at the personal level is interested
 enough to contribute their time.


Well said.

- Jonathan M Davis
Aug 24 2017