in reply to Idioms considered harmful

At my company, we have knowledge engineers and software engineers. The knowledge engineer do their job in Perl or Lisp and produce code that gets ported to C/C++ by the software engineers.

There are several reasons for this setup, but the upshot is that the knowledge engineers can do their work quickly and efficiently, while the software engineers take care of speed issues, stability and maintenance, each concentrating on what he's best at.

However, the price to pay for me is that I have to refrain from using Perl to the extreme, in the sense that I can't use idioms that are too hard to translate to other programming languages, e.g. C/C++

This might be the point to draw the line for those who ever want to get their code ported (as well as those who'll have their code ported, willingly or otherwise).

map is easy to translate, grep a little harder, but a file slurp?

Just my US$0.02...

        -gjb-

Replies are listed 'Best First'.
Re: Re: Idioms considered harmful
by goldclaw (Scribe) on Oct 16, 2002 at 01:26 UTC
    A little of topic, but...

    In C/C++ you do a file slurp with a open/mmap system call, and assign the resulting pointer to a collection object of your choice(char*,vector<whatever> or string). In fact, if your c++ programmers are any good, they should be able to handle most of the perl code you can throw at them, at least the idioms, without much problem. Doing it in C on the other hand....

    Closeures are doable in C++, but its ugly and I believe it can't do everything(Could be wrong on that). Regexps can be a pain if they don't use a proper regexp library. Be careful with reblessing references into other classes, or dynamically changing @ISA(I cant think of any idioms that actually do that....).

    just my 0.2 kroner

    goldclaw