0

I am engaged in a project that works mainly in AutoCAD to design and manufacture prefabricated building components such as roofing trusses. One of our goals is to redesign a program that was written in LISP that functions in designing roofing trusses. We are to rewrite the LISP code in C# and incrementally implement it into the current libraries that they have set up.

My problem is that I have been tasked with building a rudimentary LISP to C# converter. After some research (as Google results quickly show that such a thing does not readily exist on hand), I have come to the question of which way of converting this legacy code would be more efficient. Would it be better to take chunks of the LISP code to analyze and rewrite in C#, or should I continue on with developing a rudimentary converter for the AutoLISP code?

Rainer Joswig
  • 136,269
  • 10
  • 221
  • 346
Archer
  • 492
  • 1
  • 4
  • 12
  • Why? Unless performance is an issue or the code is lousy then why not just maintain the Lisp code? There are plenty of resources and developers around who know Autolisp, it's not going away any time soon. Bonus, the API is a lot more stable than the .NET or ObjectArx APIs. – CAD bloke Jul 14 '14 at 10:30

2 Answers2

2

You should take chunks of the LISP code and rewrite in C#.

Even if it was less effort to write a general purpose LISP interpreter in C# than to rewrite the LISP in c# (which is highly improbable), the LISP is probably running AutoCAD commands like you would type in the AutoCAD command line instead doing things the ObjectARX way. So you would also need to convert the commands to use the ObjectARX API.

RyanB
  • 757
  • 4
  • 11
0

C# is a compiled object-oriented programming language whereas AutoLISP is an interpreted expression-oriented language. Therefore there is never going to be a really straightforward way of converting one to the other without a monumental effort.

Its worth noting that AutoLISP has flexibility to be modified quickly without needing to be recompiled. The benefit to using native in-process C# is that it's extremely fast versus a similar LISP approach. I've found there's a nice middle ground for maintaining the flexibility of LISP with the speed and power of C# which leverages the LispFunction command flag and ResultBuffer type in the .NET native API.

Parrish Husband
  • 3,148
  • 18
  • 40