sysvar changed reactor

[peter]

It has more to do with cost.

Nobody wants to rewrite all of the old lisp code. We couldn't afford to.

Also, I think LISP is really easy to write compared with .NET.

I have over 5000 lisp files in my library that date back 20+ years, and many work great and do not need to be re-written. LISP is a great language, and I think it will be around for at least another 20 years. It is much easier to prototype a new function in LISP than in any other language, although it has less options as the other languages...

By building a solid bridge, we could keep all of our legacy code and start out creating all new code using .net. By exposing the code for the bridge, would allow them to learn .NET while still working with LISP.

Without the bridge I can guarantee that most of them will NEVER migrate.

Peter

[peter]

Tony,

I have already been speaking with the ADN, via devhelp on the subject.

I have seen MANY of their examples, although I did not view their webcast. I will watch it.

Plus I want to not only find the right functions, I want to write them, and understand each component, in my own style.

Peter

[dgorsman]

It has more to do with cost.

Nobody wants to rewrite all of the old lisp code. We couldn't afford to.

Also, I think LISP is really easy to write compared with .NET.

I have over 5000 lisp files in my library that date back 20+ years, and many work great and do not need to be re-written. LISP is a great language, and I think it will be around for at least another 20 years. It is much easier to prototype a new function in LISP than in any other language, although it has less options as the other languages...

By building a solid bridge, we could keep all of our legacy code and start out creating all new code using .net. By exposing the code for the bridge, would allow them to learn .NET while still working with LISP.

Without the bridge I can guarantee that most of them will NEVER migrate.

Peter

The time/cost component is a great point, one ofter overlooked in the more theoretical development side. The bridging of code between LISP and .NET is a good idea, but I think it would be best served as a one-way trip. That would be using .NET as a means of extending the capabilities of existing LISP (eventually, maybe, outright replacing) but not relying on LISP to implement whats being written in .NET. Its hard not to rely on that massive codebase of existing LISP functions, isn't it? Its a sacrifice but to my mind the reduction in complexity is worth it.

[peter]

Thanks dgorsman,

I have a LOT of code where I create new lisp functions with vb.net. No problems there.

That is not my problem, also I have a way to have the two languages to communicate, but it is not as solid as I want.

The lisp calling .net is easy.

The .net calling lisp is a little more complicated.

Obviously I can use a sendcommand method to have .net run lisp. (I got that)

I have not seen what I want yet.

But I am searching for a way that avoids the command pipe, and is modal so it won't crash AutoCAD.

Also, AutoCAD development, for the mopst part is being done by non professional programmers that are intimidated by .net. Rather than focus on the most powerful platform for development, we need to focus on the platform that will help them get up and running as quickly as possible.

I agree with Tony's comment: "The VB language was invented for and mainly targets non-professional programmers, and designed be 'easy' to use".

That is precisely why I chose vb over c# for my lecture proposal.

As far as my project...

I am looking for a good example of an operational com wrapper in vb.net to play with the available reference methods, like the vl16.tlb or maybe the vlcom.arx.

If it wasn't difficult to do, it wouldn't be very much fun!

Peter

[sinc]

Also, AutoCAD development, for the mopst part is being done by non professional programmers that are intimidated by .net. Rather than focus on the most powerful platform for development, we need to focus on the platform that will help them get up and running as quickly as possible.

I'm not sure that's true. And even though many people who are used to Lisp or VBA are intimidated by .NET, it's actually easier in many respects. There is a bit larger initial learning curve, but after that, things are much easier. And that's not even considering how much easier it is to read and maintain .NET code than Lisp.

At this point, I think of Lisp as basically "Autocad's macro language". It's good for writing very small routines, on the order of macros. For anything else, it is not a very ideal language in many respects.

I guess it all comes down to how much value you really feel exists in your old Lisp libraries, and that depends entirely on what sort of customization you've done in the past.

But if you are looking to write a Lisp bridge, thinking that's easier than just migrating to .NET, I think you'll end up discovering that it's more involved than you might expect. There are good reasons why Lisp and VBA have been deprecated as Autocad development languages.

So while people might be able to get up and running quicker with Lisp, that initial gain doesn't hold up, as over time, all the problems with Lisp code and mixed development eat up that gain and more.

[peter]

Sinc,

I can tell you it would cost us (our company) about a million dollars to re-write the thousands of programs I have developed for them in LISP over 15 years.

Never happen.

IMHO LISP is a great language for all sizes of programming for many reasons.

.NET is much more difficult to program even the simplest of things, like:

(getpoint) is pretty simple.

I have seen the full page of code in .NET to do the same thing. Until simplified libraries of expressions for common functions like getpoint are developed and distributed with AutoCAD, it will take a lot more time to develop .NET. than LISP.

By the time I am done I hope to merge the two languages to take advantage of both of their strengths.

Then I will give the bridge away so everyone can use it.

Just because it is a good puzzle.

I have already found out how to do it, I just need to write the code. I am also looking for good code samples, to try different methods of accomplishing what I want.

Peter

[dgorsman]

By the time you finish converting your LISP to NET, you will have to start over again to convert to its successor. There isn't much room in budgets these days for upgrading things which are already proven to something more complex.

[peter]

Exactly,

That is why I prefer to develop in LISP, but I want the ability to use all of the .NET framework too.

They say you have to marry your arx (.NET) code

vba you just had to date,

but LISP you can love em and leave em!

Peter

[sinc]

(getpoint) is pretty simple.

I have seen the full page of code in .NET to do the same thing.

I think you're exaggerating. Here is the C#.NET equivalent of (getpoint):

PromptPointOptions pops = new PromptPointOptions("\nSelect Point");
Application.DocumentManager.MdiActiveDocument.Editor.GetPoint(pops);

That's it. And while it might initially seem like a lot compared to "(getpoint)", it really isn't, once you consider all the additional functionality and control you have in .NET.

That's basically why I say that I view Lisp as only appropriate for macro programming or short scripts. It is actually a very poor language choice for large development efforts, because of its lack of readability and maintainability.

There is also no comparison between the support offered by the free Visual Studio Express or SharpDevelop platforms and the VLisp IDE. The VLisp IDE in Autocad is quite weak. That helps make it more difficult to do large development efforts in Lisp.

As for your "thousands of Lisp routines", I can pretty much guarantee you that nobody uses thousands of Lisp routines. So how many of those routines are REALLY being used by your users?

And then out of those routines that are actively being used, how many of them could actually be replaced by built-in functionality that has been added to Autocad since you initially wrote the routine?

And out of what's left, how many are self-contained routines that are working fine, and you don't even need to look at?

If you assess all of that, you may find that there really aren't that many routines you need to focus on.

If you are moving toward the route of a bridge, simply because you have some Lisp "library" routines that you use frequently in your coding, then a better approach may be to migrate those "library" routines to .NET. It would be much more maintainable, moving into the future.

Of course, it's very possible that your route is the best route. I can't say that from my position. I just felt obliged to urge you to really think about your proposed approach, and make sure you are really choosing the best route, and not simply making a decision based on a personal preference for Lisp over .NET. There are many huge advantages to using .NET instead of Lisp, and there are strong reasons to not want to continue large development efforts in Lisp, or even in a mixed Lisp/.NET environment. So such an approach should only be embarked upon if there really is no other viable choice.

[dgorsman]

I do agree on the part about converting the libraries first, its an excellent starting point for implementing .NET. And .NET is the better choice for truly large unitary applications.

Still have to argue about "more maintainable", as its still difficult to find coders who are both familiar with .NET and AutoCAD, plus having the appropriate compiler program in-house, and keeping the source code archived, and working out distribution issues (CASPOL vs. copy-local), demand-loading, supporting different versions of AutoCAD etc. With LISP its just "store file in read-only network location, load file on start-up", and if problems come up theres a huge, friendly user base to check with.