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.

curlgen with Ruby Rails: Mime::Type.register and response.rb

I took some time today to try to see what is happening with default MIME content_type over at lighthouseapp.com

But I am still at sea ...

In the meantime, the Rails code states that we must not use the Response class itself. So what to do if you want to change a default MIME type across a site. For example, the default in the Mailer is 'text/plain'. And in the Response class there is a method

   def assign_default_content_type_and_charset!
      self.content_type ||= Mime::HTML

which is immediately called by

  def prepare!
    assign_default_content_type_and_charset!
    handle_conditional_get!
    set_content_length!

The first thing was to track down the Mime module in action_controller where you can see that your type may be missing (mine was.)

So now I might start the effort to convert to non-HTML web content as site output with

    Mime::Type.register "text/vnd.curl", :curl

The Mime module has a class Type (yes, I know, but so it is) and that has a static
   @@html_types = Set.new [:html, :all]
Note that it is not
  @@markup_types

Of course, it might be easier just to go into the Response class and have it set its default to the Mime::Type class static default.

But should it really be necessary to repair and modify these classes to achieve something so obvious as the default MIME Content-Type for an HTTP web framework?

That's where the hope lies with Rails 3.  But Rails 3 will be a marriage with merb and there will have to be compromises. But we should be able to hope that hard-coding the MIME defaults will be a thing of the past.

Of course for individual controllers you can go piecemeal with

  class MyApplicationController < ActionController::Base



    before_filter :set_content_type
    def set_content_type
     @headers["Content-Type"] = "text/vnd.curl; charset=utf-8"
    end
  end
 
but then you are faced with tracking down just how much of ApplicationController you must override. For example,
 
  def record_not_found
    render :text => "404 Not Found", :status => 404
  end
 
must become something like
 
  def record_not_found
    render :text => myApp.msg_404, :content_type => 'text/vnd.curl' :status => 404
  end

If you are aware of how Rails on ruby 1.8.6 can globally alter the Response content_type, please add a comment.  I don't see the answer over in the Rack module where you will find hard-coded

      @header = Utils::HeaderHash.new({"Content-Type" => "text/html"}.merge(header))

Oops.

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

Ruby 1.9.1 on Windows after 1.8.6

I came back to Ruby on Windows the other day after working on a linux box and did not want not be in Cygwin. So I hopped out to ruby-lang.org and pulled in the Windows 1.9.1 binaries. Then I flipped my ruby env variable to point to the new directory so that my path - which uses %ruby%\bin - would update. Then I called gem to install Treetop for PEG and ... Segmentation fault. Oh joy.

I saw that 1.8.6 has a one-click installer for Windows, so I used that, flipped the ruby var and presto all was well.

So why not with the 1.9.1 zip install? Well, ruby for windows XP is not really Ruby for windows so much as it is Ruby for Gnu on Windows. What was missing in the path were Win32 versions of linux DLL's - specifically:
gdbm.dll
libeay32.dll
pdcurses.dll
readline.dll
zlib.dll

The quickest fix was to copy them from the 1.8.6 \bin into the 1.9.1 \bin

So if you start ruby or irb or gem on Windows and hit a Segmentation fault error, this may be the only issue.

You may avoid this issue if you build ruby from source .. but the point of running Ruby on a Windows box outside of Cygwin or Msys is usually to either try something out or get something done - not to do development work. And after all, Ruby is supposed to be at least one notch above its file-based and cmd-line cousin, Gnu Smalltalk, right? Or why else is Ruby seeing so much use on the server-side? Of course if Ruby were to displace that other Smalltalk-descendant, Objective-C, on the iPhone we would be running RIGS for GnuStep anyway ...

Btw, there is Cocotron for that other pseudo-Smalltalk on Windows ...

PS
The DLL's can also be found here.