All the Perl that's Practical to Extract and Report
use Perl Log In
Alias (5735)
Oz: How not to teach a language
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.
because that's exactly how much difference there is. :-)
--Larry Wall in <10209@jpl-devvax.JPL.NASA.GOV>
the unfamiliar (Score:1)
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: (Score:1)
Any language that forces you to use a particular editor needs to die a slow and painful death.
Re: (Score:2)
Perhaps the rest of the language is more interesting, but I don't see any of that here.
Re: (Score:1)
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: (Score:1)
AI::Prolog (Score:2)
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.
Editor agnostic (Score:1)
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