http://spot.livejournal.com/308370.html

Anyone care to total up the fail points for D?

On Tuesday, 28 July 2015 at 19:11:24 UTC, Walter Bright wrote:
> http://spot.livejournal.com/308370.html
>
> Anyone care to total up the fail points for D?

Here's a spreadsheet I've set up, feel free to test and add a comment if a particular point passes or fails:

https://docs.google.com/spreadsheets/d/17BlHF_2VAl2UUi6acymeirvVKxVZPsUnnPkLP-vX1Ec/edit?usp=sharing

On Tuesday, 28 July 2015 at 19:11:24 UTC, Walter Bright wrote:
> http://spot.livejournal.com/308370.html
>
> Anyone care to total up the fail points for D?

LOL. There's a lot of highly subjective stuff on that list, and some of it seems to think that normal practices are bad, like

* Your code tries to install into /opt or /usr/local

It's pretty much _standard_ on Linux systems that make install is going to put your stuff in /usr/local unless you told configure to use a different PREFIX. And on FreeBSD, pretty much everything actually gets installed in /usr/local normally anyway.

He definitely have some good points, but he has enough in there that a _lot_ of people would disagree with on that the list becomes pretty useless as an actual metric IMHO. And his scoring system is going to put most projects into fail territory _very_ quickly.

An interesting read though.

- Jonathan M Davis

On Tuesday, 28 July 2015 at 19:30:45 UTC, Jonathan M Davis wrote:
> On Tuesday, 28 July 2015 at 19:11:24 UTC, Walter Bright wrote:
>> http://spot.livejournal.com/308370.html
>>
>> Anyone care to total up the fail points for D?
>
> LOL. There's a lot of highly subjective stuff on that list, and some of it seems to think that normal practices are bad, like...
>
> - Jonathan M Davis

Yea, I disagree on the "/usr/local is bad" and "anything other than GNU make is bad". A few of the items are over the top too ("Your releases are only in an encapsulation format that you invented" Do people really do this?!).

On Tuesday, 28 July 2015 at 19:30:45 UTC, Jonathan M Davis wrote:
> And his scoring system is going to put most projects into fail territory _very_ quickly.
>
> An interesting read though.
>
> - Jonathan M Davis

Because most project fail?

On 7/28/15 3:11 PM, Walter Bright wrote:
> http://spot.livejournal.com/308370.html
>
> Anyone care to total up the fail points for D?

When reading this, consider that it's over 6 years old.

-Steve

On Tuesday, 28 July 2015 at 19:45:03 UTC, Minas Mina wrote:
> On Tuesday, 28 July 2015 at 19:30:45 UTC, Jonathan M Davis wrote:
>> And his scoring system is going to put most projects into fail territory _very_ quickly.
>>
>> An interesting read though.
>>
>> - Jonathan M Davis
>
> Because most project fail?

And do _any_ of them fail for the reasons on this list? Heck, the Linux kernel is _way_ into fail territory the way he scored it. There are plenty of reasons that open source projects fail, but I question that any of them actually failed because of anything on this list.

- Jonathan M Davis

On 7/28/2015 12:30 PM, Jonathan M Davis wrote:
> LOL. There's a lot of highly subjective stuff on that list, and some of it seems
> to think that normal practices are bad, like

I agree, but it's still worth taking a look at it and seeing if there are any action items we should address.

On 7/28/2015 12:35 PM, Alex Parrill wrote:
> A few of the items are over the top too ("Your releases are only in an
> encapsulation format that you invented" Do people really do this?!).

I think that's just part of a larger point to use standardized tools as much as practical, and not use custom tools that are not relevant to the product being developed.

I'd probably add to this list using a build system that required installation of a dozen programming languages :-)

On Tuesday, 28 July 2015 at 21:27:32 UTC, Walter Bright wrote:
> On 7/28/2015 12:30 PM, Jonathan M Davis wrote:
>> LOL. There's a lot of highly subjective stuff on that list, and some of it seems
>> to think that normal practices are bad, like
>
> I agree, but it's still worth taking a look at it and seeing if there are any action items we should address.

The last time I tried to build dmd from source (on OS X) I found the process pretty clunky compared to building similar languages, like, say OCaml or Nim. I don't recall all of the pain points, but I don't do it any more; I just grab the binary.

It would be great if the dmd build from source was just a few simple steps I could run (git clone repo, make, make install, or similar) and be confident that I had a working dmd. If that's how it is now, just disregard this message...