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.
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.
Re:the unfamiliar
Alias on 2007-04-20T13:10:10
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.
Re:the unfamiliar
bart on 2007-04-20T19:23:58
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.Re:the unfamiliar
jjore on 2007-04-20T21:06:59
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.Re:the unfamiliar
jjore on 2007-04-20T21:08:15
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.
