Norbert, Sounds good.
Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [email protected] Tel: (352) 273-6785 FAX: (352) 392-7029 >>> [email protected] 12/12/08 7:10 PM >>> On Fri, 2008-12-12 at 08:57 -0500, Bill Schwab wrote: > Norbert, > > Not to start an argument or anything, where do we disagree? I assume I > am a bit more jaded about the usefulness of _most_ canned components, > but freely admit that the odd thing here or there can be a life saver. > Oh, after reading your post the second time I'm not all that sure if we disagree :) > "The need for C is quite obvious. It is the best accepted macro > assembler ever invented." > > --- May I steal that? Well said! > thanks. Take it! Norbert > Bill > > > > > The need for C is quite obvious. It is the best accepted macro > assembler ever invented. > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: [email protected] > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > >>> [email protected] 12/12/08 6:04 AM >>> > On Wed, 2008-12-10 at 16:08 -0300, Alexandre Bergel wrote: > > Dear List, > > > > Something is trotting in my head for few weeks. According to the mails > > > exchanged on this list, it seems that interacting with C is of a high > > > priority. I was wondering whether you had a similar need for talking > > to the Java world. Few months ago, I worked on Athena, a small > > Smalltalk VM written in Java. It can be interfaced with Squeak. This > > means that within Squeak, you can create Java objects and talking > > directly to them within Squeak. > > > > Is there anyone who need this? I am ready to continue on this, but I > > would like to be use case driven. > > > The need for C is quite obvious. It is the best accepted macro > assembler ever invented. I can see what Bill is talking about > but I don't see it that way. If you want to be on the safe side > you focus on the least common denominator and that is C nowadays. > Using C you have the highest odds that you are able to interface > with anything else. That is the same reason why IDL sucks. It is > built after the least common denominator (which is C). So the > interfaces are clumsy and cumbersome. Having two high-level > languages interfacing via IDL is not that powerful you just lose > on both sides. > > What you are talking about is more an integration than an interfacing > issue. In this case there could be some gain. Java has its place and > it is not competing with C. So there are at least two languages that > are accepted today of different reasons. Widening the view on this > topic I would add javascript, too. > > The fashion to implement in/script java has already began. The number > of languages like javascript, groovy, jython, jruby, beanshell ... > is speaking for itself. > > So what you are talking about sounds useful to me. I have two use > cases in mind: > > Use case ME: > > The micro edition approach could bring squeak/smalltalk to mobile > devices which I would like to see. Athena is capable of that but > it has no graphics. On the other hand there is potato that is able > to execute a squeak image. For this approach a combined effort of > athena and potato would be a good thing. > > Use case SE: > > The standard edition approach will make use of the ScriptHost > extension that comes with Java 6. Being able to script any java > application with smalltalk would be just wonderful. I'm working > wih rhino (mozillas javascript engine in java) at the moment and > it is really wonderful. You focus on javascript and take java > as your assembly language to code """low level""" tools :) > > > Hope this helps, > > Norbert > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
