On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote:
> http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/
> (His particular suggestion about accept patches by default is not why I post this).
> '
> We’re all talk
>
> [...]

On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote:
[]

Interesting timing! At my workplace we have a geekfest video session once a month and last week it was this:

https://youtu.be/-F-3E8pyjFo

It's worth a watch and it covers very similar ground. The presenters discuss their experiences developing subversion and other FOSS projects.

bye,
lobo

On Wednesday, 10 February 2016 at 18:31:22 UTC, Nick Sabalausky wrote:
> On 02/10/2016 01:09 PM, Joakim wrote:
>>
>> Pretty funny that he chose Stallman as his example of a guy who gets
>> stuff done, whose Hurd microkernel never actually got done, :) though
>> certainly ambitious, so Stallman would never have had a FOSS OS on which
>> to run his GNU tools if it weren't for Linus.
>>
>
> [Unimportant theorizing ahead...]
>
> I wouldn't say that's necessarily true: It could be argued the existence and proliferation of the Linux kernel reduced the priority of his Hurd work, even if only to a subconscious extent. If it hadn't been for the Linux kernel, maybe there would have been more drive (and more contributors) to Hurd.

Also because context switching got from a handful of cycle at the time to about 1000 cycles on modern CPU, making the idea of microkernel somewhat less attractive.

But saying Stallman released nothing is unfair. If we can consider hurd a failure, he was also behind emacs, early gcc and other things.

On Wednesday, 10 February 2016 at 23:55:17 UTC, deadalnix wrote:
> Also because context switching got from a handful of cycle at the time to about 1000 cycles on modern CPU, making the idea of microkernel somewhat less attractive.
>
> But saying Stallman released nothing is unfair. If we can consider hurd a failure, he was also behind emacs, early gcc and other things.

Nobody said "nothing," I specifically noted his "GNU tools" and that a microkernel was ambitious.  Just remarking that his kernel didn't get done, for a variety of reasons.

On Wednesday, 10 February 2016 at 17:17:40 UTC, Nick Sabalausky wrote:
> Unfortunately, that sounds very similar to experiences I've had here in D-land :( Gets very frustrating.

Yes - one trigger for posting it was the tone of some messages in some recent forum discussions (although it's really a tiny part of things on the whole).  'D is broken and needs a complete redesign', 'D has no chance against C# and Swift' etc.  Maybe, but grumbling isn't going to make it better, once the ground has been covered once.

I should they that although I have read his blog in the past, the trigger for reading that note was his commentary on the nanomsg hoohah (please - let's discuss that on another thread if necessary, not on this  one).  And that's the project he was referring to in this note.  I don't know all the details there, but I think his broader point about the decline of hacker culture is a much stronger one than the specific application he makes with nanomsg (my take would be a bit different).

[I'm not really able to judge situation as regards pull requests for D, although I wonder sometimes about type 1 vs type 2 errors and the balance between maintaining high standards and letting the best be the enemy of the good, given that something imperfect but useful can be the seeds of something that ends up becoming truly excellent - depending on the intrinsic sunk costs from doing things not perfectly the first time which might depend on the particular problem but also might not be obvious beforehand].

Eg for all the time spent arguing about what's holding D back, some of the real progress in terms of making the language attractive to real end-users who are going to hire people and maybe contribute resources came from people just doing stuff.  ndslice, PyD Magic (integration with python notebook), bachmeier's integration with R (which means access to all the R libraries, which is huge).

I notice Kenji rarely argues about things in the forum.  Would we be better off if he were to spend much more time here instead of fixing bugs ? :)  would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP?

Joakim:
"Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus."

No - I think he used Stallman as an example of someone who although he whined a lot actually did a hell of a lot of work even so and became the change in the world he wanted.  In my view productivity isn't about how many projects you don't manage to finish, but how many you do get done, and I am not sure I am in a position to criticize Stallman from that perspective, and even if his ideological approach isn't entirely my cup of tea, I do recognize he played a critical role there that was necessary.


Nick:
"That's a REALLY good article - quoting 'a patch in the hand is better than two in the bush'."
Yes, I think so.  Though it's delicate.  Problem is for some things making the wrong decision can be a disaster.  But, for example, with dirEntries right now - it's broken for serious use (last I checked and if it's fixed now, the point stands as it was broken for a long time).  Almost decent solutions have been proposed but fell short of perfection and then they were kind of dropped.  So the consequence is it's (possibly and if not then was for a long time) still broken.  That's not the first time this kind of thing has happened.

Was that the right trade-off between Type 1 and Type 2 errors?  If you're not making some of each kind of mistake then it may be the case that the balance is wrong.  (Depending on the situation of course - depends on what the consequences are of making a mistake.  Conservatism isn't always the lower risk option, even though it feels that way).

"* Bare assertions that there is no need for the feature, when the fact that somebody wrote a patch should be prima facie evidence that the feature was needed"
Yes.  Though with language features it's delicate, and I respect the taste of Andrei/Walter and other key people.

"Really, what I’m asking is this: Which is more convincing? Concrete computer code authored by someone with first-hand knowledge of the defect? Or the bare assertion that something is wrong with it? I mean, either one might be correct. But the first is better supported."

Yes - quite.


Lobo - thanks for video link.  Will watch.


His montage of the shift in the front cover of hacker magazines was rather revealing of broader societal shifts.  (From Byte and Dr Dobbs in the 80s to their successors becoming more like lifestyle magazines today).

I've seen the same thing happen in my lifetime in certain parts of finance.  In the beginning you have a bunch of highly unusual people who ended up there almost by accident but really care about things intrinsically and are there as exiles from the rest of the world driven by social factors.  Then success (which comes _because_ they didn't care about social factors) leads to expansion and it brings in people who are less intrinsically motivated, drawn by money and prestige and the culture changes.  Also because people who were on the outside looking in start to find being accepted into the establishment where it is warm and cosy quite appealing and lose sight of what it was that brought them success.  CoC!

(I mean that as regards the societal shift he talks about - clearly not really applicable to D, at least not today).

On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote:
> would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP?

For the most difficult/contentious issues, writing a DIP is just another form of arguing.

On Thursday, 11 February 2016 at 04:35:27 UTC, tsbockman wrote:
> On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote:
>> would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP?
>
> For the most difficult/contentious issues, writing a DIP is just another form of arguing.

Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive.

On Thursday, 11 February 2016 at 04:50:04 UTC, Laeeth Isharc wrote:
>> For the most difficult/contentious issues, writing a DIP is just another form of arguing.
>
> Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive.

True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered.

On Thursday, 11 February 2016 at 04:50:04 UTC, Laeeth Isharc wrote:
> On Thursday, 11 February 2016 at 04:35:27 UTC, tsbockman wrote:
>> On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote:
>>> would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP?
>>
>> For the most difficult/contentious issues, writing a DIP is just another form of arguing.
>
> Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive.

And not only is it more constructive but the structured format forces you to think things through and to make explicit what isn't in a forum post (which may reduce contention since its much clearer what you mean).

And even if this were not the case then there are plenty of things that people like to grumble about but that wouldn't be all that contentious once expressed in a thought through DIP even if people didn't agree with you.  Because then its all set out clearly and it becomes more of an objective technical debate.

On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote:
> On Thursday, 11 February 2016 at 04:50:04 UTC, Laeeth Isharc wrote:
>>> For the most difficult/contentious issues, writing a DIP is just another form of arguing.
>>
>> Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive.
>
> True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered.

Which ones, out if interest ?  And in your opinion were they thought through ?

On Thursday, 11 February 2016 at 04:59:16 UTC, Laeeth Isharc wrote:
> On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote:
>> True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered.
>
> Which ones, out if interest ?  And in your opinion were they thought through ?

Specifically, DIP69 and its predecessors, which propose a Rust-inspired lifetime and escape analysis system as a solution to many of D's memory model woes.

It seemed (and still seems) like a good solution to me, but I recognize that I am insufficiently experienced and knowledgeable in the relevant areas to deserve a vote in the matter.

So, I'm not necessarily saying that it should have been accepted - but I can definitely understand how frustrating it is for those who worked on it over the course of several months to have it rejected (as far as I can tell) simply because it is "too complicated". This is non-constructive in the sense that it is a subjective judgment which does not point the way to a better solution.

As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.)

In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons.