CTFE ^^ (pow) (page 10)

On Monday, March 26, 2018 16:26:38 Guillaume Piolat via Digitalmars-d wrote:
> On Saturday, 24 March 2018 at 16:37:06 UTC, Manu wrote:
> > I'm not sure why I seem to have to defend the idea that it's a
> > *great
> > thing* that D (in theory; according to the advertising
> > brochure) does
> > away with these requirements.
>
> Manu is not the only one who has to write such programs because
> of ^^ (log, exp, cosh, sinh, tanh... need pow to be CTFE to be
> CTFE themselves).
> It's a lot more unconvenient, and plain different semantics
> (can't parameterize the table based on a compile-time value) when
> compared to having working CTFE.

I think that that we all agree that having these functions work with CTFE would be great. The disagreement is mostly on how much of an inconvenience it is or how big a deal that inconvenience is.

Ultimately, it's just a question of someone taking the time to do the work, not whether the work is desirable. And fortunately, it looks like at least some of those functions have had recent work done towards making them work in CTFE (e.g. the PR that Walter linked to in another post).

- Jonathan M Davis

April 01, 2018

Re: CTFE ^^ (pow)

Posted by Joakim
in reply to Manu

Permalink

Joakim

Posted in reply to Manu

Permalink

Been meaning to respond to this for some time now, finally got around to it. :)

On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:
> On 18 March 2018 at 17:28, Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> Perhaps the community simply has different priorities than you? For example, my Android port has never gotten much use either, which is fine as I primarily did that work for myself.
>>
>> Nevertheless, you have to think of D as like working in a startup: if you see something that you think needs doing, you have to drive it yourself or it will never get done. Pretty much the same for most any OSS project too.
>
> This is such an easy and readily-deploy-able response here.
> What you say is true, and I totally understand this... but at the same
> time, that's not actually the relationship I want to have with my
> tool. A startup probably shouldn't still be a startup 10 years later.

Then maybe D is the wrong tool for you?  Almost any tool that I know of, you either have to pay a ton of money or be willing to invest a ton of your development time to maintain yourself.  D is in the latter camp for anything serious, which is why Weka contracts with the ldc devs and Sociomantic wrote their own garbage collector and Ocean @nogc libraries.

There are a few exceptions to this rule, ie clang mostly open-sourced by Apple and available for free, but almost no tools work that way. You seem to expect D to work like clang without having an Apple behind it, only the largest company on the planet! :)

> In your case, doing the android work was obviously an interest you had
> on the side, and you gain something from the work itself.
> I have a small amount of that, but that's not where I'm at, and it
> never has been. I want to use D to do my job, because I'm fed up with
> C++. I want to engage in D the way I think D should **EXPECT** it's
> users to engage in D; as an end-user, who uses the tool to get their
> jobs done.

Great, you can all pay Walter $100-500 like you do for all your other tools and then you can get your paying job done. Oh, you never paid Walter anything? Well, then the expectations are different.

> If D is a large-ish scale hobby project among a bunch of people with
> mutual interests, then that should be more clearly communicated, but I
> don't think that's the intent, and I feel perfectly fine interacting
> with D in the way D is intended to be interacted with.

It has elements of that, but it's growing into something more, particularly with the fundraising efforts recently.  Whether they will succeed, nobody can predict.

> Incidentally, this particular work I'm doing is on a multimedia library intended for the community... so I really am truly trying to contribute something of value!! But like most of my projects, I tend to get blocked at some point, and then it goes on hold indefinitely.

I know, I'm not saying your ultimate goal is selfish in this case.  However, if you want to use it in your job, that's a different matter.

On Monday, 19 March 2018 at 01:15:28 UTC, Manu wrote:
> On 18 March 2018 at 17:55, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> I definitely agree with this. If the folks fixing stuff don't have the same priorities as you, then there's a high risk that what you want to be fixed won't get fixed, and that's often how things go with open source projects.
>
> And here it comes again!
> I understand the reality, and echo-ing statement sounds so good to the
> community... but it's a terrible opinion to propagate if the goal is
> for D to be successful.
> You're effectively saying "D is a hobby/toy, therefore you can't bank
> on it with confidence". If I weren't a deluded zealot, there's NO WAY
> I'd let my business invest in this technology when the crowd endlessly
> repeats this sentiment.

Then don't, but that's the reality of where D's at. There's a wide spectrum between hobby/toy and production tool that conservative businesses pay thousands of dollars for, so they can make sure it's super-stable and supported.  D is somewhere in between, closer to the former than the latter.  That means it's more suited for startups like Sociomantic or Weka and not for old-school conglomerates like HP.  If you want the stability of the latter while paying nothing, it's your expectations that are wrong.

> So, while it IS a practical reality, there needs to be very strong
> motivation from the community (and organisation) to combat that
> practical reality.
> I would strongly suggest; never say a sentence like this again. It's
> the wrong attitude, and it gives an undesirable impression to users.
> (assuming the goal is for D to be successful, and not a fun hobby for
> the devs)

It is the _truth_, so it should be repeatedly said.

>> But at the same time, if you come to D, see all kinds of great things about it, and think that it's going to be fantastic but keep running into things that cause you problems when you try to use D, and then those pain points don't get fixed even after years of dealing with the language, that's going to be very frustrating - even more so if you've invested a lot of time and energy into it.
>>
>> On some level, the only solution is to buckle down and fix your pain points yourself, but that can also be quite frustrating.
>
> Or hire staff who are paid to work on 'boring' issues. I would make regular donations if I could be satisfied that my decade old issues would be addressed. I wonder how many others would too?

There has been a bountysource for many years, linked from the front page of the wiki: did you ever pick an issue and put a bounty on it?  If not, you have not done what you'd said you'd do.

I don't mean to put all the blame back on you, the community has failed so far to tie some business model to the OSS development process, something without which no OSS project has ever gone anywhere. Whether it's the consulting model that the linux kernel started off with, or the ad-based model of Firefox/Chrome, or the hybrid model of Android, every major OSS project you've ever used in production had a business model powering it behind the scenes.

D has so far failed to have one, which is partially why it's still a "startup." The recent Opencollective effort is one possible way to change that. I have suggested another paid model in this forum before, which is the most successful software licensing model today.

For you to ever get D in production, outside of startups, one of these business models will need to be used by the D team.

Forums