Cross-language prototypes
Author
Do any of you write prototypes of algorithms in a language, then implement the actual algorithm in another?
Do you have any tips about how to make the process less boring or repetitive?
I'm currently translating a constraint-solving algorithm from Objective Caml into PHP (quite different languages).
I haven't written many programs, but I always write a prototype in a high-level language such as Basic so I can test it at an early stage without having to write out as much code (= more potential for bugs) as in a lower-level language. I can't really think how to make the process less boring or repetitive without using an automatic translator, which isn't always available for your chosen pair of languages. Even then, the resulting code is likely to be highly unoptimized.
I find that the boredom and repetition largely go away when you let the prototype language be much higher level than the implementation language. (Unless you count the boredom and repetition involved in dealing with design patterns in the low-level implementation language [wink])
I'll implement algorithms and new structures in higher-level languages so I can test out and play with the constraints and the functionality before I move to lower-level ones. So, I typically start in Smalltalk, Lua, or PHP (depending on needs and target) before moving on to O'Caml or C.
However, for software I'll start with the target framework and language. I only use the two-step process for new components I want to create.
Also, I'm working on implementing a Smalltalk system with a native-level compiler and a self-teaching hintable optimization system, so that even an obscenely high-level language like Smalltalk can be just as powerful as any modern VM-based system (ie CLI). Maybe even a Smalltalk compiler that produces CLI code will come out of it.
It's hardly unique, but it's extremely educational.
However, for software I'll start with the target framework and language. I only use the two-step process for new components I want to create.
Also, I'm working on implementing a Smalltalk system with a native-level compiler and a self-teaching hintable optimization system, so that even an obscenely high-level language like Smalltalk can be just as powerful as any modern VM-based system (ie CLI). Maybe even a Smalltalk compiler that produces CLI code will come out of it.
It's hardly unique, but it's extremely educational.
I find it easiest to start with the language I'm going to use the algorithm in. Translating code between languages is as much of a pain as writing the same texture-loading code twice.
Author
Quote:Original post by Zahlman
I find that the boredom and repetition largely go away when you let the prototype language be much higher level than the implementation language. (Unless you count the boredom and repetition involved in dealing with design patterns in the low-level implementation language [wink])
Well, actually, the fun part of programming a new algorithm is the design and tweaking portion. Once the layout is known and the various constants and factors have been optimized, there is little left to invention, and everything left to writing. Which is boring.
Quote:Original post by
I'll implement algorithms and new structures in higher-level languages so I can test out and play with the constraints and the functionality before I move to lower-level ones. So, I typically start in Smalltalk, Lua, or PHP (depending on needs and target) before moving on to O'Caml or C.
For me, it's the other way around: I find PHP to be more awkward than O'Caml, and also much easier to get something wrong done with it. Writing PHP code is a constant fight between getting something done and doing it in a way that does not contain 10 bugs, is not unreadable or utterly inefficient, and is still understandable two hours from now when I read the code again.
On the other hand, I never write any bugs in O'Caml that are not immediately caught by the compiler (although the algorithm itself may be flawed), and I'm able to read unindented O'Caml code without any syntax highlighting or thought-out layout at a relatively fast pace, so normally indented/highlighted code is not as much of a problem as it would be in PHP.
Quote:Original post by Anonymous Poster
I find it easiest to start with the language I'm going to use the algorithm in. Translating code between languages is as much of a pain as writing the same texture-loading code twice.
It's true, but somehow I feel that writing this particular 200-line algorithm in PHP from scratch would have taken around 800 lines, and would have required refactoring in the end anyway. Not to mention that PHP is more difficult to tweak-and-run than OCaml.
I don't usually code prototypes. I typically use a whiteboard for very high-level prototyping, and then describe the solution in a DSL, based on the prototype. Then all I have to do is to implement the DSL, in OCaml whenever possible.
In this particular case though, I can't think of an easy solution to make the task less boring, sorry. Have you considered reimplementing the algorithm in a very high level, stricter than PHP, simplistic language that you could then compile to PHP? Just thinking out loud.
I'm with you there.
Hope this helps.
In this particular case though, I can't think of an easy solution to make the task less boring, sorry. Have you considered reimplementing the algorithm in a very high level, stricter than PHP, simplistic language that you could then compile to PHP? Just thinking out loud.
Quote:Original post by ToohrVyk
For me, it's the other way around: I find PHP to be more awkward than O'Caml, and also much easier to get something wrong done with it. Writing PHP code is a constant fight between getting something done and doing it in a way that does not contain 10 bugs, is not unreadable or utterly inefficient, and is still understandable two hours from now when I read the code again.
I'm with you there.
Hope this helps.
Author
Phew, it's done, at last. Now, I have to test it...
As for coding prototypes (as opposed to chalking them up), it's because this particular algorithm is used to create a "graphically pleasing" output. Since I have no way of determining if a given output is aesthetically acceptable without actually seeing it, I had to code the algorithm and watch.
The upside is that it works pretty well. The downside is that it's pretty long to describe at a low level (i.e. PHP).
As for coding prototypes (as opposed to chalking them up), it's because this particular algorithm is used to create a "graphically pleasing" output. Since I have no way of determining if a given output is aesthetically acceptable without actually seeing it, I had to code the algorithm and watch.
The upside is that it works pretty well. The downside is that it's pretty long to describe at a low level (i.e. PHP).
Quote:Original post by ToohrVykQuote:Original post by Zahlman
I find that the boredom and repetition largely go away when you let the prototype language be much higher level than the implementation language. (Unless you count the boredom and repetition involved in dealing with design patterns in the low-level implementation language [wink])
Well, actually, the fun part of programming a new algorithm is the design and tweaking portion. Once the layout is known and the various constants and factors have been optimized, there is little left to invention, and everything left to writing. Which is boring.
Then don't do the tweaking on the prototype; save it for later. The prototype is really just supposed to be a sketch, after all.
Or, along the lines of what let_bound said: don't "really" do "code" prototypes.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
