Re: Trip notes from Israel
On Saturday, 27 May 2017 at 20:21:56 UTC, Meta wrote: On Saturday, 27 May 2017 at 10:50:34 UTC, Ola Fosheim Grøstad wrote: Don't mistake my intentions. I proposed removing `body` because not being able to use it as a symbol name is often complained about on the forums, because it is a small, manageable and understandable change, because it is a net (admittedly tiny) improvement to the language, and because I wanted to write a Sure, there are many small improvements that could be made, but this is a lot of bureaucracy for the 15 minutes it takes to turn it into a contextual keyword...
Re: Trip notes from Israel
On Saturday, 27 May 2017 at 10:50:34 UTC, Ola Fosheim Grøstad wrote: Anyway, if people sense that semantic changes are too hard to get through I guess they will aim for something that is on the surface (like "body"). As a symbolic act to see if change is at all possible. Don't mistake my intentions. I proposed removing `body` because not being able to use it as a symbol name is often complained about on the forums, because it is a small, manageable and understandable change, because it is a net (admittedly tiny) improvement to the language, and because I wanted to write a "practice" DIP to familiarize myself with the process in the event that I decide to write a larger one in the future (such as fixing up and resubmitting Kenji's tuple DIP).
Re: Trip notes from Israel
On Friday, 26 May 2017 at 16:55:44 UTC, Joakim wrote: On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote: Walter and I have implicitly fostered a kind of meritocracy whereby it's the point/argument that matters. I don't see any evidence of this statement being true. Unfortunately. That's because that's all that matters. It is what almost every worthwhile organization aspires to, though very few get there. Doing anything else would be a mistake. True. Of course, like anything, debate can be overdone and you're probably right that it has been at times here. But an open source project is a fundamentally different thing than a startup, it requires much more community involvement and deliberation. Right, feedback and arguments about semantics are good, feedback on usability or integration problems are good. What is not good is lifting out design-issues into small packages and trying to fix them one-by-one with a strong emphasis on implementation cost. Democracy is great for building big things if the vision is clear and shared. Democracy is great for pointing out where the systemic problems are. Democracy is great for adapting something that is complete to new use cases. Democracy is not great for innovation, designing new solution, creating good UI experiences or even engineering... So, why-oh-why so much effort on writing DIPs on stuff like pre/post condition syntax? This has to be designed into a whole and would be better done by a small team of designers taking the _problems_ into account consulting experts on the specifics of the area. But if you want expertise you actually have to be interested in learning about that topic instead of defending what is there already. Anyway, if people sense that semantic changes are too hard to get through I guess they will aim for something that is on the surface (like "body"). As a symbolic act to see if change is at all possible. But it is rather inconsequential and rather inefficient use of resources. Which will happen to any project without a list of priorities.
Re: Trip notes from Israel
On Friday, 26 May 2017 at 16:55:44 UTC, Joakim wrote: On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote: Documentation of vibe.d was also mentioned as an important problem. More precisely, it's the contrast between the quality of the project and that of the documentation - someone said his team ended up with a different (and arguably inferior) product that was better documented. Literally they had the same engineer try each for a day. Reportedly it was very difficult to even figure whether vibe.d does some specific thing, let alone tutorials and examples of how to do it. Eh, documentation is going to be sparse for a non-corporate OSS project. If they're building products with vibe.d, presumably they can throw some consulting dollars Sonke's way and get him to help. A reasonable presumption, but I do not know if Sonke himself has capacity for such as he seems quite busy. So it might be worth thinking about alternative ways to move towards better docs for vibe.d (in collaboration with Sonke).
