On 8/20/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: > On 8/20/07, David Chisnall <[EMAIL PROTECTED]> wrote: > > It's a nice idea, although it's purely interpreted. I've been > > working on a JIT-compiled version of Smalltalk using the GNU > > Objective-C runtime a bit over the summer. I was hoping to have > > something partially-working in svn a week or so ago, but I got > > distracted with the compositing manager, which seemed a little more > > user-visible (and therefore important for 0.3). > > > > David > > > > On 20 Aug 2007, at 15:28, Jesse Ross wrote: > > > > > I just found this the other day: > > > > > > http://blog.neontology.com/posts/2007/08/11/whats-nu > > > > > > http://blog.neontology.com/posts/2007/08/17/a-few-nu-details-emerge > > > > > > http://blog.neontology.com/posts/2007/08/19/a-glimpse-of-nu > > > > > > There doesn't seem to be a release yet, but once there is, it could > > > be interesting to see if it runs on GNUstep/Etoile, as an alternative > > > to Objective-C. > > Here is my thoughts on script language for Etoile: > > The choices for script languages are: > (1) very similar to Objective-C. > (2) provide something Objective-C doesn't have. > > StepTalk would be the best choice for (1). > So the discussion would be focused on (2). > The most popular languages, like Ruby, Python, Perl, > are mostly OOP and redundant to Objective-C. > All you get is another syntax and their libraries. > Nu falls into the same situation where you don't > get anything more except the syntax. > > So for option (2), I would say Io is a good candidate. > It is proto-type and provides concurrency, > which is very different from Objective-C. > > The core of Io seems to be more stable now > and I think we can start port it again. > What I learn from porting other applications > is that it is hard to track the changes. > So in the end, it becomes a fork. > > In that case, we can just fork Io and uses > Foundation for most of the basic data structure (string, array, etc). > In that case, we can get most of Io without the redundancy.
As you say, in the end it usually becomes a fork, so we better be careful. It also depends on what we /want/ to have. Personally I don't care that much about scripting capacity per itself -- I mean, yeah, it's cool and is useful to bind apps together, but StepTalk already provides an excellent architecture for that and is available Now :-) What I am much more interested in is a more dynamic language to write applications. Why ? well, objc is great, but more dynamism is better, and we can provide that kind of dynamism with a "script" language while it's (mostly) doable but much harder with objc. In particular, I want to be able to inspect objects at runtime, change methods at runtime, provide good refactoring tools, etc. It could be done with objc but with great effort, while it'd be fairly easy to provide such an environment with an interpreted language. Moreover, the fact that objc has a runtime and do dynamic dispatching provides us with a unique capacity to integrate trivially objc/c/c++ code with another dynamic language -- so you could really just write your app with something else than objc, and only write a few methods in objc/c/c++ if needed. Note also that we don't really need in that case 3rd party libraries that a particular language would provides -- as it would simply be another way to access gnustep/etoile frameworks ! It's closer in my mind to "a different way to write objc for the objc runtime" than a completely new language/environment. With that particular approach in mind, I think we have three good candidates for Etoile: - David's smalltalk JIT - Something based on StepTalk (eg similar to the gorm palette I wrote) - io Io is neat, and we had a bridge that allowed us to write applications before -- so it'd be conceivable to use it. But... we don't really care about using a io third party libraries that io gives, and keeping track to Io seems to be a certain amount of work (considering it's broken atm). Something using StepTalk Smalltalk implemention would be trivial to do; but it's not the fastest thing ever, and we'd only care anyway about the smalltalk implementation in that case, not the full steptalk. That left David's implementation, and imho that'd be the better suited thing for us: - small, only provides what we need - will be reasonably fast with JIT - and fully integrated to the objc runtime Thoughts? -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à enlever." -- Antoine de St-Exupéry _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
