November 24, 2018
On Sat, Nov 24, 2018 at 10:25:23AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 11/23/18 6:49 PM, Walter Bright wrote:
[...]
> > Fixing autodecode will break about everything. But you don't like breaking changes.
> > 
> > What do you suggest?
> 
> In fact, fixing autodecode will break very little. It will break some things, and I shudder to think of possible "correct" deprecation paths. But for the most part, code only cares about strings, and not the individual items inside them.
> 
> 1. foreach(x; someString) stays the same. In fact it gets better,
> because it will be more consistent with phobos
> 2. someString.front changes, breaking some code, but most of it is
> already written to deal with it. Take for example
> std.algorithm.splitter -- there are already cases to handle ranges of
> char, it will just move from auto-decoding to... intentional decoding.

Unfortunately, this will break range-based code that expect a range over a string to return dchar. And thanks to item (3) below, this breakage will be a *silent* one, which is the worst possible kind of breakage. The code will still compile, but the semantics will be different from what the code was originally expecting.  And to top it off, it will mostly work if your code deals primarily with ASCII strings. Only the poor end user on a foreign locale will even notice the breakage, and by then it's far too late.

I'm all for killing autodecoding, but we need some way to inform user code that the code needs to be updated. Silent breakage is unacceptable. Better yet, have a tool to automatically convert the code to the new idiom, possibly with some user intervention required but preferably none besides "run this command to fix your code, then recompile".


> 3. Probably the WORST part is that char implicitly casts to dchar, so things that expect dchar will still compile with strings whose element types switch to char, but instead of decoding, it will promote. Where you will find problems is where code assumes char[].front is dchar instead of using the Phobos ElementType in constraints.

Yes, this is a big problem because it's a silent breakage.


> 4. The longer we wait, the worse it will be.
> 
> There is no way to fix autodecoding without breaking code. So we have to make that sacrifice to make progress. The most painful thing I think would be a possible deprecation path where you have to be explicit about how you want things decoded in order to avoid messages.
[...]

This isn't actually as bad as it sounds. Just make strings non-ranges (temporarily), and require .byCodePoint or .byCodeUnit for iteration. Then once the deprecation cycle is over and autodecoding is no more, allow strings as ranges again. It will be painful, yes, but painful is better than silent subtle breakage that nobody knows until it explodes in the customer's face.


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.
November 24, 2018
On Saturday, 24 November 2018 at 15:19:26 UTC, Chris wrote:
> I don't understand how things are prioritized in D.

Oh thats very easy. They dont. Not really. Well there are
Wish list
https://wiki.dlang.org/Wish_list
Vision documents
https://wiki.dlang.org/Vision/2018H1

But most people ignore them and work on what they want to work on. They scratch their own itch so to speak and if you try to force them to do something else they wont work at all. If you could figure out a way to make people work for free and on things that we want that be great.

> Basic and important things seem to be at the bottom of the list (XML parser)
there was attempt on rewriting xml module but it never crossed finish line. Its from Aug 22, 2016
https://github.com/dlang/phobos/pull/4741


> The scarce resources you have are not used wisely in my opinion.

Ok try for a month to control contributors on open source project then lecture us on how to manage resources. I will wait here to laugh at your failure.
November 24, 2018
On Sat, Nov 24, 2018 at 07:50:30AM +0000, Joakim via Digitalmars-d wrote:
> On Saturday, 24 November 2018 at 02:45:46 UTC, H. S. Teoh wrote:
> > On Sat, Nov 24, 2018 at 01:38:07AM +0000, Laeeth Isharc via Digitalmars-d wrote:
[...]
> > Right now, it's still an experimental project to test out the
> > waters...  Things are looking good and it might turn into a "real"
> > project soon, but as of now, it's still experimental.
> > [...]
> 
> Interesting, good to hear it's working well. I plan to write up a post for the D blog about the Android port next month: this would make a good demo to link to, particularly if the source is available.
> 
> Any chance you'll make it available, at least as a demo app if not the source code? If you have commercial aims for this app and don't want to release either, that's fine and I understand.

I would release the code... except it still has a long way to go before it's ready for public consumption. It's definitely not going to be ready by next month, unfortunately.  But perhaps a demo APK might not be out-of-place. It's not quite presentable yet in terms of UI, but it does work, and displays nice eye-candy suitable for a simple demo.

The biggest problem with releasing the code right now is that out of convenience, I reused some geometric models from a different project of mine, which is otherwise completely unrelated to this one (and which I'm not ready to release quite yet), and as a quick hack to be able to access the data I pulled it in as a git submodule, and the model generation utility depends on some of its source files.  Before releasing the code I really should just pull out the model data directly into independent data files, instead of the "dirty" cross-dependency. (The main reason I haven't done anything about this yet, is because I hope to eventually generate the model data independently of this other project -- it's really just a quick and dirty way of obtaining some interesting geometry for testing OpenGL ES rendering, and was never meant to be a permanent dependency.)


T

-- 
Just because you can, doesn't mean you should.
November 24, 2018
On Sat, Nov 24, 2018 at 04:46:02PM +0000, welkam via Digitalmars-d wrote:
> On Saturday, 24 November 2018 at 15:19:26 UTC, Chris wrote:
[...]
> > Basic and important things seem to be at the bottom of the list (XML
> > parser)
> there was attempt on rewriting xml module but it never crossed finish line.  Its from Aug 22, 2016 https://github.com/dlang/phobos/pull/4741
[...]

Actually, if you're interested in XML, you should check out Jonathan Davis' dxml module:

> Documentation: http://jmdavisprog.com/docs/dxml/0.2.0/
> Github: https://github.com/jmdavis/dxml/tree/v0.2.0
> Dub: http://code.dlang.org/packages/dxml

It doesn't handle DTDs due to design constraints, but if you can live with that, it should work much better than std.xml.

(I'm hoping Jonathan pushes for this to be merged into Phobos, as it's far superior to std.xml IMO. But that has yet to happen.)


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom
November 24, 2018
On Sat, Nov 24, 2018 at 03:19:26PM +0000, Chris via Digitalmars-d wrote: [...]
> I don't understand how things are prioritized in D. Basic and important things seem to be at the bottom of the list (XML parser), other things get huge attention while they are of dubious value to many users. This is why I don't completely buy the "we don't have enough resources" argument. The scarce resources you have are not used wisely in my opinion. And it is a pity when I see that D has loads of potential (C/C++ interop, Objective-C interop etc.) but other new languages overtake D because they focus on practical issues too.
[...]

You have to understand that D is an open source project run by volunteers, not a for-profit organization that can afford to pay people to tell them what to do. Well, with the D foundation setup now, I suppose we could begin to pay some people to work on stuff (and we have).  But with a budget of barely over 1K per month, the bulk of the work is still done by unpaid volunteers who contribute purely out of their own initiative.  Demanding that volunteers work on tasks that you deem important is about as effective as herding cats.  This is not to excuse the state of things in any way, but it's just a realistic evaluation of the actual situation.

Even though Walter and Andrei serve as BDFL and visionary leaders, they can no more order any of us to do anything than a random stranger from the street can dictate to you how you ought to spend your free time. They can't just "use our resources" however they want, because this isn't a top-down organization where the higher ups assign tasks to the lower downs. This is a gathering of like-minded peers who contribute as equals according to their interest and capacity because they believe in the product.

This is really what we mean when we say "if you want X to change, do it yourself" or "be the change that you want to see".  It should not be misconstrued as writing anyone off, an excuse for laziness, or being dismissive of newcomers.  Rather, it's an open invitation to participate in the gathering of peers, to have a hand in producing something we hope and believe will be wonderful. Whether you accept the invitation or not is really up to you -- it's not a demand, but just an invitation. If you see the value in D, and if you feel you can contribute something useful, then you will be welcomed.  But if you expect to tell others what to do while not contributing anything yourself, then don't be surprised if you get the same reactions you might give when a random stranger walks up to you and starts dictating how you ought to be spending your free time.


T

-- 
What's a "hot crossed bun"? An angry rabbit.
November 24, 2018
On Saturday, 24 November 2018 at 16:46:02 UTC, welkam wrote:

> But most people ignore them and work on what they want to work on. They scratch their own itch so to speak and if you try to force them to do something else they wont work at all. If you could figure out a way to make people work for free and on things that we want that be great.

That's definitely a problem. It's not completely true though. Some people answer questions on Stack Overflow even though it doesn't benefit them in any way to do so - they get (more or less) meaningless points for answering questions. Some people put in long hours for minor Linux distributions, doing things that don't benefit them at all. Some people answer newbie Linux questions for hours at a time. Heck, I wasted time getting one of my projects to work on Windows, even though I would rather change jobs than use Windows.

I think the problem with D is that the work that needs to be done is not clearly defined, you don't get credit in any way, and even if you do it, there's no reason to think you've done it "right", so it might all be for nothing. If you can fix those three things, you might be able to get people to contribute to things they don't care about.

There are other solutions too. If you can partner with a department in a university, you can give students internship credit for working on certain projects.
November 24, 2018
On Saturday, 24 November 2018 at 17:37:36 UTC, H. S. Teoh wrote:
> On Sat, Nov 24, 2018 at 03:19:26PM +0000, Chris via Digitalmars-d wrote: [...]
>> I don't understand how things are prioritized in D. Basic and important things seem to be at the bottom of the list (XML parser), other things get huge attention while they are of dubious value to many users. This is why I don't completely buy the "we don't have enough resources" argument. The scarce resources you have are not used wisely in my opinion. And it is a pity when I see that D has loads of potential (C/C++ interop, Objective-C interop etc.) but other new languages overtake D because they focus on practical issues too.
> [...]
>
> You have to understand that D is an open source project run by volunteers, not a for-profit organization that can afford to pay people to tell them what to do. Well, with the D foundation setup now, I suppose we could begin to pay some people to work on stuff (and we have).  But with a budget of barely over 1K per month, the bulk of the work is still done by unpaid volunteers who contribute purely out of their own initiative.  Demanding that volunteers work on tasks that you deem important is about as effective as herding cats.  This is not to excuse the state of things in any way, but it's just a realistic evaluation of the actual situation.

this concept was repeated until the nausea ...

> Even though Walter and Andrei serve as BDFL and visionary leaders,

AHAHAHAHAHAHAHAHAHAH

This is the point! They are considered leaders and ARE NOT leaders! Nobody asks that they give orders, a leader is asked to give a direction, a VISION!

> they can no more order any of us to do anything than a random stranger from the street can dictate to you how you ought to spend your free time. They can't just "use our resources" however they want, because this isn't a top-down organization where the higher ups assign tasks to the lower downs.
> This is really what we mean when we say "if you want X to change, do it yourself" or "be the change that you want to see".  It should not be misconstrued as writing anyone off, an excuse for laziness, or being dismissive of newcomers.  Rather, it's an open invitation to participate in the gathering of peers, to have a hand in producing something we hope and believe will be wonderful.
> Whether you accept the invitation or not is really up to you -- it's not a demand, but just an invitation. If you see the value in D, and if you feel you can contribute something useful, then you will be welcomed.  But if you expect to tell others what to do while not contributing anything yourself, then don't be surprised if you get the same reactions you might give when a random stranger walks up to you and starts dictating how you ought to be spending your free time.

Nothing is more effective than the example, to motivate!

Since the transparency of the leaders and the foundation is very bad, let's look a little bit more about what secret strategy they are concentrating on:

Walter, months to convert the backend from C ++ to D, be careful, in a compiler in which you can not even turn on the GC, what a show, pride for the D programming language! Should we talk about the DIP1000 documentation?

Andrei: https://github.com/andralex
Need to add more? More than a gatekeeper, this is a solid brick wall.

With these examples, the problem is the lack of contributions?

This is pure collective madness.

November 24, 2018
On Friday, 23 November 2018 at 23:49:16 UTC, Walter Bright wrote:
> On 11/23/2018 4:59 AM, Chris wrote:
>> Then there was the whole issue of string handling and autodecode and the way the leadership / big guys in the community dealt with it. I was of the opinion that such an essential issue had to be fixed immediately (of course with a proper path to fix it). I even offered to be the guinea pig and document the transition. But no.
>> 
>> Then there were the dreaded dmd updates. "Shit, what will break now?" this question would be my constant companion.
> Fixing autodecode will break about everything. But you don't like breaking changes.
>
> What do you suggest?

The real reason he is upset is because reality didnt match with his internal view(expectations). This creates anger, disturbance(dont know better words). Then "left brain" tries to come up with reasons to explain this feeling and thats what you get in his posts. Left brain coming up with reasons.

People in neuroscience know for some time now that brain comes up with possible sounding explanations that are not the real reasons. Here are example from split brain. Talking about left explaining stuff start at 1:16
https://www.youtube.com/watch?v=wfYbgdo8e-8
Another example from Sam Harris. 19:55-20:10
https://youtu.be/gfpq_CIFDjg?t=1195

If you want these kinds of post to go away start managing expectation (almost impossible) or improve D (the thing you already doing)
November 24, 2018
On Saturday, 24 November 2018 at 18:02:59 UTC, welkam wrote:

> This creates anger, disturbance(dont know better words).

Frustration. In this case, of defenestration-inducing variety.


November 24, 2018
On Saturday, 24 November 2018 at 17:37:36 UTC, H. S. Teoh wrote:
> Even though Walter and Andrei serve as BDFL and visionary leaders, they can no more order any of us to do anything than a random stranger from the street can dictate to you how you ought to spend your free time. They can't just "use our resources" however they want, because this isn't a top-down organization where the higher ups assign tasks to the lower downs. This is a gathering of like-minded peers who contribute as equals according to their interest and capacity because they believe in the product.

The Vision document is overdue (https://wiki.dlang.org/Vision/2018H1 - "This document discusses the high-level vision for D with semestrial granularity. It is released in January and July of each year. Note that the goals presented are those the D leadership works on, explicitly fosters, or strongly believes are important for the success of the D language"). I'm sure more people would contribute if the vision and goals were better defined.

Imagine someone has a great idea for improving the GC. But they aren't certain if GC is going to stay in D for the future. Perhaps it will transition towards reference counting, Rust-like solution or manual memory management. Without design and vision, you might scare away contributors, because they don't want to put any larger effort into something that would get thrown into trash few months down the road.