Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Friday April 20, 2007
06:33 AM

Oz: How not to teach a language

[ #33044 ]

I'm currently working on a project that has a scheduling element to it.

While I admit I dislike learning new languages, this is mostly for practical reasons. I don't like having to start from scratch on a new language, so I can solve the same problems I can already solve in a language I know.

But I'm smart enough to know when a problem has Perl beaten, so I've been looking for a way to write my scheduler. Prolog looked like the easiest way, and AI::Prolog already exists, so integration with Perl would be trivial.

After talking to a few people, jjore came back with a complete program to solve my sample schedule in a language I'd never heard of, called Oz.

The code is remarkably legible, and I can see how I'd be able to extend it in the ways I'll need down the track, and the codegen required looks like it should be simple enough.

So I'm looking into learning some Oz basics.

Installation was a breeze. apt-get install mozart on debian, and a downloadable installer on Windows. So things are looking good, and all the clues of sanity are there.

Until I hit the tutorial...

Because I have to say, Oz has the most horrid tutorial introduction I've ever seen.

After spruiking the language in the introduction, it suggests to run the "oz" interactive programming environment.

So I run it... to be faced with what is a modified EMacs editor with extra integrated stuff, and that spawns off Tk windows for some tasks. I'm completely lost, I don't even know how to quit, and eventually kill the terminal in disgust.

In fact, the entire first three or four sections of the official tutorial are written based on the assumption you are an competent EMacs user.

So ok, I'll just use the compiler to manually build things and execute them instead.

Except the programs in the tutorial don't work!!!

Take their "look how simple hello world is in Oz" example.

{Show "Hello World!"}

Simple enough... except that not only isn't that a legal standalone program, but "Show" is a command built into the editing environment! :(

2 hours later, after skimming through the entire tutorial to try and find clues, I get something that will actually compile, execute and print out Hello World, it turns out hello world ACTUALLY looks something like this.

functor
    import
        Application
        System
    define
        {System.showInfo "Hello World!"}
        {Application.exit 0}
end

This looks NOTHING like the example provided in the tutorial.

If swear to god if I didn't need a constraint language for this scheduling code I'd have junked this language in disgust, never to look at it again.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Don't you think a lot of that is probably frustration due to being unfamiliar with how things are done in this new environment?

    It does look interesting at first glance, in any case. Thanks for the pointer.

    • Being forced to use EMacs is not "a new environment", it's having religion imposed on you.

      Any language that forces you to use a particular editor needs to die a slow and painful death.
    • It does look interesting at first glance, in any case.
      Well, just looking at the Hello World program, I see nothing at all that even remotely peeks my interest. It looks like just more of the same old cruft.

      Perhaps the rest of the language is more interesting, but I don't see any of that here.
      • You don't want Oz as a general purpose language. Its no good at that. You want it because it has nice ergonomics for constraint solving, parallelizing execution across computers, or perhaps something about it being a data-flow driven language.

        Perl isn't good at any of those. I don't know ofa nice thunking layer between Perl and Oz so maybe I'd want to just use Perl's glue-language capabilities to write Oz code and scrape the output as it came back.

        I'm a rank Oz novice though.
        • I don't know what being a data-flow driven language buys you, fwiw. Lazy execution, sure. Whether that's something to make me want to move code into Oz or not... I have no idea why I'd do that right now.
  • As much as I hate to say it, I'm glad you didn't go with AI::Prolog. Scheduling problems (as with any search algorithm) are generally heavily recursive and AI::Prolog probably would have killed any hope you had of having a fast system.

  • For what its worth, I write Oz in Emacs but don't use the integrated thing much. I do have X handy which is nice for those popups though. There's also printing stuff to STDOUT if you've no X.

    A compile -> run command looks like this:

    ozc -c program.oz && ozengine program.ozf

    A compile -> debug command looks like this and it requires a GUI. The debugger mostly sucks though.

    ozc -g -c program.oz && ozd program.ozf