Subject:
|
Re: LDraw Animation - Why MPD?
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Thu, 1 Sep 2005 15:34:21 GMT
|
Viewed:
|
5407 times
|
| |
|
|
In lugnet.cad.dev, danny staple <orionrobots@gmail.com> wrote:
>
> On 29/08/05, Damien Guichard <damien.guichard@wanadoo.fr> wrote:
> > In lugnet.cad, Timothy Gould wrote:
> > >
> > > Damien,
> > >
> > > I don't see the advantage in using OCaml over any other language.
> > > Particularly
> > > ones people are more familiar with. Could you outline any advantages is
> > > might
> > > have over, say, Perl (which also has inbuilt strings and memory management).
> > >
> > > Tim
> >
> > (* off-topic discussion *)
> >
> > Design and implementation are not as independant as i wish.
> >
> > As part of the design requirements, i pointed moves should be functions and be
> > as composable as functions are. Practically that means the language must
> > support:
> > 1. anonymous functions
> > 2. closures
> > 3. partial application
> > 4. type inference (Milner's type system)
> >
> > Java doesn't meet any of these requirements.
> > Perl, Python and Ruby may barely meet 2 or 3 of the requirements.
> > Scheme confortably meets 3 of the requirements.
> >
> > The 4 requirements together leave only 3 language candidates:
> > 1. OCaml
> > 2. Haskell (the successor of Miranda)
> > 3. SML (Standard ML)
> >
> > OCaml is by far the most popular of them.
> >
> > Why is a Milner's type system so much needed ?
> >
> > Because of the heavy use of partial application.
> > Partial application means you can't check the number of applied arguments.
> > Thus
> > code is very fragile: forgetting a function argument goes undetected, this
> > leads
> > to code that is clean to read but nightmarish to debug. The solution found by
> > Robert Milner is a stronger typing system known as "Milner's type system".
> >
> > damien
>
>
> I think you may need to explain you choices further. Python supports
> variable numbers of function arguments, as does Perl. In Python it is
> relatively easy to check the types of the arguments, and implement
> overloading and type checking inside a function. In Python you can
> pass around an object containing a function and call it.
>
> Considering that (as you pointed out) animation is mathemetics and
> matrix multiplication - I quote this posting from comp.lang.python:
>
> [QUOTE]
> To create a matrix the OCAML code is
>
> 7 let mkmatrix rows cols =
> 8 let count = ref 1 and last_col = cols - 1
> 9 and m = Array.make_matrix rows cols 0 in
> 10 for i = 0 to rows - 1 do
> 11 let mi = m.(i) in
> 12 for j = 0 to last_col do mi.(j) <- !count; incr count done;
> 13 done;
>
> In Python with Numeric it's just
>
> x = zeros([nrow,ncol],Float)
> [/QUOTE]
>
> OCaml is not a widely used, or recognised language - and asking people
> to learn something that is even more esoteric than Perl would be a
> complete turn off. Popular is not a word I would associate with it at
> all. My point about usability is even stronger - when you use an
> obscure language, most developers wouldnt even touch it, let alone the
> end users. Please dont make something so over the top - Lego is
> simple, and easy to use - and so should any tools built to work with
> it be simple and readable.
>
> Dont get me wrong - I like the idea of embedding a nice, scriptable,
> object oriented, readable and high-level language so that complex
> animations using mathematical functions could be created. But I
> strongly feel the OCaml is not the way to do it, its not as readable
> as other languages - and going into Milner is just not necessary.
>
> OrionRobots
(* off-topic discussion *)
To create a matrix the OCaml code is:
let x = Array.make_matrix nrow ncol 0.0
I acknowledge:
* OCaml is not widely used
* even more esoteric than Perl would be a complete turn off
* popular is not a word I would associate with OCaml (other than relativily to
Haskell)
* OCaml is obscure (assuming the average user is not familiar with
lambda-calculus)
I even add my own comment to the mix:
* OCaml sucks as an OOP language
These are facts and i won't deny.
Now why would i stick to OCaml?
I have read the thread "Lego CAD systems infuriating?" and it convinced me
usability is a user-concern. Users are zappers, they try and zap, try something
else and zap again in the vain hope that "Just imagine...", "Plug & Play", "Just
do it" are more than slogans.
There IS a barrier for CAD and animation. Whatever low the barrier it will be
too high anyway.
OCaml is a full-fledged functional language, and that's what i need.
Paste the 6 following lines in your OCaml top-level (this is the
implementation), there are a bunch of nonsense definitions:
let to_the () = ();;
let walk_minifig () () = ();;
let drive_car () () = ();;
let mario = ();;
let mario_car = ();;
let grocery_store = ();;
Now paste the 2 following lines (this is the end-user command) in the top-level:
(walk_minifig mario (to_the mario_car));
(drive_car mario_car (to_the grocery_store));;
The text is valid OCaml and executes nicely.
Suddenly what was an obscure OCaml implementation seems much like a natural
language interface.
What programming tricks i would use to derivate the animation from the user
command is my business, not the user concern.
My plan is to go bottom-up, to progress seamlessly from math concepts to natural
concepts. The first prototype would be inaccessible for the average lego
builder. But, incrementally, as more and more layers would be added, the command
line would be more and more pleasant to use. At the upper level the commands
would be usable both as a user command line tool and as a load/save text format
for a point-and-click interface.
We have the same usability goal, just you concentrate first on the interface, i
concentrate first on the implementation.
I don't see how "walk_minifig" and "drive_car" could be implemented.
Because they certainly need concepts i have not yet developped.
Probably they are just gimmicks and other commands will reveal more appropriate.
What is important is that the final user syntax will be readeable and
user-friendly. That is a long-term goal, the more abstract layers are added, the
less skills required for scripting:
* the lowest implementation level would be a quite stable animation engine
* above it would be generic animation commands
* above them would be domain-specific animation commands
The strength of OCaml is all user/developper levels would use the same language
that will seamlessly connect thus allowing incremental improvements.
The feedback would be straightforward:
* changes in the implementation would surface as improvements in the upper level
commands
* user requests would drive adjustments in the lower level commands
* as they progress advanced users would seamlessly become implementers
Having XML for datas and Python for commands would be having two languages, that
is playing Dr. XML & Mr. Python and separating the users from the implementers.
So when users would explain me why my tool is not useable i could answer "Just
do it".
Moreover i am not an OCaml believer, i have used Scheme, Smalltalk and Eiffel
previously and i know how "cutting-edge" technology can be misleading. So let me
assume the implementation failure before i can assume the interface failure.
Having a working implementation would already be a huge success for me.
damien
my lego web page: http://perso.wanadoo.fr/alphablock/
|
|
Message is in Reply To:
 | | Re: LDraw Animation - Why MPD?
|
| (...) I think you may need to explain you choices further. Python supports variable numbers of function arguments, as does Perl. In Python it is relatively easy to check the types of the arguments, and implement overloading and type checking inside (...) (19 years ago, 30-Aug-05, to lugnet.cad.dev)
|
61 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
