I haven't read SICP, but I thought that this email would be inspirational to us.
---------- Forwarded message ---------- Date: 22 Nov 2005 16:34:10 +0100 From: Shae Matijs Erisson shae@ScannedInAvian.com To: pragprog@yahoogroups.com [...]
From http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-3.html
This book is dedicated, in respect and admiration, to the spirit that lives in the computer.
``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''
Alan J. Perlis (April 1, 1922-February 7, 1990)
In my opinion, all programmers should read SICP, I'm glad it's free.
On 23 Nov 2005, at 17:46, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
I haven't read SICP
Do so now!
I know we have the Kguile object, but bear with me.
I've been reading SICP, and it struck me that it would be an amazing thing, to be able to have a common PD-scripting language, similar to the scheme they use in SICP (well, similar or better, whether that means more or less smalltalky or ruby-esque, whatever).
One of the things I'd like to introduce in teaching PD is to remove the fear people have of building their own objects if/when they need to, because of their perception of programming, and of languages like C.
I would be a happy bunny if I could, mid-way through a PD course (I'm helping to plan such a thing next week), I could introduce PD-scripting in a more unified way than saying : 'Ok there's py/pyext, gridflow/ruby, kguile, etc etc etc. Pick one, or read Kernigan C book'.
Has anyone got any ideas on this? I know Davide Morelli wants (eventually) to create a Lisp interpreter for PD, but I would like to hear thoughts on what the best route for a unified scripting framework for PD could be...if there can be such a thing at all?
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Nov 24, 2005, at 5:09 AM, David Plans Casal wrote:
On 23 Nov 2005, at 17:46, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
I haven't read SICP
Do so now!
I know we have the Kguile object, but bear with me.
I've been reading SICP, and it struck me that it would be an amazing thing, to be able to have a common PD-scripting language, similar to the scheme they use in SICP (well, similar or better, whether that means more or less smalltalky or ruby-esque, whatever).
One of the things I'd like to introduce in teaching PD is to remove the fear people have of building their own objects if/when they need to, because of their perception of programming, and of languages like C.
I would be a happy bunny if I could, mid-way through a PD course (I'm helping to plan such a thing next week), I could introduce PD-scripting in a more unified way than saying : 'Ok there's py/pyext, gridflow/ruby, kguile, etc etc etc. Pick one, or read Kernigan C book'.
Has anyone got any ideas on this? I know Davide Morelli wants (eventually) to create a Lisp interpreter for PD, but I would like to hear thoughts on what the best route for a unified scripting framework for PD could be...if there can be such a thing at all?
There are some efforts along these lines, check the "tgrill's alternate loader" thread on pd-dev.
But why not teach your students to make their own objects in Pd? You don't need anything outside in order to write your own objects.
.hc
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
Hi Hans
On 24 Nov 2005, at 19:18, Hans-Christoph Steiner wrote:
There are some efforts along these lines, check the "tgrill's alternate loader" thread on pd-dev.
I participated in that thread, and AFAICT it didn't propose particular languages, but rather it is attempting to be able to load objects written in -any- language.
I was asking for opinions on what language people would choose to teach external object scripting in PD, and whether there was any thoughts on a unified scripting language for PD.
But why not teach your students to make their own objects in Pd? You don't need anything outside in order to write your own objects.
Good point, however there are occasions where it is less than possible to achieve something in PD itself. Also, in my experience, it illustrates the point perfectly, when you are trying to explain that PD externals do not necessarily -have- to be written in C, to be able to just show people a few lines of faily simple Ruby or Python.
It makes people feel that if they need to go that way, it won't be impossibly difficult, IYSWIM.
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Nov 27, 2005, at 4:58 AM, David Plans Casal wrote:
Hi Hans
On 24 Nov 2005, at 19:18, Hans-Christoph Steiner wrote:
There are some efforts along these lines, check the "tgrill's alternate loader" thread on pd-dev.
I participated in that thread, and AFAICT it didn't propose particular languages, but rather it is attempting to be able to load objects written in -any- language.
I was asking for opinions on what language people would choose to teach external object scripting in PD, and whether there was any thoughts on a unified scripting language for PD.
The only learning materials that I know of for this is the Externals HOWTO, which is all about C externals.
But why not teach your students to make their own objects in Pd? You don't need anything outside in order to write your own objects.
Good point, however there are occasions where it is less than possible to achieve something in PD itself. Also, in my experience, it illustrates the point perfectly, when you are trying to explain that PD externals do not necessarily -have- to be written in C, to be able to just show people a few lines of faily simple Ruby or Python.
It makes people feel that if they need to go that way, it won't be impossibly difficult, IYSWIM.
Yes, that would be nice. Right now the loader stuff is just the basics. It would be great to see a working ruby/etc. loader so that we could have some objects written in a scripting language without using a language obj like [py] or [tow]/[widget].
.hc
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
It would be great to see a working ruby/etc. loader so that we could have some objects written in a scripting language without using a language obj like [py] or [tow]/[widget].
I'm sorry i don't know gridflow/ruby, but i'd be interested about the fundamental difference between using ruby and Python in the PD context.
thanks, Thomas
On Sun, 27 Nov 2005, Thomas Grill wrote:
I'm sorry i don't know gridflow/ruby, but i'd be interested about the fundamental difference between using ruby and Python in the PD context.
I'm sorry I don't know pyext/python, but I think that there aren't really any fundamental differences; just a bunch of small ones due to the fact that we didn't look at each other's work when we started it (especially because the Ruby externals feature started as a jMax-only project several months before I ported it to PureData)
Small differences:
GridFlow allows to create classes directly in pd's main namespace, that is, through the objectmaker receive-symbol. in contrast, with pyext, you go thru [py].
GridFlow writes method names like _0_float while pyext does it like float_1. That is, inlet number is prefixed and 0-based.
GridFlow lacks a damn lot of features of pyext. I don't know about the other way around. Does pyext support definition of GUI objects through t_widgetbehavior ? Because GridFlow/Ruby supports it and I have two or three externals written using it already (though not really debugged, sorry...).
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
GridFlow allows to create classes directly in pd's main namespace, that is, through the objectmaker receive-symbol. in contrast, with pyext, you go thru [py].
Ok, that's interesting... i'll have to look into it
Does pyext support definition of GUI objects through t_widgetbehavior ? Because GridFlow/Ruby supports it and I have two or three externals written using it already (though not really debugged, sorry...).
py/pyext will never support PD GUI objects (from my side at least)
best greetings, Thomas
On Sun, 27 Nov 2005, Thomas Grill wrote:
Does pyext support definition of GUI objects through t_widgetbehavior ? Because GridFlow/Ruby supports it and I have two or three externals written using it already (though not really debugged, sorry...).
py/pyext will never support PD GUI objects (from my side at least)
Oh. Well. I'm going to remove support for them in GridFlow eventually, but that will wait until the new GUI (not using t_widgetbehavior) works well enough that all of my collaborators will have already switched to it... which i hope will be in 2007.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 27, 2005, at 4:54 PM, Thomas Grill wrote:
It would be great to see a working ruby/etc. loader so that we could have some objects written in a scripting language without using a language obj like [py] or [tow]/[widget].
I'm sorry i don't know gridflow/ruby, but i'd be interested about the fundamental difference between using ruby and Python in the PD context.
I guess in your case, I should have said "I'd like to see a working python loader". I just meant a loader that works with a scripting language.
.hc
________________________________________________________________________ ____
Hi David,
Has anyone got any ideas on this? I know Davide Morelli wants (eventually) to create a Lisp interpreter for PD, but I would like to hear thoughts on what the best route for a unified scripting framework for PD could be...if there can be such a thing at all?
what i'm (slowly) working on is an interface between PD and the CLR (common language runtime), also known as .NET or mono. This is a kind of bytecode assembly (related to Java bytecode) which can be targetted from different programming languages, like C#, C++/CLI, Java#, IronPython, VisualBasic, DotLisp. With the associated JIT-Compiler these portable executables can be quite fast, much faster than current Python or ruby, and they can cooperate easily, independently of the source language used. It's forseeable that not all scripting languages will support the CLI (common language infrastructure), but a growing number does.
see: http://en.wikipedia.org/wiki/Common_Language_Runtime http://en.wikipedia.org/wiki/Category:.NET_programming_languages http://www.mono-project.com http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm...
best greetings, Thomas
On 25 Nov 2005, at 11:19, Thomas Grill wrote:
Has anyone got any ideas on this? I know Davide Morelli wants (eventually) to create a Lisp interpreter for PD, but I would like to hear thoughts on what the best route for a unified scripting framework for PD could be...if there can be such a thing at all?
what i'm (slowly) working on is an interface between PD and the CLR (common language runtime), also known as .NET or mono. This is a kind of bytecode assembly (related to Java bytecode) which can be targetted from different programming languages, like C#, C++/CLI, Java#, IronPython, VisualBasic, DotLisp. With the associated JIT-Compiler these portable executables can be quite fast, much faster than current Python or ruby, and they can cooperate easily, independently of the source language used.
That's wonderful. Mono is a very interesting project.
Could you clarify a bit what stage you're at with your CLR project?
Cheers,
David
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Fri, 25 Nov 2005, Thomas Grill wrote:
what i'm (slowly) working on is an interface between PD and the CLR (common language runtime), also known as .NET or mono. This is a kind of bytecode assembly (related to Java bytecode) which can be targetted from different programming languages, like C#, C++/CLI, Java#, IronPython, VisualBasic, DotLisp. With the associated JIT-Compiler these portable executables can be quite fast, much faster than current Python or ruby, and they can cooperate easily, independently of the source language used. It's forseeable that not all scripting languages will support the CLI (common language infrastructure), but a growing number does.
Also, Pascal Gauthier from Montréal has made one for Java/JVM and I'm trying to get him to release his stuff. In particular I want him to present his JNI external at PureData Montréal #15, on December 10.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Am 27.11.2005 um 21:41 schrieb Mathieu Bouchard:
On Fri, 25 Nov 2005, Thomas Grill wrote:
what i'm (slowly) working on is an interface between PD and the CLR (common language runtime), also known as .NET or mono. This is a kind of bytecode assembly (related to Java bytecode) which can be targetted from different programming languages, like C#, C++/CLI, Java#, IronPython, VisualBasic, DotLisp. With the associated JIT-Compiler these portable executables can be quite fast, much faster than current Python or ruby, and they can cooperate easily, independently of the source language used. It's forseeable that not all scripting languages will support the CLI (common language infrastructure), but a growing number does.
Also, Pascal Gauthier from Montréal has made one for Java/JVM and I'm trying to get him to release his stuff. In particular I want him to present his JNI external at PureData Montréal #15, on December 10.
That would be very interesting. Talking about unifying scripting in PD, it's not too hard to imagine that at least JVM and CLR could have exactly the same interface functionality and namings. Is there a web link to Pascal's work?
best greetings, Thomas
On Sun, 27 Nov 2005, Thomas Grill wrote:
That would be very interesting. Talking about unifying scripting in PD, it's not too hard to imagine that at least JVM and CLR could have exactly the same interface functionality and namings. Is there a web link to Pascal's work?
i don't think so. Pascal is really shy about it ;-)
i'll let you find out how to contact him starting with this link:
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
-
David Plans Casal -
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Thomas Grill