Dr Jekyll & Mr Hyde

24 Responses to “Non-classical paradigms and languages”

1. Stéphane Bortzmeyer Says:
   February 23rd, 2007 at 15:49

   “Creation of domain-specific languages” is under “Parsing, interpretation, compilation” which is very restrictive. It seems to imply that designing and implementing a DSL is mostly an issue of compilation. For embedded DSL, it is clearly false. And even for standalone DSL, there are other things than compiling them.

2. Samuel Tardieu Says:
   February 23rd, 2007 at 15:55

   Stéphane: I put it there because of something Chuck Moore (Forth father) said: “Forth is a useless language as-is; however it lets you build very powerful and useful languages” (or something like that).

   Also, I have not mentioned side-effects nor monads on the list, while they should be there.

3. Daniel Slaney Says:
   February 23rd, 2007 at 17:00

   I’d side with scheme over CL for teaching purposes. It’s small, has good implementations, covers a lot (if not all) the ground you mentioned and has a lot of teaching materials.

4. msw Says:
   February 23rd, 2007 at 17:25

   I love Python - it’s my language of choice for almost all tasks. But I can’t see what pedagogical use it has. It’s a nice implementation of a high-level language, with the best selection 3rd party libraries anywhere, strong unicode support and one of the few thread-safe garbage collectors, but I can’t see why students would particularly care about that.

5. Chris Says:
   February 23rd, 2007 at 17:30

   Don’t underestimate how much of a change of perspective will be required by the students in applying knowledge about programming in C/C++/Java (which, let’s face it, are essentially identical languages when compared to the likes of Lisp, Haskell etc.). I think they’re going to have a very very hard time getting their heads around some very alien concepts.

   Perhaps let the students do some coding in only one or two of these languages (I suggest starting with Python because it has a reasonably similar syntax to the C-like languages, but play up its functional aspects, and then move straight onto Haskell, which has some of the functional stuff in common with Python, but clearly has a diferent syntax and semantics).

   In lectures, demonstrate solutions to some problems that are easy to solve using certain languages features but difficult to solve using others. But don’t expect your students to find it easy to pick up more than the basics of one or two new languages, and certainly don’t expect them to become even half-way competant in the list above!

   The students will probably not enjoy having to change their ideas about what programming is, so don’t be too ambitious.

6. Tet Says:
   February 23rd, 2007 at 17:37

   Forth (or even PostScript) is great for demonstrating stack based languages.

   Erlang I think is probably the nicest introduction to functional programming I’ve come across (and it works in the real world, rather than just being an academic excercise in computer science), and it’s *definitely* the easiest way to show message passing that I’ve come across.

   Python. Well, to be honest, I’m surprised the latter isn’t already covered as one of your mainstream languages. But if not, you *need* to show a modern scripting language, and Python’s a pretty good all rounder there, without the nasty syntax of perl. Ruby might be an alternative here, but I’ve never tried it, so I can’t comment.

7. Phil Crissman Says:
   February 23rd, 2007 at 17:39

   I’d vote for haskell and/or erlang to featured for at least part of the course — not because I like them any better, but because for many CS students, a class like this might be the only time they get a chance to check these languages out.

   Thumbs way up for Scheme and Python as well; I took a class which used both of these, and moving from manipulating lists recursively in Scheme to using list comprehensions is Python was (I thought) a rewarding experience.

8. anatoly Says:
   February 23rd, 2007 at 17:45

   [reproduced from reddit, with permission]

   If it’s given that most of them already know some Lisp… then I would choose Haskell, Smalltalk and either APL or J. The goal should be not just to present the different languages/paradigms, but explore each deeply enough for the students to be able to understand clearly, in their own experience and not just on the teacher’s authority, how those different languages encourage ways of approaching problems that are essentially different from the usual procedural fare, and not just a set of convenient shortcuts and idioms.

   Both Haskell and Smalltalk are as ideologically pure, in their respective ideologies, as possible, presenting clearly the power of their approaches. With Haskell, I would expect only a few of the brightest students to be able to internalise, during the time available the understanding of monads well enough to use them creatively. But everyone can be shown the standard uses of IO, State etc.; and more importantly, they should learn to appreciate algebratic datatypes, type inferencing, closures, currying, and understand how usefully strong really strong static typing is, compared to C++. Actually, it may even be a good idea to look into Clean instead of Haskell and forgo monads altogether.

   With Smalltalk, the goals should be to understand the power of a completely dynamic evolving object hierarchy; to explore object-oriented programming in its most consistent setting; and to realize that a language doesn’t have to be full of warts and exceptions to its primary paradigm in order to be useful “in the real world”. The students should appreciate the beauty of the consistent application of the same abstraction - all the way down to primitives - and how that beauty frees the mind from incident clutter of ad hoc constructions, and leads to wonderfully productive clarity.

   As for APL/J, I know so little of either that it’s just enough to understand that I would (and will) benefit from a better understanding of their approach. Perhaps so would your students.

   If all of these taken together still leave some time, I would try to take the students deeper into Lisp and show them what code=data really can do, and what macros really can do. Nevermind Scheme, they’ll get enough lambda beauty from Haskell; Common Lisp will serve better.

   I don’t like leaving Forth out, but I think that with the time constraints given, there just won’t be enough time to show its real power - only to explain the basic ideas and leave some vague impressions that won’t stick.

9. ChauveSouris Says:
   February 23rd, 2007 at 17:51

   It is so unfair, it is just the type of class I would have liked to have. And I have just been off school. Anyway, just kidding, but don’t forget that last year, the “Compiler Class” did not open as not enough student asked for
   About the langages, it is sure that students must know about python. No question about that, but it does not bring by itself any new concept (it is just a full functionnal and/or object based langage — functionnal or object depending on how you would use it, and yes, it adds lambda function, etc ). You know that I am found of OCaml, and actually, I don’t see any pure ML lanage in your list. Sure you have got Lisp or Scheme, but not Caml. You should consider the fact that an important part of your students may know Caml langage as it is teached in prep’ school, computer science option.
   By the way, PHP is a langage (sorry). I do not like it, but it brings the schema of request answering script. As to Perl, you do not presented Perl, that is probably not a good langage to teach but it represents a langage created for a very specific task (manipulating strings) …

10. costelv Says:
    February 23rd, 2007 at 18:12

    Forth, Scheme, Erlang, Haskell (in that order)

    They should use them solve several real problems.

    Ideally, work on a product, do customer and field support, and make/lose money&sleep&a life, because of good/poor underlying technology.

11. Mike Says:
    February 23rd, 2007 at 18:25

    You might want to take a look at the D programming language. v1.0 was just released at the start of this year and, from what I understand, it’s been in “development” since C++ was born. It’s an improvement on C, with influences from all kinds of languages (like C++, Java, C#, and hell, even VB). It supports everything modern languages do, like OOP and garbage collection, and includes some interesting additions, like integrated unit testing and an integrated documentation system (like JavaDoc). The website explains not only the syntax of the language, but the thoughts behind why they decided to build the language the way they did. The compiler is free to download.

    Wikipedia has a good entry for it as well.

12. Don Dwoske Says:
    February 23rd, 2007 at 18:42

    This is an interesting question.

    I love anatoly’s suggestion and apologia regarding Smalltalk. To extend that, I would also suggest that it’s possible and very useful to construct a similar system/language *from scratch* using Ian Piumarta’s (http://piumarta.com/cv/bio.html) work based on a VPU. He’s got a self-hosting object compiler with which dynamic languages can be built quickly and easily. This technology will be leveraged in Alan Kay’s work in the NSF grant. Ian has created a Smalltalk - like language using his VPU, as well as something like JavaScript.

    http://piumarta.com/papers/EE380-2007-slides.pdf
    http://piumarta.com/papers/albert.pdf
    http://piumarta.com/papers/vpu-vm04.pdf
    http://www.vpri.org/pdf/NSFproposal.pdf

    Perhaps you and your class could help in the NSF endeavor by experimenting with the VPU’s features and applicability. I’m not sure if it’s possible, but creating a functional language using the VPU with Erlang-style message passing would teach you (and your students) a great deal.

    I know only what I’ve read on the web about this, so if you’re interested, follow up with Ian or Alan directly.

13. Paul Says:
    February 23rd, 2007 at 19:03

    Sounds like an exciting class, both for you and for them. As a working programmer who’s always reading, but never had a proper CS education, the languages I have found myself most wanting to learn about are those which have been most influential, even if I’m not going to run out and write deployable software in them.

    If I were going to pick just three languages (and I imagine it would be hard to cover more than three in depth), they’d be (in order): Scheme, Smalltalk, and Haskell.

    Scheme (as a representative of the Lisp family) over CL simply mostly because it’s smaller and cleaner and will be easier to grasp in the limited time available. Smalltalk because as anatoly notes it’s “pure” OO. Haskell (as a representative of FP) because of its purity and density of ideas. Having Haskell last seems fitting because (IMO) it has the busiest and most vibrant community of the three right now, which might help make these “weird” languages seem a bit more relevant.

    I’m stepping over the line here into designing your course, but a faster-paced survey at the end of the course might be a great way to cover odds and ends while showing the influence of your selected core languages/families. This would be a great place to talk about scripting languages — show how Python stole list comprehensions from Haskell; show how Ruby uses Smalltalk-style message passing; etc.

    One language not on your list which might be interesting to incorporate into such a survey is Io (http://iolanguage.com/). It’s a small embeddable language (almost as small as Lua); it uses prototype-based OO, which isn’t covered in your list; it uses Smalltalk-style message passing; and has an interesting concurrency model.

    Good luck, and make sure you post about your final decisions!

14. Grant Says:
    February 23rd, 2007 at 20:09

    Something from the ML family, like OCaml maybe? That’s the other modern functional languague (you already have Haskell on the list). It may be a little more digestible than Haskell since it looks like you’re not going to be able to get too in depth on any particular language.

15. Mat Says:
    February 23rd, 2007 at 22:21

    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.

16. Mat Says:
    February 23rd, 2007 at 22:32

    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.

17. Monkeyget Says:
    February 23rd, 2007 at 22:33

    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).

18. Cameron Kerr Says:
    February 23rd, 2007 at 22:49

    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.

19. Daniel Ehrenberg Says:
    February 24th, 2007 at 5:26

    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

20. Yang Says:
    February 24th, 2007 at 8:36

    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.

21. schlenk Says:
    February 25th, 2007 at 12:18

    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.

22. Gabriel Says:
    March 22nd, 2007 at 1:12

    Ç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.

23. Charles Says:
    March 23rd, 2007 at 17:33

    Factor vaut vraiment le détour. De tous les langages que vous citez, c’est le plus prometteur !

    Encore bravo pour votre démarche

24. Roma Says:
    September 3rd, 2007 at 18:51

    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.

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

Notify me of followup comments via e-mail