Good generic API design is one of the hardest problems around. For many problem areas, we just haven't found the right design yet. JuMP is one of the prime examples of brilliant work in this area. Mathematica is the best example of consistent APIs in a language and it's ecosystem because Stephen Wolfram literally reviews and approves every single function that's added. We can't do that since this is an open source community and we don't have dictators, and honestly no one has the time or breadth of expertise to do this for all the amazing areas people are using Julia in. There are some things that are helpful, however.
*GitHub orgs.* Having related packages under a single org is weirdly effective – way more than it seems like it should be. I think this is about awareness and communication. Not a panacea, but more helpful than you would imagine. *Communication.* Long hard conversations like this one <https://github.com/JuliaML/Roadmap.jl/issues/8>. Get people talking about what the common API should look like. Once people agree on a good one, implementation is often easier than one might think. *Generic functions.* Julia's multiple dispatch is good at this, especially because it allows you to disentangle nouns and verbs, and different people can work on different parts of the vocabulary. Have a good set of nouns like Distributions <https://github.com/JuliaStats/Distributions.jl>? Anyone can add their own verbs. Have some good consistent verbs? Making them apply to your own nouns is no problem either. See the esoteric-seeming expression problem [1 <https://en.wikipedia.org/wiki/Expression_problem>,2 <http://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions/> ,3 <http://www.ibm.com/developerworks/library/j-clojure-protocols/>] – which doesn't even occur to Julia programmers as being a problem because the solution is so natural. *Persistence.* The more speculative and active a research area is, the less likely we are to have a consensus on what the generic interfaces and APIs should look like. Optimization APIs were all over the place until things like JuMP and Convex came along. Now you can swap out different solvers easily and keep the expression of your problem the same. Changing deep learning backends should be just as easy, but it's certainly not – because people are still trying to figure out how what the interface between how you program and how you implement these systems is. *Summary:* keep trying, communicate, create organizations, and use multiple dispatch effectively. On Sat, Oct 8, 2016 at 10:12 AM, Tsur Herman <tsur.her...@gmail.com> wrote: > I noticed this also .. and this is why I chose to "rip" some packages for > some of its functionality. > > From what I observed the problem is the "coolness" of the language and the > highly creative level of the package writers. Just as the first post here > states the seemingly two advantages , cool language and super-creative > package writers .. can some time have a "babel tower" effect. > > I encountered this with respect to image processing geometry primitive > manipulation etc .. the problem is: too many types!! > > if something can be represented as an array with some convention for > example MxN array where M is the Descriptor size and N is the number of > Descriptors .. then it is better to use and support that > than to declare more specialized types. > > At least for fast paced research and idea validation it is better. > Probably for implementation and performance specialized types optimized for > speed will be required.. > > >
