Programmer's Wishlist?

The last posting I found on this topic was in 2001 so I felt obliged to raise the issue again. It has been my observation that Autodesk seems oblivious to the desires of its customizers unless it is in the direction of VBA. Despite their best efforts to wean the lispers over to VBA they have largely failed. Why is this?

1. Chad Wanless wrote ObjectDCL, so the carrot of easy dialog boxes was no longer a carrot.
2. They gave us the VL functions which allowed us all to write libraries of LISP functions interfacing us into EXCEL, WORD and even ACCESS so that once again we didn't need VBA except for speed critical applications, and this is becoming less often as computers keep getting faster.

You would think they would notice this and wonder why we are all being so obstinate, but they don't seem to. So I will spell it out for them:

LISP is a better language for math, geometry and the type of data structures CAD programmers use most often - LISTs!

LISP programs are half the lines of code and half the time to write and debug.

So my programmer wishlist items consist of the same complaints we have been hearing for several versions of AutoCAD now. My main wishes are:

1. A better LISP, not VBA. Optional number of arguments, macros, larger integers. Give us the root functions, we'll be happy to write the rest of it ourselves.
2. Either buy ObjectDCL and add it to AutoCAD or enlarge the DCL vocabulary.

Am I alone in this? What do some of you other hackers want? We have to keep complaining or no one will listen.

 

I don't this is the forum that will produce a response from AutoDESK, in fact I'm pretty sure it isn't. You might wish to check with AUGI.

 

As far as I'm concerned, yes. I feel quite comfortable in both
languages, but (for nearly 2 years) I only use Vlisp when I HAVE TO.

Terry

 

Terry,
Can you elaborate your reasons for mostly working in VBA?
I understand dialogs, shorter object notation, and working at
the application level and with MDI better. It's probably easier
to read than the ActiveX implementation of LISP. Are there other
reasons?

Are you using ObjectArx?

Regards,
Doug

 

Jeremy,
I think Autodesk has done a fair job of supporting LISP. The
move to VBA and .NET is inevitable since a programmer versed
in those languages can use the programming interfaces in a
variety of applications. As far as I know, no other Windows
application is using LISP as its internal programming language.
While I hope they continue to support LISP, it would seem possible
in the future that they might seek to simplify their support of 3rd
party developers.

I have enjoyed LISP and still do most of my AutoCAD programming
with it, but for some things, it is more difficult.

I imagine that Autodesk was able to purchase the VBAIDE and
the VBA language from Microsoft rather than develop it in house
and then needed to provide only the object and application access
functions.

I have not tried ObjectDCL. As far as Autodesk aquiring it, that
seems unlikely. It would also require that CW and ADesk both
agree to the transaction, something that we have little or no influence
over.

Where are you getting your statistics about how many have/have not
made the transition to VBA? If given the the chance to teach my
students LISP or VBA today, I would choose VBA, primarily
because they can reuse that knowledge with Excel, Word, Access,
Powerpoint, and many other applications.

Regards,
Doug

 

Heres a non-technical statement, "It just feels right to me." I learned
BASIC a long time ago, then learned LSP/DCL because AutoCAD didn't
support basic. Then when I get used to Lisp, they added basic support.

I became quite comfortable with Lisp, but never liked editing DCL. And
the hoops for dismissing a DCL dialog to get user interaction always
required me to go back to my previous uses to copy instead of just
banging it out, nothing as simple as Me.Hide. No grid (or other)
controls were available. I know ObjectDCL addresses those but even if
Autodesk bought and implemented it I wouldn't go back to it.

So I guess interface coding (which is a lot of the time to complete an
application) is what did it for me.

The fact that newer product API's (such as Civil3D) don't support Vlisp!
Thats the area I'm working on today and vlisp isn't a choice, but I'm
not bothered by it at all.

No. I feel confident that I could learn it, but since I can do 98% of
what I need in VBA (with Vlisp as backup) I can't justify the time. I
would have to stop producing sellable code for 2-3 months to learn it,
and don't feel that I would be paid back for a long time, if ever.

Terry

 

If dcl is your major gripe I suggest buying Protobox from Richard Littleton,
The program works great and I very seldom look at my DCL files in a text
editor.
Rodney

 

Terry and Doug:

You program for profit. I program for myself, as I think Jeremy does. I'm
trying to produce drawings, not software. So for me AutoLISP/Vlisp and
ObjectDCL are the only way to go. If you refer to the "Import Layers"
thread you'll see an excellent example of a rough program not suitable for
retail but is excellent for what I and other drafters do.

If I were to learn another language it would be foolish to waste time on
VB(A). I can do anything "I require" in Lisp/ObjectDCL that I could do in
VB(A). What I would want to add to my time-saving drafting needs would be
smart-objects which would lead me to ObjectARX.

I think this is the point Jeremy is trying to make. If I find myself in the
middle of an arduous drafting task I can bang out a quick lisp to make my
life easier. Heck, I even wrote a lisp to change the names of 1000 JPEGS
that I messed up in 3dVIZ. So you see LISP, for us drafters, is like the
old chorded drill in the shop; yea, Home Depot has that snazzy new DeWalt
chordless screw Gun, but my trusty old Black & Decker does just fine . . ..

Humbly,

jb

 

I don't have hard stats for how many people have changed over but the CAD Mananger's column in Cadalyst based on user response was not showing a big move over to VBA, most users were still using AutoLISP. I believe LISP has the superior syntax because in a good LISP I can write all kinds of structures simply that you would throw your hands up in the air trying to do it in VBA. Try doing any MAPCAR or APPLY type operations in VBA. I can write in both languages but always spend more time writing and debugging a VBA program. Why do people consider this a superior trait? Most newer languages (Python, Ruby, Perl) are incorporating features from LISP and are accordingly easier to use and more powerful than VBA. I recognize that being able to tie-in to the Microsoft universe is important but why should we be held hostage to it? I get the feeling that AutoLISP programmers are regarded as curmugeons that don't have enough brains to use VBA when the truth is simply that many of us prefer the LISP way of thinking and doing things over the VBA way of doing things.

 

The most wide-spread application using Lisp is likely the Emacs editor;
more common in the Unix/Linux world, but also available on Windows (and
if you are not using it for your Lisp programming, you are working
inefficiently). Other succesful applications exist, but they tend to not
be mass-market programs, more often rather specialist stuff.

So what's preventing them purchasing Allegro CL from Franz or Lispworks
from Xanalys? Or perhaps Corman Lisp?

If we are asking for a better language, why not go all the way and get a
full-size Common Lisp? It would have everything on your wish list, and
quite a lot more, too; up to and including ANSI standardization.
Building a compatibility mode to run AutoLisp/VisualLisp code would be
quite simple for source code, and likely possible even for .vlx programs
given access to VisualLisp internals.

--

 

but my trusty old Black & Decker does just fine . . ..

I've used the comparison of a chisel versus a router. There's a small realm
of overlapping functionality, but much larger realms where they can't
reasonably be substituted. Certainly the router is way more "powerful," and
will do things you couldn't reasonably do with a chisel. But it's also true
that in most of the situations where you grab a chisel, a router would be
wildly inappropriate choice. You can put a quick point on a pencil with a
chisel, for instance.

 

I don't think you're alone, Jeremy.

To me, writing a DCL in Autolisp has always been a huge pain. And instead of
using ObjectDCL, I've been using doslib for simple dialog.

The idea of supporting optional arguments is also great. In order to achieve
that, what i'm doing now is put those arguments in a list, and having the
subroutine to check the length of the list to find out how many arguments
were supplied.

I sure wish there will be more support towards LISP from AutoDesk. But
honestly, I can hardly see it happen.

 

I have an application that has about 30k lines of code and involves about 25 different dialog boxes.
I basically rewrote the interface functions to the Land Desktop Database - my own vertical alignment editor, horizontal
alignment manager, labeling with saved label styles and so on.

At one point, I tried switching over to VB and was able to mimic just about everything in VB. The problem was that I
had to do so many "sendcommands" that did things with lisp. It was stupid and slow.
Lisp has the ability to do lists which are nested arrays. This is so nice for dealing with groups of data formatted as
lists.

The real two killers for me are:
1) Lisp has grdraw and grread functions. VB does not no matter how you slice it. Those are huge necessities to giving
users feedback and making input slick. Nothing comes close in VB.

2) I do not like VBA since it groups everything into one file (.dvb) that is not compiled, I stick to VB for just about
everything. I have not figured out how to tell a VB prog what acad session to operate on if more than one are open.
In other words, since VB runs outside acad, keeping track of what session it is hooked with is a problem. Suggestions
welcome.

thx

JeremyD <>
|>The last posting I found on this topic was in 2001 so I felt obliged to raise the issue again. It has been my observation that Autodesk seems oblivious to the desires of its customizers unless it is in the direction of VBA. Despite their best efforts to wean the lispers over to VBA they have largely failed. Why is this?
|>
|>1. Chad Wanless wrote ObjectDCL, so the carrot of easy dialog boxes was no longer a carrot.
|>2. They gave us the VL functions which allowed us all to write libraries of LISP functions interfacing us into EXCEL, WORD and even ACCESS so that once again we didn't need VBA except for speed critical applications, and this is becoming less often as computers keep getting faster.
|>
|>You would think they would notice this and wonder why we are all being so obstinate, but they don't seem to. So I will spell it out for them:
|>
|>LISP is a better language for math, geometry and the type of data structures CAD programmers use most often - LISTs!
|>
|>LISP programs are half the lines of code and half the time to write and debug.
|>
|>So my programmer wishlist items consist of the same complaints we have been hearing for several versions of AutoCAD now. My main wishes are:
|>
|>1. A better LISP, not VBA. Optional number of arguments, macros, larger integers. Give us the root functions, we'll be happy to write the rest of it ourselves.
|>2. Either buy ObjectDCL and add it to AutoCAD or enlarge the DCL vocabulary.
|>
|>Am I alone in this? What do some of you other hackers want? We have to keep complaining or no one will listen.

James Maeding
jmaeding at hunsaker dot com
Civil Engineer/Programmer

 

Optional arguments, like this?

(defun test (arglst / a1 a2 a3)
(mapcar 'set '(a1 a2 a3) arglst)
)

;;;(test '(1 2 3)) = (1 2 3)
;;;(test '(nil 2 nil)) = (nil 2 nil)
;;;(test '(nil nil 3)) = (nil nil 3)
;;;(test '(nil 2)) = (nil 2)
;;;(test '(1)) = (1)
;;;(test nil) = nil

 

So what are the advantages of using emacs versus the vlide editor that comes
packaged with AutoCad?

keep complaining or no one will listen.

 

Well, this was aimed more at the people proudly using Notepad etc
non-lisp-aware editors, and producing un-indented code troubled with
unbalanced parens.

For most Lisp environments Emacs has direct connections, so that you can
run the lisp system through Emacs, like the Visual LISP Console -window
in Vlide, and also directly send code from the editor to be evaluated or
compiled. It seems nobody has built this for AutoLisp, so here Emacs is
only usable as an external editor: debugging etc still has to be done
with Vlide.



For handling raw program text, emacs has several Lisp-related commands.
A fast cut-and-paste from the docs:



backward-kill-sexp ESC <C-delete>, ESC <C-backspace>,
<C-M-delete>, <C-M-backspace>
Kill the sexp (balanced expression) preceding the cursor.

backward-sexp C-M-b
Move backward across one balanced expression (sexp).

forward-sexp C-M-f
Move forward across one balanced expression (sexp).

indent-sexp M-x indent-sexp RET
Indent each line of the list starting just after point.

kill-sexp C-M-k
Kill the sexp (balanced expression) following the cursor.

last-sexp-toggle-display M-x last-sexp-toggle-display RET
Toggle between abbreviated and unabbreviated printed representations.

mark-sexp C-M-SPC, C-M-@
Set mark ARG sexps from point.

transpose-sexps C-M-t
Like M-t but applies to sexps.

lisp-fill-paragraph M-x lisp-fill-paragraph RET
Like M-q, but handle Emacs Lisp comments.

beginning-of-defun C-M-a
Move backward to the beginning of a defun.

beginning-of-defun-raw M-x beginning-of-defun-raw RET
Move point to the character that starts a defun.

lisp-eval-defun M-x lisp-eval-defun RET
Send the current defun to the Lisp process made by M-x run-lisp.

mark-defun C-M-h
Put mark at end of this defun, point at beginning.

narrow-to-defun C-x n d
Make text outside current defun invisible.

backward-list C-M-p
Move backward across one balanced group of parentheses.

backward-up-list C-M-u
Move backward out of one level of parentheses.

down-list C-M-d
Move forward down one level of parentheses.

forward-list C-M-n
Move forward across one balanced group of parentheses.

up-list M-x up-list RET
Move forward out of one level of parentheses.

parens M-x check-parens RET
Check for unbalanced parentheses in the current buffer.

insert-parentheses M-(
Enclose following ARG sexps in parentheses. Leave point after
open-paren.

show-paren-mode M-x show-paren-mode RET
Toggle Show Paren mode.

toggle-highlight-paren-mode <menu-bar> <options><highlight-paren-mode>
Toggle whether to highlight matching/mismatched parentheses at cursor.


- And if these are not enough, the whole thing is programmable in Lisp.




--

 

Martii,
See comments below.

An editor is not what I was thinking of. I use AutoCAD/ADT, 3D Studio, Viz Render, Excel,
Access, Word, MathCAD, Powerpoint and some image editors on a regular basis. None of them
support LISP but most support VBA. Newer versions are supporting .NET languages.

The time it takes to learn a language must be balanced with the number of
opportunities to use it and benefit from it. I learned LISP because it was
the only language that AutoCAD supported at the time and I needed to
customize AutoCAD because it was too inefficient to use without customization when I began
to learn it.

I use vlide and find it adequate to meet my AutoLISP needs. I can't imagine
an Emacs editor would give me internal access to AutoCAD the way Vlide does.

There have been discussions about the shortcomings of LISP but I can't imagine what profit
Autodesk could recognize by buying one of those packages and spending time adapting it to
the AutoCAD/ADT/ABS object models. Of couse, if no one asks, then obviously we're not
going to get it. ;-)

 

Thanks for the info Martti.

Casey

 

A few lisp/general programming wishlist items:

-random input for ssget (as initget with entsel/getxxx functions)

-a 'boundary' function with fuzz options

-direct manipulation of vplayers in viewports

-integration of additional acetutil.arx functions (especially - acet-ui-progress, acet-ss-drag-*, and acet-ui-status (or hover equivalent)

-a toggle on 'Find' in the VLIDE to look for the definition of a search string (i.e. - find (defun [search string] ...) or a context popup menu after the function showing argument names (and yes, optional arguments would be nice)


-CTBFILE->LIST and LIST->CTBFILE function ( STB, too...)

-access to the screenmenu object

These are just off the top of my head - I'm sure that I'll think of a few more after I post this.

I use vlisp for about 80% of my programming needs - possibly just because I'm more comfortable with lisp - but also because I find it much simpler to manipulate/add drawing objects with lisp than vb/vba. Also, I like the ease of using lists and not worrying about variable types - and the ability to leave a variable in the drawing session for later use.

I use DCL for simple dialogs - create the dcl text files on the fly for the most part, and create activex forms for more complicated UIs.

= my 0.02€

Peter

 

A program called Lisplink can evaluate lisp code in its IDE as well. I
briefly tested it for couple of days. It still lacks many features that
AutoCAD lisp IDE provides. So I didn't keep using it.