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.

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?

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

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

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.

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 C# has in their standard libraries though, I think that you're forever going 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

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

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

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?

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.