Feeds:
Posts
Comments

Archive for May, 2007

Seaside or HaXe?

Posted in Web Development on May 25, 2007| 5 Comments »

Recently, I decided there was something of a hole in my programming toolbox – a good tool to develop websites. Now I want to change that so I have a number of options. I’ll group them into three main categories.

  1. Choose a framework that works for one of the languages I know already, e.g. Catalyst
  2. Choose a framework for another language, e.g. Rails or Django
  3. Choose a tool that is specifically designed for the web, e.g. Seaside, GWT or HaXe

For various reasons, I like option 3, and as I’m not interested in Java, it comes down to a choice between Squeak/Seaside or HaXe. This puts me in the unenviable position of making a choice between two technologies I know almost nothing about. Let me try and enumerate the pros and cons that I’m aware of at my superficial level of understanding.

Seaside positives

  • HTML/CSS generation using Smalltalk only
  • Better debugging
  • Image development – install pain is a thing of the past

Seaside negatives

  • Squeak is difficult to integrate with C.
  • Documentation is not as good as HaXe

HaXe positives

  • Language looks more familiar
  • Relatively bigger community
  • There is going to be a book available soon
  • Seems to be improving rapidly (in comparison with Seaside)
  • Integrates with C

HaXe negatives

  • You still need to write HTML/CSS (I think)
  • Not quite so easy to install

The big points here are obviously the integrates with C – e.g. if I want to use a Sqlite (ignoring the single-threaded blocking FFI version) or Sybase library then I have a lot of work to do. On the other hand:

  • I’m not sure I’ll ever need that functionality
  • even if I do, there are ways around it.
  • I love the idea of not writing HTML/CSS directly.

I think I’m going to go with Seaside and keep HaXe as backup.

Update: Looks like you do still need to know/write some amount of CSS which weakens my primary reason for choosing Seaside over HaXe.

Read Full Post »

The tools in my programming toolbox

Posted in Uncategorized on May 18, 2007| Leave a Comment »

It is probably worth enumerating which technologies I am familiar with so I can determine if I need to concentrate on any obvious deficits or if I could substitute a mediocre tool with a superior one. I will only talk about languages here.

C++ is my main enterprise statically-typed language. I have used it for a number of years and I am very comfortable with it. The main alternatives (as I would need something that I could easily get paid for) are Java and C#. However, there is a huge barrier for me to consider either as it would take me so long to get to the same level. If it wasn’t for needing to get paid, perhaps Ada, Eiffel or D would be reasonable substitutes for C++, Java or C#.

Perl is my primary scripting language and I’ve been using it for both ad-hoc tasks and small to medium projects as required at work since the 90s. Again, I’m not really interested in a direct competitor to Perl at the moment because of familiarity and also because neither Ruby nor Python provide any compelling advantages.

Unix, shell and related utilities are another ‘language tool’ that I use frequently. I can’t think of a competitor at the moment, but that might be due to limited imagination on my part. I should briefly mention a couple of other languages I use at work: ELisp and SQL but again I can’t think of any alternatives.

Outside of work, I have a much greater flexibility in choosing a language to do a project and so far I have chosen Scheme. MzScheme provides a nice native GUI on Windows built on a solid, relatively performant, strong & dynamically typed, garbage collected language.

For the past few months, Chicken Scheme has been my tool of choice for delivering native executables on Windows. I chose it initially because of the excellent FFI and theoretical portability of the code. However, I could be looking for something else, as it doesn’t work on Windows Vista.

I have invested a fair amount of time in scheme, but of all the languages I use, it is the most likely to be replaced. Python with WxWindows could probably handle many of the small scripts I whip up in MzScheme. I’ve often wanted to give Ocaml a proper whirl too, but perhaps library availability on Windows will be limiting.

Conspicious by its absence, is a good tool for developing Web applications. Ideally, I would like something open, portable and easy to install and to me, Squeak and Haxe both stand out as options here.

Read Full Post »

A Basic Transcripter in PLT Scheme

Posted in Scheme on May 3, 2007| Leave a Comment »

PLT Scheme provides a graphical toolkit for implementing GUIs called MrEd. At least on Windows, the result looks like a native application and was used to implement the IDE, DrScheme. As usual, the documentation is excellent.

When an application is running, it can be useful for it to output diagnostics that report on what it is currently doing, e.g. which database it connected to, or the id of a transaction that may have failed. This is normally output to a file, but it can also copy the output to a logging window, e.g. the Transcripter in Squeak, or the Java Web Start Console. How easy is it to implement a simple transcripter in PLT Scheme?

As usual, it is a good idea to decide on your API first as encapsulating everything behind an API means that we can easily change the implementation later on. I will simply provide a function (log s) where s is a string but you would probably want to have various logging levels which can be enabled or disabled at runtime.

(require (lib "42.ss" "srfi"))

;; First of all, create a text area inside a window (frame)

(define *frame* (instantiate frame% ("Transcript")))

(define *text* (instantiate text-field% ()
                 (label "")
                 (style '(multiple))
                 (parent *frame*)))

;; We need the editor belonging to the text area in order to append text to it

(define *editor* (send *text* get-editor))

;; The 'API' for accessing the Transcripter
;; This is a somewhat unrealistic implementation, but good enough for a quick example
(define (log s) (send *editor* insert s))

;; A test method, displaying 200 numbers on the transcripter
;; - this is the same as we did in Squeak

(define (200-nums)
  (time
   (do-ec (:range i 1 201)
          (log (string-append (number->string i) "n")))))

(instantiate button% ()
  (label "Execute")
  (parent *frame*)
  (callback (lambda (button event)
              (200-nums))))

(send *frame* show #t)

A couple of things. First of all, performance: When I ran this initially, the display numbers test took ~60ms. However, when I expanded the Transcripter window to a reasonable size, it took ~2000ms (2 seconds!) When I retried the same in Squeak it took around 5700ms although I’m certain it had earlier taken more than 10 seconds. This is a different computer and a different image but maybe the Squeak Transcripter isn’t so bad after all.

Secondly, it was fairly straight-forward to construct the GUI. Of course, such a simple example doesn’t really give any idea how hard it is to use MrEd to create moderately complex GUIs, but the existence of DrScheme indicates that it is at least possible.

Read Full Post »