François, perhaps we should emphasize some points we agree on: 1. There are inconsistencies in julia, both in the language and with the "guideline" 2. It's probably fair to say that a majority of people actively working on julia value code above guidelines 3. As you've noted from the lack of prompt action on your complaints, there do not appear to be hordes of developers who are breathlessly waiting for some genius on the mailing list to finally point them towards a project they can work on :-).
This is just life in open source. When you fully accept the implications of point 3, you'll come to accept that you don't have a tool for bludgeoning unpaid developers to do your bidding. But that's what you seem to be asking for, or at least that's how it may read to some folks. Volunteers do what they do because of their own internal priorities, and it's actively counterproductive to try to convince them to abandon those in preference for your own. After all, _you're_ not willing to put your money where your mouth is, so clearly it can't be that important. If you do decide to jump in, there are issues like #9493 that are a great way to get your feet wet. Or, start renaming functions and writing deprecations to improve consistency. _Many_ people have done this before you, including "new" users, and so there is no reason why it should be beyond your means. Finally, don't be so sure that people wouldn't appreciate efforts to improve process--- if you'd followed the growth of julia's testing (first Travis, then AppVeyor, then Coveralls, hopefully soon rr), I think you'd be a little less worried and more inclined simply to help speed things along. Bottom line: time is precious, and responding to long threads on the users list is a huge waste unless it results in change. Make it happen! Best wishes, --Tim On Wednesday, April 29, 2015 07:52:17 AM François Fayard wrote: > On Wednesday, April 29, 2015 at 1:58:07 AM UTC+2, John Myles White wrote: > > Let's all go back to our core work: writing packages, building > > infrastructure and improving Base Julia's functionality. We can discuss > > naming conventions when we've got the functionality in place that Julia is > > sorely lacking right now. > > I tend to disagree on this, and I still believe that good softwares need > consistency in their developing process which includes > -1- Coding guidelines: naming conventions, a good error policy > -2- Proper unit testing > -3- People who takes the lead to enforce that > > I've just talked to a friend who is one of the main developer of > scikit-learn. They have strong coding guidelines, enforced with 2 reviewers > for every patch and extended unit testing. Numpy and Scipy seem to use the > same policy. Guidelines are a good way to share experience of good and bad > habits, and as a new user I just need them. I might have upset people, but > it would also have been nice that some main developers acknowledge once > that there is a strong gap between usage and the available guideline. This > lack of concern seems to have driven away other users ( > http://danluu.com/julialang/ ) which makes me think that many of the main > Julia developers don't seem to put the 3 points mentioned above in their > priority list.
