DotNet Visual Lisp

[BlackBox]

Now here's a "biggie" . Since the Mac version, what's happening to DotNet? I thought it was only on M$ operating systems? Sorry, you tested this - I've yet to have the pleasure.

That *IS* the question, isn't it!?

Seemingly all 'flavors' of AutoCAD are shifting that way (toward .NET), for example look at Revit.

You'll find this interesting:

The development of Mac OS X APIs reflect that of the underlying operating system. Mac OS X is written mostly in C and Objective-C. In particular, Objective-C is ubiquitous in the human interface systems. With Mac OS X v10.5, after a transition where new elements of the Carbon interface specifically referred to the underlying Cocoa system, Apple identified Objective-C and Cocoa as the preferred interface to human interface services. Carbon access to various human interface services in the 64-bit operating environment is not available, and significant new features will not be added to the 32-bit Carbon interface.[6] Most other parts of the system, which have less emphasis on Objective-C, are not so affected.

Cocoa is one of Apple Inc.'s native object-oriented application programming interfaces (APIs) for the Mac OS X operating system. It is one of five major APIs available for Mac OS X; the others are Carbon, POSIX (for the BSD environment), X11 and Java.
Cocoa applications are typically developed using the development tools provided by Apple, specifically Xcode (formerly Project Builder) and Interface Builder, using the Objective-C language. However, the Cocoa programming environment can be accessed using other tools, such as Clozure CL, LispWorks, Object Pascal, Python, Perl, Ruby, and AppleScript with the aid of bridging mechanisms such as PasCocoa, PyObjC, CamelBones and RubyCocoa. An implementation of the Ruby language, called MacRuby, which does away with the requirement for a bridging mechanism, is under development by Apple, while Nu is a Lisp-like language which can be used with Cocoa without a bridge. It is also possible to write Objective-C Cocoa programs in a simple text editor and build it manually with GCC or clang from the command line or from a makefile.

... Perhaps will there be an Objective-C based IDE in the future?

[irneb]

... Perhaps will there be an Objective-C based IDE in the future?

Now there's a thought! I just think ADesk is letting themselves up for some huge amounts of extra libraries and / or inconsistencies. They'd be better off making use of an interpreted language (i.e. AutoLisp or such) - since they'll then not need to have several different API's for each platform (e.g. what if they also add a Linux-Gnome version of ACad? Do they then need yet another library for X11?).

I'd think the easiest method would be to leave the DotNet stuff as is, but create a wrapper-translator library to match DotNet to the native OS's libraries. Similar (but in reverse) to what Delphi/Kylix does with its Borland Foundation classes mapping onto the Windows libraries as well as the Linux libraries - no need to modify source code to compile for another platform.

[eptownie1988]

I too would be interested in a reply regarding the .NET API when used on a Mac version of AutoCAD. I am a Mac user at home and would definitely prefer an OSX version of AutoCAD over a PC platform anyday. The main concern I have is the intergration of custom routines on a Mac OS versus a PC OS. Any information would be greatly appreciated.

[irneb]

I too would be interested in a reply regarding the .NET API when used on a Mac version of AutoCAD. I am a Mac user at home and would definitely prefer an OSX version of AutoCAD over a PC platform anyday. The main concern I have is the intergration of custom routines on a Mac OS versus a PC OS. Any information would be greatly appreciated.

At present: No. You will only be able to use LSP addons until ADesk makes some form of runtime DLL converter / linker for Mac. And I don't think the extended Lisp (VLAX stuff for ActiveX/COM) would necessarily work on Macs as well. So you're stuck with only working Lisp as a macro language (i.e. sending commands to ACad) or working with DXF data.

See why I think ADesk should rather just extend AutoLisp to work with the new stuff?

[BlackBox]

At present: No. You will only be able to use LSP addons until ADesk makes some form of runtime DLL converter / linker for Mac. And I don't think the extended Lisp (VLAX stuff for ActiveX/COM) would necessarily work on Macs as well. So you're stuck with only working Lisp as a macro language (i.e. sending commands to ACad) or working with DXF data.

See why I think ADesk should rather just extend AutoLisp to work with the new stuff?

I find it interesting that you post this today, as just yesterday I dove into writing an XCode application (using Cocoa/Objective-C) for fun. lol

I for one *hope* that given OS X 10.6 (Snow Leopard) has a dominant C-based environment, and I'm sure Lion will have (later this year), that it will be possible (some day) for AutoCAD-Mac to have some sort of overhead that will support cross-platform development, given .NET's Common Language Runtime (CLR).

Perhaps (one day) an extension can be developed for Visual Studio, to allow this port-ability (pun intended).

As for Visual LISP on PC - I do wish that Autodesk would better empower ActiveX as, for example, in many Civil 3D Aec* entities, vlax-dump-object yields no results. I now am *forced* to use .NET which is a shame, given the VLIDE being built in (i.e., no 3rd-party install of VS).

... Guess that's why this thread is posted in the *Wish List* forum!

[irneb]

Does anyone know if M$'s replacement for VBA (called VSTA) works on Mac versions of M$ programs? I'm thinking stuff like MSO 2011 for Mac. If so then it's "really" time for ADesk to do a "true" replacement of VBA instead of just sticking their head in the sand with this .Net stuff. I know the main issue with porting to Linux is due to the .Net stuff not wanting to work too well in Wine - probably the same for Mac as it is actually a BSD (also derived from Unix as Linux was - just uses Coco instead of WinX11 / Gnome / KDE / etc.).

But I still think they'd be much better off just extending AutoLisp to directly work with everything .Net can do (actually everything ARX can do since .Net is also still behind that). Perhaps extend the ActiveX libraries, but I think that won't help Macs too much though - still DLL / OCX files. It should become native to AutoLisp (like those layerstate functions were added in 2000 or so).

If they feel AutoLisp is too cumbersome / old / restricted / etc., then by all means add another scripting language like Python / Perl / JS / VBS / Ruby or even Java. Or even just upgrade the 20+ year old AutoLisp engine to one of the Current Lisp engines - that way there'd be very little porting needed from old LSP files.

And while they're at it extend the old defunct DCL language. Maybe have something similar to Mozilla's XUL.

[irneb]

Actually I've started a wiki on this subject. For planning on how to go about making such available to AutoLisp: http://alisp-ext.wikidot.com/

Let's face it, ADesk has some sort of aversion to lisp and simply wants to kill it through attrition! They've been trying for more than 10 years now, and it won't die. To the point where we've come full circle and find all these new programming languages like Python, Perl, Ruby, etc. having concepts exactly the same as Lisp had in the 60's.

And now also the stuff is creeping into C++/C# even. But still ADesk cannot see why they should even consider making AutoLisp into something comparable to its other big brothers.

[dgorsman]

Resources - time, money, manpower. And, the people in charge of implementing any LISP upgrade are professional programmers. I'm sure to them LISP in AutoCAD "isn't a REAL programming language", C#/VB .NET "just isn't that hard to learn" and "if you can't handle it get a real programmer to do it for you". But I could just be feeling pessimistic today

[irneb]

Yeah well ... if that is their opinion, then all I can say is:

The only reason that AutoLisp is an inferior language to C++ is because THEY'VE NEVER UPDATED THE DAMNED THING IN 15 YEARS! If they made something comparable to CL then you'd have seen hundreds of user created addons which would surpass even ADesk's own vertical products in both functionality, efficiency & robustness!

Lisp is JUST THAT MUCH BETTER A LANGUAGE ... and I speak from experience! In all of C, C++, C#, VBA, VBS, VB, VB.Net, Java, JavaScript, PHP, ASP, Pascal, Delphi, ObjectPAL, and Lisp! Of all of them? My favourite is still Lisp!

[BlackBox]

... professional programmers. I'm sure to them LISP in AutoCAD "isn't a REAL programming language", C#/VB .NET "just isn't that hard to learn" and "if you can't handle it get a real programmer to do it for you".

I think this is funny given recent events at work.

I'm Beta testing my state's DOT Civil 3D 2012 'Kit' which is meant to mirror their long time Microstation 'Kit'. Anyway, your comment is funny to me because they are NET obsessed, especially given their background in NET development for MS.

They do almost all of their coding in NET, not ARX, and then they don't know how to properly configure their development.

It's riddled with errors (not custom error messages) when their .NET commands are invoked in Drawing1.

They use a SCR in the App Icon (/b switch) to turn the ribbon on, and CUILOAD their CUIx file instead of simply using (setvar 'ribbonstate 1), and Enterprise CUI in their Profile respectively.

They took LISP code I provided them (defuns) earlier this year, and File Copy+Rename as ACAD.lsp which serves no purpose once you open another drawing, unless you SAVEAS. They should be using *.MNL instead anyway.

Never mind that they don't know how to enable demand loading of their NETLOADS via the registry, so I informed them (thanks to what I learned from Kean! LoL). So instead, they NETLOAD them all via SCR (mentioned above), then their Ribbon button macros are something like:

 
^C^C_netload;<FileName>.dll;<CommandName>

<<SmacksForehead>>

These 'ubber-smart, professional programmers' have no clue how to deploy AutoCAD, let alone Civil 3D... But I guess their Windows forms are cool, ya know, for public workers. LoL

They're exhausting to continually correct. Especially for free. But I'm going to have to work with this 'Kit' at some point, and I'm trying to make sure it's fully operational.

<<Sigh>>

In any event - I'm still going to learn .NET development, because I don't know what the future has in store for me. If I end up not doing CAD for the rest of my life, I'd like to know that I have as many skills at my disposal as possible.

But under the assumption that I am able to continue doing CAD (and pay the bills!), then I too wish that ADSK would enhance VLIDE+API. I really began to notice just how much I enjoy LISP when jumping back and forth between C#/VB.NET and LISP. I kept writing code that was more complex than it needed to be... not declaring every data type (among other luxuries) is something I now can actually appreciate. LoL