"Announced by me" is a big word here, but thanks to Kevin the correct link found its way to this post! =)
Sorry about the confusion, we still try to figure out how to get things across on the mailing list! And its quite a complex topic, so it's a bit difficult to get a good summary across, without writing 10 pages of description. That's also why we kept things a little separate, so that we can have different level of details in the discussion. This post is intended to get a more general feedback on the concept, so that we don't implement things, that are already there, or proofed to be foolish. Posts by me about Events.jl, or the OpenGL package are more on an implementation level. I hope this strategy enables us to talk about the implementation and the concept separately, making things more constructive. Please feel free to also criticize the way we present things, so that we can show our project in the best way possible and get the most feedback/help! After all, we're still rookies, shooting for a fairly ambitious project. Best, Simon Am Mittwoch, 9. April 2014 17:59:34 UTC+2 schrieb Jannis Eichborn: > > Hi, > > As previously announced by Simon Danisch, I want to present our online > library concept for Julia. > > It's an online library based on a graph-database, that is supposed to > enable a very rich feature set including uploading and versioning of code, > search for code and documentation, automated tests etc… > > For starters, it will be more of an advanced interface for searching > packages and documentation. > This might be a little hard to justify, as the package system combined > with Github already does a great job. > > But I think the idea behind it becomes understandable, when you think > about scaling up the feature set in the future. > You could probably implement every feature you would like to be > independent from each another, say as different libraries or tools. > For example make an extra interface for an image library, a library for > statistical data sets, a library for binary dependencies, a library for > tutorials and examples, a forum for discussions/bug-reports, etc.... > > But I think it's extremely useful to have all these different kind of > "libraries" in one big library because the resources I listed all need to > be treated very similar. > They all might have tags, ratings, attached opinions/discussions, > dependencies, are part of a hierarchy and finally, the search interface for > them should be very similar. > In a graph library, nodes get a higher level semantic meaning very easily, > by just building connections. > In the end this would also prevent fragmentation of information regarding > the code over different systems or libraries. > > Just one example how things could be represented in an inhomogeneous > graph-like structure. > This is just a mock-up, as things are not consistent so far and might be > represented differently in the final library: > > > <https://lh3.googleusercontent.com/-lJ2meY5A_-A/U0VuCwhaNOI/AAAAAAAABj4/yJ1bPnwzktU/s1600/ImageExampleGraph.png> > You can search for the English word "Image" and already get a first > impression of what one can do with Julia and images. > > This would be especially cool, if it was deeply integrated into an IDE. > You could just click on a particular datatype and get a display of what > functions you could use on the type, or actually query example material. > Similarly, you can look-up documentations, or code samples for functions > and so forth... I hope you get the big picture! > > Another interesting use case is to combine the library with a good testing > library, so that you can define tests for every function. > Like this you can extend the library in an easy and controlled way. > Someone can just upload a new version of a function, and if it passes the > test for the function, it gets accepted. > Together with benchmarks, one could even find out, if the new > implementation is better, promoting it to the new standard implementation. > This is far out for sure, as this needs a feature set similar to Github > and beyond. > But at some point, this might turn into version control system, which can > make it very easy and conflict free to extend the functionality of Julia. > > As mentioned above the first steps will be to create an interface that > lets you insert code and search for it intelligently, based on partially > given information. Right from the start the system should allow for > multiple competing implementations of one symbol and also take care of > versions of the same functions. > > We are currently developing the first prototype of the database together > with a simple IDE to connect to it. This happens in the scope of our > Bachelor’s Thesis. The database is conceptually independent from the IDE > but of course one does not make much sense without the other. > > So if you have any kind of feedback, ideas, wishes for features, inherent > flaws you want to point out or just your two cents worth, let us know! We > want to know what people working with/on Julia need. > > Thanks and cheers, > Jannis & Simon >
