Here's my perspective. Historically, I did a lot more work on Julia than Dan used to do. I also agree with many of Dan's points in that blog post.
But conversations exactly like this one are a large part of the reason that I decided to do less work on open source development. To make that point clear: exactly this kind of thread drives developers like me away from working on Julia. The core problem with a thread like this is simple: people need to earn credibility by making large contributions to Julia before engaging in bikeshedding. Without the credibility derived from substantive contributions of code or other resources, engaging in bikeshedding is pointless because no one with commit access is going to haphazardly churn through function names to see whether it makes the community happier. It's just not worth the effort involved and everyone who's engaged in larger projects is bored by such superficial changes. In general, I think there's no reason for us to ever have any debates about naming conventions on this mailing list. It's just too minor an issue to be dealt with at this point in Julia's development. We're missing so much essential functionality that needs to be written in rough draft form first. Renaming things is trivial once the code is in place because of Julia's strong deprecation tools. But we can't deprecate functions that haven't been written yet. And most of the functions we need haven't been written yet. So, please, let's officially stop all discussion on this thread. -- John On Wednesday, April 29, 2015 at 7:52:17 AM UTC-7, 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. >
