nengo / nengo-1.4

Create and run detailed neural simulations
http://www.nengo.ai/nengo-1.4
96 stars 22 forks source link

Learning refactoring #199

Open tbekolay opened 12 years ago

tbekolay commented 12 years ago

The learning code has been refactored a few times, but it's probably a good idea to get a group together to figure out a good API. Rather than worry about the Java implementation, we should approach this from the perspective of the Python API, and worry about the Java implementation after.

codemercenary commented 11 years ago

What will be the canonical language for the API? For access reasons, imho, it's probably a good idea to write your reference interfaces in Java, and then only provide implementations in Python. Java is a very good interchange language, and allowing users to make use of other dialects that target the JVM may be advantageous in the long run.

Are there any documentation generators for Python that target the Javadoc format?

tbekolay commented 11 years ago

I believe we're moving towards making Python the canonical language for the API, and providing this Java backend as one possible implementation. Our argument is the same, oddly, that Python is a good glue language, and it's easy to write interfaces that can easily be swapped out for different backends... that's probably just a difference of expertise; people in our lab are more familiar with Python so we know how it's all done in Python already.

codemercenary commented 11 years ago

Good to hear that your team has experience with a modern language like Python. Too often, I’ve seen new projects started on old technologies chosen simply due to the developer familiarity.

I’m reading through the Nengo documentation to get a better grasp of the system. It seems like Nengo implements the engine architecture, with a “specify-and-execute” paradigm for model construction. This is, of course, a very sound architecture for performance-critical systems.

I’m starting to see what you meant by recoding your existing Java logic in Python and waiting to see what the similarity is. Right now, I understand the purpose to be to expose a scripting capability to your end-user; generally Python is a good choice, here, as it’s designed to be a scripting language, but that purpose could have been trivially accomplished simply by running user code in Jython and offering some convenience wrappers to the Java API, so I feel like I’m missing something.

My main concern is making your project buildable from source with minimal effort in order to make it accessible to other developers like myself. Ultimately, my goal is to have everything written such that all dependencies are automatically downloaded, and that the solution tree is zero-configuration and binary-free. Maven seems like a great choice to accomplish most of this, and distutils seems like it could accomplish some of this in a minimal way. Otherwise, I’m not particularly attached to any single language or platform.

--Jason S.

From: Trevor Bekolay Sent: Sunday, December 23, 2012 2:36 PM To: ctn-waterloo/nengo Cc: Jason Sanchez Subject: Re: [nengo] Learning refactoring (#199)

I believe we're moving towards making Python the canonical language for the API, and providing this Java backend as one possible implementation. Our argument is the same, oddly, that Python is a good glue language, and it's easy to write interfaces that can easily be swapped out for different backends... that's probably just a difference of expertise; people in our lab are more familiar with Python so we know how it's all done in Python already.

— Reply to this email directly or view it on GitHub.