Seven Languages and a few questions

Pragmatic Programmer has published Bruce Tate's Seven Languages.  I have some reservations.

The languages are Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby.  Looks cool.  But look again.

Clojure is something of a Lisp reincarnate.  Io and Ruby are botrh Smalltalk in another guise: Ruby is Smalltalk in files à la Perl; Dekorte's Io is Smalltalk-2 (Self) + actor (but not morphic - for which see one brand of Squeak Smalltalk.)

Erlang is best understood as Prolog reduced.  So what would have been beyond 1974 Prolog? Oz.  Or Mercury.  Or XSB.  Or think outside the box with a chapter on Logtalk instead.

Scala Traits come from Squeak Smalltalk, btw.

I have no quarrel with Haskell being there, though some would argue for OCaml.

But if LISP is not there, what is Prolog doing there?  Why not JESS or Drools instead?  And not a single expression-based language (Rebol, ICON/UNICON ( and now ObjectIcon and Converge) or MIT Curl, the language (ww.curl.com.)

With Ruby there, we at least have a reminder that performance matters - so maybe it should have been JRuby.  But I can imagine how Pythonists might feel incensed.

I would suggest 12 languages in 12 months or 3 languages in 3 months.

Take a moment to look at the comments on the Prolog N-Queens code.  Is Tate claiming that the two files in question are his copyrighted code?  Compare the ICON code for N-Queens and ask whether you wouldn't be better looking there for an alternative language on your shelf.  And Rebol 3 is really starting to take shape over at Rebol.net, Rebol.org and Rebol.com

Most CS folks recall the course in which they were required to do some Prolog.  But would they skip a chapter on JESS or Logtalk?

The real story in Prolog in the past 25 years is constraint resolution, and that can be seen best in Oz.  But the reader will have to use emacs.  Oops.

I don't mean to knock Amzi! Prolog for Eclipse or many of the excellent Prolog projects such as swi-prolog.org (now with UNICODE and constraint-handling rules) but I would argue that what makes SWI interesting is Logtalk - and if there is RDF in the picture, that points to XSB.

Clojure, Haskell, Io, XSB, Scala, Erlang, JESS and JRuby in 8 weeks.  Ok, now I'm more likely to recommend a book.

"Clojure, F#, Io, Oz, Scala, Erlang, and JRuby in 7 months".  Call it "between vacations reading-and-testing-and-coding-and-designing".  And you would have my attention.

And whatever became of Tcl ( it only gave us Tk, Expect, Sqlite and now TclOO.)  Oops.

Oh, and Mercury now generates Erlang in addition to C or Java.

PS
Isn't concurrency coming to UNICON?  Isn't Oz now distributed Oz?  Isn't ObjectIcon at code.google.com/p/objecticon
Oh - right.  The cool factor.  And Smalltalk itself - after giving us so much and then the RefactoringBrowser and then UnitTest and pair-programming and eXtreme Programming and the wiki at c2.com ... is not yet cool again.  Might as well wait for Hermes2 on a non-Linux OS.
Oh - and Rebol is already PEG-equivalent at 300+ Kb core running with a claim to a whole 15 Mb of working memory.  Hmmm.

Aules evolve

Over at my Aule blog I have a post on evolving an Aule as a "home page" - but one that it is with me and not at Yahoo or Google or AOL.

For some time it has been my habit to set the browser home page to a file on my PC or netbook by using an address bar entry of

file:///c:/webpages/home.html

or

file:///home/grs/websites/home.html

but those should soon go to being

aule.html

or

aule.curl

or

aule.dcurl

as Aules evolve towards being user-defined entry points with access to

remote-astronomy_aule.html

and such.  I had hoped to use a variant of Seaside for Smalltalk to generate these "pages" and another   Squeak Smalltalk framework to make them both portable and persistent.  I am now leading more towards using Robert Parlett's new variation on the Icon language and its libraries as ObjectIcon.  And in time there may be Laurie Tratt's Converge.

Two largely ignored programming options still hold my interest: the Logtalk framework for Prolog (swi-prolog is both constraint and RDF-friendly) and Oz (rules, constraints, dataflows ... )

As Smalltalkers know, it is not just the language, it is the environment, the established patterns - and the ease of testing and debugging.  I will still keep an eye on Seaside for Pharo Smalltalk and watch for Dolphin+Lesser's NG Smalltalk.  But an Aule layout keeps coming back to being a structured String specification to be parsed, persisted and built.  Rebol3 looks to be mired-down (the latest distraction for Carl Sassenrath is running his alpha on an Amiga before that alpha has stumbled into a first beta.  Oh vey ... ) and don't hold your breath for an environment.

Parsing in Icon is almost as fine as in Rebol - and there remains in my back pocket the Qtk for Oz.

No option will be as elegant as a declarative Curl UI in a web page - so they will continue - but as an option.  My next iterations are for Tcl and Ruby links over at logiquewerks.com because the Tcl aule (entry point, home page, portal, mashup) must itself evolve as Tcl 8.6 and TclOO become old-hat.  And Ruby may yet get cleaned up.  And then Java 7 and a VisualWorks 8.  And oh yes - a Rebol 3.

Python + Tkinter and Python + Gtk

Remembering that Python was intended as a scripting language, compare these two HelloWorld from Python.

First, Tkinter for Tk as in Tcl/Tk

from Tkinter import *
root = Tk()

class HelloWorld:

def __init__(self):
  widget = Button(root, text = 'Hello World', command = self.quit)
  widget.pack()

def quit(self):

  print "Hello World"

  import sys

  sys.exit()

HelloWorld()
root.mainloop()

Now to compare the same minimal HelloWorld with Gtk.  First, install Gtk+  ( and on Windows XP  that means get all of the dependencies - the DLL's - on the path.)

import pygtk
pygtk.require('2.0')
import gtk

class HelloWorld:
def hello(self, widget, data=None):
print "Hello World"

def delete_event(self, widget, event, data=None):
print "delete event occurred"
return False

def destroy(self, widget, data=None):
   gtk.main_quit()

def __init__(self):
   self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
   self.window.connect("delete_event", self.delete_event)
   self.window.connect("destroy", self.destroy)
   self.window.set_border_width(10)
   self.button = gtk.Button("Hello World")
   self.button.connect("clicked", self.hello, None)
   self.button.connect_object("clicked", gtk.Widget.destroy, self.window)
   self.window.add(self.button)
   self.button.show()
   self.window.show()

def main(self):
   gtk.main()

if __name__ == "__main__":
    hello = HelloWorld()
    hello.main()

Whatever the merits of Gtk+ as a cross-platform C GUI framework for general purpose languages, something looks to have gone wrong with the Python library PyGtk.

Even with Tk itself, something comparable occurs when using Tk from Haskell versus using Tk from OCaml.  Probably  expect was the Tcl "killer app" but Tk is what most developers know of Tcl today.  Tk was also an early mainstay of Ruby.  Here is the HelloWorld demo using Gtk+ from the Ruby-Gnome team:

# Copyright (c) 2002,2003 Ruby-GNOME2 Project Team
require 'gtk2'

button = Gtk::Button.new("Hello World")
button.signal_connect("clicked") {
    puts "Hello World"
}

window = Gtk::Window.new
window.signal_connect("delete_event") {
    puts "delete event occurred"
#true
   false
}

window.signal_connect("destroy") {
   puts "destroy event occurred"
   Gtk.main_quit
}

window.border_width = 10
window.add(button)
window.show_all

Gtk.main

Now this is a little better, but compared to Ruby + Tk we are at almost double the lines of code.

To see a really elegant use of Tk, see the QTk framework for Oz, the language.  I'm fiddling with a QCurl variant for Oz just now.  I added some notes on OCaml and labltk over at wikia.com

From Oz QTk to QHTML to QCurl

The QTk framework for the Oz programming language provides a mixed declarative and procedural approach to generating a GUI using Tk. Since the appearance of QTk, the QHTML framework appeared first as a research report and then in the SCM for Oz.

In going through the QHTML Oz code it became apparent almost immediately that transitioning QHTML to QCurl would be even less problematic than my current efforts with Smalltalk Seaside for Curl.

A QCurl framework should address one or two challenges that faced QHTML and move closer to a framework involving the fewest number of disjoint languages: in this case, only Oz and Curl. With Oz on the server-side and Curl on the client-side we have a mixed declarative-functional-procedural language on each end, plus the advantage of Curl macros. With the Curl JIT compiler producing native code and consuming declarative Curl as a data format, Oz can expect excellent performance with an alternative to HTML+JavaScript+CSS while also not being restricted to the web browser as the GUI container.

a note on Polymorphism in Rebol and Oz

I have put a page on Polymorphism in Rebol and Oz with some mention of Strongtalk at eclectic-pencil

It really does not do justice to the richness of Rebol and may presuppose some familiarity with Smalltalk. All are available as freeware on the web.

If you work in JavaScript or C# there will be a lot to interest you in the trio of Oz, Strongtalk and Rebol. TiScript, for example, is a JavaScript variant which rejects prototype-based in favor of simple modules.
If you are looking at the new languages coming available for .NET and VisualStudio and want to see multi-paradigm programming then Oz is the place to start.
If you find you don't quite get Oz and the whole Emacs thing, start with Rebol.
If you don't want another way to think about web programming, just an alternative to JavaScript+CSS+HTML+whatever, download the Curl RTE and IDE.
I had been almost sold on XUL + JavaScript or XAML + C# and then I took a look at both Rebol and Curl.
In the next few days I will post something on the beauty of "Quick" Tk in Oz. If you were ever taken with Logtalk+Prolog or Datalog+RDF you will appreciate td(...) and lr( ...) as td( lr( ... )) i.e. layout of widgets is top-down and left-right...

QTk scripting in Oz/Mozart

The relative neglect of oz/mozart compared to say, Scala, has an explanation.

Part of it must lie in the needless snags along the learning curve. Steep is fine; jagged bits, less so.

There is no learning Oz/Mozart without embracing their emacs mode. And tolerating their tutorial.

Do not begin with applications. An application will require at least one 'functor'.

Ignore the bits that say you are compiling. You are not. No tutorial code will compile. Just do as you are told (follow the instructions) and 'feed' in a line. Or 'feed' in a region. Or 'feed' in a buffer.

What they mean is pass a line, a selection or the file through the interpreter only.

Think of it as scripting in Oz/Mozart. Now you can open a window with widgets using an few lines of Qtk.

No language which interfaces to Tk should be hampered by such a tutorial or such documentation; the usual answer is to buy the somewhat pricey MIT book by Peter van Roy.

Try to understand that the people who are assessing the need to revise the on-line documentation already know oz/Mozart inside-out and cannot 'see' the bits that say 'compile' when nothing compiled at all. They think you know what they mean by 'pickle' and that you get the 'functor' jibe at Prolog. A module is a module. Sometimes in some language a class is just a module. And writing a fine tutorial is an art. If you can get the video intro to Revolution/Transcript/MetaCard to run under Windows using the required QT codec, you may actually see what I mean.

But hey, you could not script the Oz/Qtk way in C. The fact that it looks easier in Jython may be that you know java and python. But it is easier in Tcl/Tk wish. So the point must be what can be achieved in oz/Mozart and that may be as much as can be achieved with Scala and then some.

Watch this blog for a link to a tutorial and a concordance/commentary to their friendly-looking documentation. And just accept that all you need to know is in the oz/Mozart maillist.

Somewhere in oz, climbing a cliff on the way to the corner store.

Note: do try the QTk Prototyper.  The tutorial leaves out one essential: declare the Prototyper, as in

 declare Prototyper

[Prototyper]={Module.link ["x-oz://system/wp/Prototyper.ozf"]}

{Prototyper.run}