Comments on: Non-classical paradigms and languages http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/ Samuel Tardieu's dual-sided blog Sun, 06 Jul 2008 06:46:22 +0000 http://wordpress.org/?v=2.3.3 By: Roma http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-64937 Roma Mon, 03 Sep 2007 16:51:31 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-64937 Thanks for the map, I use C++,perl,python for work. IN addition, I also use Erlang for some servers in work. I want to pick up Lisp or something. Factor interests me since it can deliever small application codes and has attibutes found in many modern languages. Thanks for the map, I use C++,perl,python for work.
IN addition, I also use Erlang for some servers in work.
I want to pick up Lisp or something.
Factor interests me since it can deliever small application codes and has attibutes found in many modern languages.

]]> By: Charles http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-35515 Charles Fri, 23 Mar 2007 16:33:55 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-35515 Factor vaut vraiment le détour. De tous les langages que vous citez, c'est le plus prometteur ! Encore bravo pour votre démarche Factor vaut vraiment le détour. De tous les langages que vous citez, c’est le plus prometteur !

Encore bravo pour votre démarche

]]> By: Gabriel http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-35291 Gabriel Thu, 22 Mar 2007 00:12:10 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-35291 Ça se rapproche. Tu commences à avoir une idée de ce à quoi on va avoir droit ? Personnellement, j'aime bien OCaml, mais comme je le connais, ça me plairait justement de découvrir d'autres langages/paradigmes. J a l'air très déroutant et fun, et Factor m'intrigue au plus haut point. Ça se rapproche. Tu commences à avoir une idée de ce à quoi on va avoir droit ?

Personnellement, j’aime bien OCaml, mais comme je le connais, ça me plairait justement de découvrir d’autres langages/paradigmes. J a l’air très déroutant et fun, et Factor m’intrigue au plus haut point.

]]> By: schlenk http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31925 schlenk Sun, 25 Feb 2007 11:18:42 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31925 For many of those topics Tcl might be an interesting choice. It has some weaknesses (no real closures or continuations, but its extremly regular in its syntax and very easy to learn and play with programming constructs). Some interesting pointers: DSLs: http://wiki.tcl.tk/15542 Introspection: http://wiki.tcl.tk/introspection Transforming the language to look like others: http://wiki.tcl.tk/1324 Message Passing based threading (or remote execution): http://wiki.tcl.tk/3447 / http://wiki.tcl.tk/comm Live Code Update is a matter of fact with Tcl, it even works for some dlls...(that support unload). Functional stuff: http://wiki.tcl.tk/9546, http://wiki.tcl.tk/16182 , http://wiki.tcl.tk/fold, http://wiki.tcl.tk/4833, http://wiki.tcl.tk/13844 Some extra Features: Unicode and Encodings done in a good way http://wiki.tcl.tk/515 Safe Interpreters/Sub Interpreters with security policies (sandboxes): http://wiki.tcl.tk/interp Embedding is trivial with Tcl it was made for embedding: http://wiki.tcl.tk/3474 Event based Programming: The Tcl event loop is like Twisted for Python, but built into the language http://wiki.tcl.tk/1527 Tcltest test framework: http://www.tclscripting.com/articles/apr06/article1.html If you want to have OO stuff included, take a look at the XOTcl variant of Tcl (http://www.xotcl.org) which features some very high level OO constructs like pre-/postconditions, method filters, dynamic changes of the superclass hierarchy, mixins, metaclasses and some other goodies. For many of those topics Tcl might be an interesting choice. It has some weaknesses (no real closures or continuations, but its extremly regular in its syntax and very easy to learn and play with programming constructs).

Some interesting pointers:
DSLs: http://wiki.tcl.tk/15542
Introspection: http://wiki.tcl.tk/introspection
Transforming the language to look like others: http://wiki.tcl.tk/1324
Message Passing based threading (or remote execution): http://wiki.tcl.tk/3447 / http://wiki.tcl.tk/comm
Live Code Update is a matter of fact with Tcl, it even works for some dlls…(that support unload).
Functional stuff: http://wiki.tcl.tk/9546, http://wiki.tcl.tk/16182 , http://wiki.tcl.tk/fold, http://wiki.tcl.tk/4833, http://wiki.tcl.tk/13844

Some extra Features:
Unicode and Encodings done in a good way http://wiki.tcl.tk/515
Safe Interpreters/Sub Interpreters with security policies (sandboxes): http://wiki.tcl.tk/interp
Embedding is trivial with Tcl it was made for embedding: http://wiki.tcl.tk/3474
Event based Programming: The Tcl event loop is like Twisted for Python, but built into the language http://wiki.tcl.tk/1527
Tcltest test framework: http://www.tclscripting.com/articles/apr06/article1.html

If you want to have OO stuff included, take a look at the XOTcl variant of Tcl (http://www.xotcl.org) which features some very high level OO constructs like pre-/postconditions, method filters, dynamic changes of the superclass hierarchy, mixins, metaclasses and some other goodies.

]]> By: Yang http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31776 Yang Sat, 24 Feb 2007 07:36:31 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31776 Hi Samuel, will you be teaching this class in English? I (and I'm sure others) would be very interested in taking this class, so if you do the next-best-thing and make the materials available, that would be much appreciated. Hi Samuel, will you be teaching this class in English? I (and I’m sure others) would be very interested in taking this class, so if you do the next-best-thing and make the materials available, that would be much appreciated.

]]> By: Daniel Ehrenberg http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31756 Daniel Ehrenberg Sat, 24 Feb 2007 04:26:12 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31756 Sounds like an interesting course; I almost wish I could take it. As to the issue of Forth vs Factor, I'd recommend both. With Forth, it'd be interesting to discuss the complete lack of types and the direct compilation method. With Factor, it'd be good to cover the unique object system and the very direct correspondance between code and data, even at runtime. Factor also has a lot of interesting properties with respect to its image base, reflection and the sequences library, but those aren't unique among the languages you're covering. Though I'm of course biased, as a Factor programmer. With Scheme vs. Common Lisp, there aren't as many differences. Lisp might be better because of the direct style of writing macros, but Scheme has the advantage of overall simplicity. Usually, I think, people are taught Scheme first. Then again, this doesn't sound like a usual class :) Sounds like an interesting course; I almost wish I could take it.

As to the issue of Forth vs Factor, I’d recommend both. With Forth, it’d be interesting to discuss the complete lack of types and the direct compilation method. With Factor, it’d be good to cover the unique object system and the very direct correspondance between code and data, even at runtime. Factor also has a lot of interesting properties with respect to its image base, reflection and the sequences library, but those aren’t unique among the languages you’re covering. Though I’m of course biased, as a Factor programmer.

With Scheme vs. Common Lisp, there aren’t as many differences. Lisp might be better because of the direct style of writing macros, but Scheme has the advantage of overall simplicity. Usually, I think, people are taught Scheme first. Then again, this doesn’t sound like a usual class :)

]]> By: Cameron Kerr http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31707 Cameron Kerr Fri, 23 Feb 2007 21:49:02 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31707 I did a paper very much like this in my 3rd year of my CS degree (2000). It was titled "Comparitive Programming Languages". I have to say I think it was one of the more useful papers, not because I came away with much of a degree of competency in any language, but because I had a chance to understand different paradigms and their suitability to various applications. Pedagogical note#1: Emphasize application over language fluency. There won't be enough time for the latter, but working on the former will inspire them to learn more. I've found personally that I appreciated functional languages such as Erlang a whole lot more when I found out more about how poorly most languages deal with many CPUs. Pedagogical note#2: I would suggest finding some good documents that stress how the paradigm is applied (such as Google's implementation of MapReduce), as well as looking at how language features (such as lazy evaluation) contribute to solving problems more easily. This paper (13 weeks) had three programming problems, of which each student chose two. Throughout the paper, we covered four paradigms: imperative, logical, functional and object oriented. We used C or Pascal, Prolog, Haskell and Smalltalk respectively, and solved the same two problems in each language. If I were structuring the paper I did back in 2000, I would have removed the imperative component, as students are already quite comfortable in that paradigm. I would replace it with some coverage over the sorts of problems brought about by mainstream languages. I've recently been looking into Erlang, and found Dr Armstrong's (Erlang father) thesis to be very interesting reading. Issues such as concurrency and performance myths are ripe issues here. I wouldn't bother with teaching them a scripting language such as Python, for although it is useful, scripting languages tend to be paradigmatically promiscuous, and are easily learned by the student in their own time. (see note#1 above). I would also look at how you might use particular patterns in each language. IO can throw some curly issues, so it would be prudent to cover basic IO patterns, such as reading from terminal, a file, or network socket. Another thing that needs some attention is how to deal with errors. This necessarily involves at least two facets: interpretation of compiler/interpreter error messages; and dealing with runtime errors. The Erlang thesis I mentioned above has some good ideas here. I hope my experience as a student has been useful to you. I did a paper very much like this in my 3rd year of my CS degree (2000). It was titled “Comparitive Programming Languages”. I have to say I think it was one of the more useful papers, not because I came away with much of a degree of competency in any language, but because I had a chance to understand different paradigms and their suitability to various applications.

Pedagogical note#1: Emphasize application over language fluency. There won’t be enough time for the latter, but working on the former will inspire them to learn more. I’ve found personally that I appreciated functional languages such as Erlang a whole lot more when I found out more about how poorly most languages deal with many CPUs.

Pedagogical note#2: I would suggest finding some good documents that stress how the paradigm is applied (such as Google’s implementation of MapReduce), as well as looking at how language features (such as lazy evaluation) contribute to solving problems more easily.

This paper (13 weeks) had three programming problems, of which each student chose two. Throughout the paper, we covered four paradigms: imperative, logical, functional and object oriented. We used C or Pascal, Prolog, Haskell and Smalltalk respectively, and solved the same two problems in each language.

If I were structuring the paper I did back in 2000, I would have removed the imperative component, as students are already quite comfortable in that paradigm. I would replace it with some coverage over the sorts of problems brought about by mainstream languages. I’ve recently been looking into Erlang, and found Dr Armstrong’s (Erlang father) thesis to be very interesting reading. Issues such as concurrency and performance myths are ripe issues here.

I wouldn’t bother with teaching them a scripting language such as Python, for although it is useful, scripting languages tend to be paradigmatically promiscuous, and are easily learned by the student in their own time. (see note#1 above).

I would also look at how you might use particular patterns in each language. IO can throw some curly issues, so it would be prudent to cover basic IO patterns, such as reading from terminal, a file, or network socket.

Another thing that needs some attention is how to deal with errors. This necessarily involves at least two facets: interpretation of compiler/interpreter error messages; and dealing with runtime errors. The Erlang thesis I mentioned above has some good ideas here.

I hope my experience as a student has been useful to you.

]]> By: Monkeyget http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31704 Monkeyget Fri, 23 Feb 2007 21:33:22 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31704 Oh boy, that's EXACTLY the course I whish i had when i was studying CS. Your students are very lucky (unless you drown them with too many concept they don't have the time to grasp. 60 hours is not that much). Oh boy, that’s EXACTLY the course I whish i had when i was studying CS.
Your students are very lucky (unless you drown them with too many concept they don’t have the time to grasp. 60 hours is not that much).

]]> By: Mat http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31703 Mat Fri, 23 Feb 2007 21:32:06 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31703 Erlang might also be something very interesting to show, because of its very powerful threading model and the use that's made of threads within the language. Especially considering the growing need for ubiquity of multithreading (multiple cores, distributed computing, etc.) It might help your students bring back good ideas about threading to their mainstream language of choice. Instead of starting with the mostly useless and misleading examples that can often be found in these languages' documentation. Erlang might also be something very interesting to show, because of its very powerful threading model and the use that’s made of threads within the language. Especially considering the growing need for ubiquity of multithreading (multiple cores, distributed computing, etc.)

It might help your students bring back good ideas about threading to their mainstream language of choice. Instead of starting with the mostly useless and misleading examples that can often be found in these languages’ documentation.

]]> By: Mat http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31701 Mat Fri, 23 Feb 2007 21:21:45 +0000 http://www.rfc1149.net/blog/2007/02/23/non-classical-paradigms-and-languages/#comment-31701 Ruby might be and interesting choice to show continuations as well as its ubiquitous use of closures (event loops are in fact closures). Its syntax is similar enough to mainstream languages to lower the barrier a great deal. As a bonus, it seems to be getting a great deal of attention lately, which might help spark the interest of your students. DSLs can also be demonstrated with Rails' neat hack where you can call the nonexistent method "sort_by_columnname_and_columnname2" and so on; this triggers a missing method exception. The class defines the handler for this type of exception and then parses the "sort_by" string and match it to the database columns. :-) It might also be used to demonstrate code is data is code is data, too. I'm not exactly sure how that is done, however. I'm not proficient enough with Ruby to remember on the top of my head. Ruby might be and interesting choice to show continuations as well as its ubiquitous use of closures (event loops are in fact closures). Its syntax is similar enough to mainstream languages to lower the barrier a great deal. As a bonus, it seems to be getting a great deal of attention lately, which might help spark the interest of your students.

DSLs can also be demonstrated with Rails’ neat hack where you can call the nonexistent method “sort_by_columnname_and_columnname2″ and so on; this triggers a missing method exception. The class defines the handler for this type of exception and then parses the “sort_by” string and match it to the database columns. :-)

It might also be used to demonstrate code is data is code is data, too. I’m not exactly sure how that is done, however. I’m not proficient enough with Ruby to remember on the top of my head.

]]>