Asking any of you programmers if AutoLisp is a good language to learn for making you a better programmer?
I am not convinced it will make you a better programmer, but not because you will not learn skills, but rather because the skills you learn might well be limited to interaction with AutoCAD.
Has it added much insight and better thought process to your software development. (AutoCAD or non-AutoCAD)?
Basically my intrest is not so much the automation of cad but picking up a range of valuable programming skills.
Now, the thought process portion on the other hand, I think is quite interesting.
I started programming over 30 years ago using simple Basic. The syntax was straightforward and the execution was linear. For the purpose of the programming I was writing, it was good enough. I picked up lisp around '93 and was quite confused because while it appeared to be a linear structure, the code is actually written in an inside-out fashion. It forces the programmer to consider the order of operation instead of thinking in a straight line conceptual theater.
Lisp also introduced me to the first real concept of datatypes, although they are not declared as such i.e. a variable can be a string, integer, list, real number etc. it can also be reused as a different data type on the fly. Because of the flexible nature of variable usage, one must be keenly aware of the variables used, what type of data is in each variable and whether or not the variable is initialized. In most high level languages simply defining a variable initializes it to the default datatype value (i.e. 0 for an integer or "" for a string). This is useful to the programmer just throwing together a bit of code, but in lisp, the programmer will have to think about the variables and what they contain at any point in the code.
Another habit that it will help instill is the explicit nature of terminating functions and code segments. For example, in C# code segments are bound by curly braces and VB uses context strings. The proper closing of parenthesis' will force the programmer to consider the code wrapped up in the code segment. Long functions become untenable and the lisp programmer will certainly break it down into smaller bits of reusable code, if for no other reason than to make the code easier to understand ... after all it is
Lost
In
Stupid
Parenthesis. ... ultimately, you will choose to utilize smaller code segments and will build libraries of functions.
Error handling in lisp is limited to simply quitting the code execution if something goes wrong. In many higher level languages, the error is merely ignored (VB's On Error Resume Next comes to mind) or an error isn't thrown at all. In lisp though, most errors will result in catastrophic failure of the entire code. There is no "Resume Next" in lisp. The programmer will have to consider how to handle every conceivable error and write copious amounts of code in many instances, simply to handle something as simple as an incorrect datatype. This leads to the practice of checking variables before acting on them. Interestingly enough, my .NET instructor in college used to get upset because I wouldn't utilize Try Catch blocks on simple bits of code. If you can code around a known or expected error, why not? Seriously, if you know that a variable could be null at a particular point and could cause a problem, simply check for its value before acting on it instead of acting on it and then trying to figure out what to do then.
In the end, I don't think it necessarily makes you a better programmer for having learned lisp, but the simplicity of it makes it a quick learn and the crux of your question is whether or not you can gain anything useful from learning it ... I say yes
