Mercurial > pylearn
view doc/v2_planning/arch_src/plugin_JB_comments_YB.txt @ 1242:316410a38f6f
comment on Yoshua's comment on James architecture
author | Razvan Pascanu <r.pascanu@gmail.com> |
---|---|
date | Thu, 23 Sep 2010 12:10:14 -0400 |
parents | 067b2f9ba122 |
children | 808e38dce8d6 |
line wrap: on
line source
YB. I am very worried about this proposal. It looks again like we would be creating another language to replace one we already have, namely python, mainly so that we could have introspection and programmable changes into an existing control flow structure (e.g. the standard DBN code). I feel that the negatives outweigh the advantages. Please correct me: Disadvantages: * much more difficult to read * much more difficult to debug Advantages: * easier to serialize (can't we serialize an ordinary Python class created by a normal user?) * possible but not easier to programmatically modify existing learning algorithms (why not the usual constructor parameters and hooks, when possible, and just create another code for a new DBN variant when it can't fit?) * am I missing something? I am not convinced that any of the stated advantages can't be achieved in more traditional ways. RP comment: James or anybody else correct me if I'm wrong. What I think James proposed is just a way encapsulating different steps of the program in some classes. These classes are serializable. They are not a programming language per se. The way I see it is like dividing your program in a set of functions. Each function is a control flow element applied to something ( like a CALL to a python function ). The idea is to wrap this functions around something to make them serializable, and also offer the added advantage that you have a graph that presents the order in which you should call the functions and you can play with that order. That is why I was trying to convince James to re-write things ( using some syntactic sugar) to make it look less intimidating ( I believe it can look much more "traditional" that it looks right now). I think a programming language might also be a overloaded term that so we might speak about different things. But if all that his proposal does is to offer some wrapper around python function that makes them serializable, and generate a execution order graph in which you can possible do simple operations ( like substitutions and replacements) I would not call it a programming language. I think the advantage of making the program aware where in its own execution flow it is and what is its execution flow can be quite useful for automating some of the things we want.