I'm planning on developing an application which I intend to be heavily scripted (and scriptable). I also 
intend to implement a small command line interface, in the excellent tradition of autocad, in order to make 
the application more user-friendly and take advantage of it's scripting features. 

With that objective in mind, I've started gathering the app's requirements and evaluating some APIs and 
components. Nonetheless, I'm having a bit of trouble putting down the basic design for the command line 
interface. The first option that came to mind was to use the command line interface as a direct interface of 
the scripting engine, similar to how programs such as maxima, octave and the typical dynamic programming 
language interpreter. Nonetheless, I'm not sure if it that's a reasonable thing to do and if it wouldn't be 
better to separate the scripting side of it from the command line interface.

So, what are your thoughts on this issue?


Rui Maciel

Rui Maciel <rui.maciel@gmail.com> writes:

> I'm planning on developing an application which I intend to be
> heavily scripted (and scriptable). I also  intend to implement a
> small command line interface, in the excellent tradition of autocad,
> in order to make  the application more user-friendly and take
> advantage of it's scripting features. 
>
> With that objective in mind, I've started gathering the app's
> requirements and evaluating some APIs and  components. Nonetheless,
> I'm having a bit of trouble putting down the basic design for the
> command line  interface. The first option that came to mind was to
> use the command line interface as a direct interface of  the
> scripting engine, similar to how programs such as maxima, octave and
> the typical dynamic programming  language interpreter. Nonetheless,
> I'm not sure if it that's a reasonable thing to do and if it
> wouldn't be  better to separate the scripting side of it from the
> command line interface.
>
> So, what are your thoughts on this issue?

Indeed, it is a difficult choice.  Why should you commit to it right
now?  Just embed ECL in your application, and later you will be able
to implement any script language wanted by the users in lisp, without
modifying the application.  There even are already existing scripting
languages implemented in CL, such as python or JavaScript.

http://cliki.net/LanguagesImplementedInLisp

-- 
__Pascal Bourguignon__

Pascal J. Bourguignon wrote:

> Indeed, it is a difficult choice.  Why should you commit to it right
> now?  Just embed ECL in your application

I'm considering embedding ECL, mainly for being an implementation of a standardized language and for Lisp's 
inroads in projects such as autocad, which share some similarities with what I intend to do. Nonetheless, 
ECL's manual (and also wiki) suffers heavily from a series shortcomings that give the impression that 
adopting ECL for this type of work will be a major source of problems instead of solutions. Even if we 
consider that alternatives such as Lua and Python don't offer any advantage at all, their manuals and the 
overall volume of information available regarding all sorts of details about them don't make it possible for 
ECL to stand out as a serious alternative.


> and later you will be able
> to implement any script language wanted by the users in lisp, without
> modifying the application.  There even are already existing scripting
> languages implemented in CL, such as python or JavaScript.
> 
> http://cliki.net/LanguagesImplementedInLisp

That's a nice feature. How bad is the performance impact when compared with just embedding a dedicated 
interpreter?


Rui Maciel

Rui Maciel <rui.maciel@gmail.com> writes:

> Pascal J. Bourguignon wrote:
>
>> Indeed, it is a difficult choice.  Why should you commit to it right
>> now?  Just embed ECL in your application
>
> I'm considering embedding ECL, mainly for being an implementation of
> a standardized language and for Lisp's  inroads in projects such as
> autocad, which share some similarities with what I intend to
> do. Nonetheless,  ECL's manual (and also wiki) suffers heavily from
> a series shortcomings that give the impression that  adopting ECL
> for this type of work will be a major source of problems instead of
> solutions. Even if we  consider that alternatives such as Lua and
> Python don't offer any advantage at all, their manuals and the
> overall volume of information available regarding all sorts of
> details about them don't make it possible for  ECL to stand out as a
> serious alternative.

The documentation may have to be completed, but you can get good
support on the mail-list, mailto:ecls-list@lists.sourceforge.net


>> and later you will be able
>> to implement any script language wanted by the users in lisp, without
>> modifying the application.  There even are already existing scripting
>> languages implemented in CL, such as python or JavaScript.
>> 
>> http://cliki.net/LanguagesImplementedInLisp
>
> That's a nice feature. How bad is the performance impact when
> compared with just embedding a dedicated  interpreter?

It would depend on the implementation of the script language of
course.  In the case of CLPython, AFAIK it's a compiler, that generate
lisp code that would be compiled to native code on ECL.  Therefore I'd
expect the performance of python scripts to be good, almost as good as
lisp scripts.


-- 
__Pascal Bourguignon__

Pascal J. Bourguignon wrote:

> The documentation may have to be completed, but you can get good
> support on the mail-list, mailto:ecls-list@lists.sourceforge.net

ECL's mailing list does appear to be active, although it doesn't get nearly as much traffic as 
comp.lang.python or Lua's main mailing list. Nonetheless, before relying on mailing lists to address 
particular issues, it is important to be able to take care of the basics and get something up and running. As 
ECL's documentation efforts how stand, it is particularly (and needlessly) impractical for a ECL newbie to 
"get up on his two feet", more so if that newbie is also starting up on Lisp. 

That is a major problem affecting ECL. It's manual's entire section on embedding ECL amounts to a small C API 
reference with 9 entries (with no info on how it works and no implementation examples) and a non-existent 
introduction whose text amounts to nothing beyond the acronym TBD. The project may be interesting and may 
even be technically superior to any other offering but all those qualities are rendered to waste if the 
project doesn't even solve the most basic problems that hinder adoption.


Rui maciel

Rui Maciel <rui.maciel@gmail.com> writes:

> Pascal J. Bourguignon wrote:
>
>> The documentation may have to be completed, but you can get good
>> support on the mail-list, mailto:ecls-list@lists.sourceforge.net
>
> ECL's mailing list does appear to be active, although it doesn't get
> nearly as much traffic as  comp.lang.python or Lua's main mailing
> list. Nonetheless, before relying on mailing lists to address
> particular issues, it is important to be able to take care of the
> basics and get something up and running. As  ECL's documentation
> efforts how stand, it is particularly (and needlessly) impractical
> for a ECL newbie to  "get up on his two feet", more so if that
> newbie is also starting up on Lisp. 
>
> That is a major problem affecting ECL. It's manual's entire section
> on embedding ECL amounts to a small C API  reference with 9 entries
> (with no info on how it works and no implementation examples) and a
> non-existent  introduction whose text amounts to nothing beyond the
> acronym TBD. The project may be interesting and may  even be
> technically superior to any other offering but all those qualities
> are rendered to waste if the  project doesn't even solve the most
> basic problems that hinder adoption.

Indeed.  Perhaps you could contribute some more documentation?

-- 
__Pascal Bourguignon__

Pascal J. Bourguignon wrote:

> Indeed.  Perhaps you could contribute some more documentation?

I would gladly contribute if that was a realistic option, let alone a reasonable suggestion. As you are 
aware, the main problem plaguing ECL is the fact that the project's appalling documentation makes it 
virtually impossible to learn how to use it, much less rely on it to perform any task. So, how do you expect 
someone to contribute documentation if it isn't possible to learn how to use it to begin with? As you 
understand, in order for someone to be able to contribute anything to the project it would be necessary that 
that person knew how it worked and knew to use it, which isn't all that realistic due to the project's lack 
of documentation.


Rui Maciel

Rui Maciel <rui.maciel@gmail.com> writes:

> Pascal J. Bourguignon wrote:
>
>> Indeed.  Perhaps you could contribute some more documentation?
>
> I would gladly contribute if that was a realistic option, let alone
> a reasonable suggestion. As you are  aware, the main problem
> plaguing ECL is the fact that the project's appalling documentation
> makes it  virtually impossible to learn how to use it, much less
> rely on it to perform any task. So, how do you expect  someone to
> contribute documentation if it isn't possible to learn how to use it
> to begin with? As you  understand, in order for someone to be able
> to contribute anything to the project it would be necessary that
> that person knew how it worked and knew to use it, which isn't all
> that realistic due to the project's lack  of documentation.

You're forgetting it's open source.  You can learn how to use it and
all the details you need to write a documentation by just reading the
sources.


-- 
__Pascal Bourguignon__

Pascal J. Bourguignon wrote:
) Rui Maciel <rui.maciel@gmail.com> writes:
)> I would gladly contribute if that was a realistic option, let alone
)> a reasonable suggestion. As you are  aware, the main problem
)> plaguing ECL is the fact that the project's appalling documentation
)> makes it  virtually impossible to learn how to use it, much less
)> rely on it to perform any task. So, how do you expect  someone to
)> contribute documentation if it isn't possible to learn how to use it
)> to begin with? As you  understand, in order for someone to be able
)> to contribute anything to the project it would be necessary that
)> that person knew how it worked and knew to use it, which isn't all
)> that realistic due to the project's lack  of documentation.
)
) You're forgetting it's open source.  You can learn how to use it and
) all the details you need to write a documentation by just reading the
) sources.

You forgot the smiley to indicate you were being sarcastic.

HTH, HAND


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Pascal J. Bourguignon wrote:

> You're forgetting it's open source.  You can learn how to use it and
> all the details you need to write a documentation by just reading the
> sources.

....which demands an ungodly amount of time and effort, more so for a newbie both at ECL and Lisp, to tackle. 

So, to remind what's the case in point, when comparing three candidate software packages to adopt as a 
fundamental part of an application, if the best documentation that one of those candidates has to offer is a 
deep, convoluted and time-wasting source code analysis (which must be done by someone who isn't familiar with 
both the software package and the programming language it tries to implement) then that option isn't much of 
an option to begin with. 

And it's a real shame. Lisp is a very interesting language and it appears it's being held down due to a 
serious lack of effort at providing documentation for key software packages.


Rui Maciel

Rui Maciel <rui.maciel@gmail.com> writes:

> Pascal J. Bourguignon wrote:
>
>> You're forgetting it's open source.  You can learn how to use it and
>> all the details you need to write a documentation by just reading the
>> sources.
>
> ...which demands an ungodly amount of time and effort, more so for a
> newbie both at ECL and Lisp, to tackle. 

Of course.  In the process of applying this amount of time and effort,
any newbie becomes a confirmed lisp programmer.   Therefore it's a
task that is indeed totally impossible to complete by a newbie :-)


> So, to remind what's the case in point, when comparing three
> candidate software packages to adopt as a  fundamental part of an
> application, if the best documentation that one of those candidates
> has to offer is a  deep, convoluted and time-wasting source code
> analysis (which must be done by someone who isn't familiar with
> both the software package and the programming language it tries to
> implement) then that option isn't much of  an option to begin with. 
>
> And it's a real shame. Lisp is a very interesting language and it
> appears it's being held down due to a  serious lack of effort at
> providing documentation for key software packages.

Any time you're CEO of a company with as much resources as Sun (Java),
Microsoft (C#) or Apple (Objective-C), you may finance the commercial
development of Lisp, along with all the documentation writting needed
and all the evangelizing needed to have millions of programmers, of
web forums, etc.

In the meantime, there is only one option: do it yourself!

-- 
__Pascal Bourguignon__

On 24 Oct, 19:01, Rui Maciel <rui.mac...@gmail.com> wrote:
> Pascal J. Bourguignon wrote:
> > Indeed. =A0Perhaps you could contribute some more documentation?
>
> I would gladly contribute if that was a realistic option, let alone a rea=
sonable suggestion. As you are
> aware, the main problem plaguing ECL is the fact that the project's appal=
ling documentation makes it
> virtually impossible to learn how to use it, much less rely on it to perf=
orm any task. So, how do you expect
> someone to contribute documentation if it isn't possible to learn how to =
use it to begin with? As you
> understand, in order for someone to be able to contribute anything to the=
 project it would be necessary that
> that person knew how it worked and knew to use it, which isn't all that r=
ealistic due to the project's lack
> of documentation.

try an embeddable scheme instead? You get a nice simple script
language which you pile other stuff on top of if your users don't like
brackets.

Gambit and chicken are allegedly easy to embed. Is guile still active?

> From: Rui Maciel <rui.mac...@gmail.com>
> I'm planning on developing an application which I intend to be
> heavily scripted (and scriptable).

I'll need at least one use case of what you call "scripting" before
I even know what you're talking about. Will it be like writing a
program in something like PHP, or will it be more like the
instructable robot research I did at IMSSS about 25 years ago?

Robert Maas, http://tinyurl.com/uh3t wrote:

> I'll need at least one use case of what you call "scripting" before
> I even know what you're talking about. Will it be like writing a
> program in something like PHP, or will it be more like the
> instructable robot research I did at IMSSS about 25 years ago?

Are you familiar with autocad?


Rui Maciel

"Rui Maciel" <rui.maciel@gmail.com> wrote in message 
news:4ae20fc3$0$32343$a729d347@news.telepac.pt...
> I'm planning on developing an application which I intend to be heavily 
> scripted (and scriptable). I also
> intend to implement a small command line interface, in the excellent 
> tradition of autocad, in order to make
> the application more user-friendly and take advantage of it's scripting 
> features.
>
> With that objective in mind, I've started gathering the app's requirements 
> and evaluating some APIs and
> components. Nonetheless, I'm having a bit of trouble putting down the 
> basic design for the command line
> interface. The first option that came to mind was to use the command line 
> interface as a direct interface of
> the scripting engine, similar to how programs such as maxima, octave and 
> the typical dynamic programming
> language interpreter. Nonetheless, I'm not sure if it that's a reasonable 
> thing to do and if it wouldn't be
> better to separate the scripting side of it from the command line 
> interface.

I found it easier to have two languages:

* Command language that the user types in
* Scripting language used behind the scenes

Now the scripting language can be more shophisticated, and you can probably 
import one from somewhere (although I created my own), and the command 
language can be ultra-simple and with a syntax suitable for non-programmers.

If it's anything like Autocad then you can probably knock something together 
fairly quickly, although it's not that trivial as you may need to implement 
expressions, enter points (and other special data of your appl), have 
variables of some sort, and probably macros (eg. linked to function keys and 
the like). This stuff can also be stored in a file to create simple 
scripting.

All that's then needed is one command such as "exec" which links in to the 
scripting language proper when real work needs to be done.

Whatever you do, don't inflict Lisp or it's variants (or, to be fair, most 
languages) on your users!

-- 
Bartc 

"bartc" <bartc@freeuk.com> writes:

> "Rui Maciel" <rui.maciel@gmail.com> wrote in message
> news:4ae20fc3$0$32343$a729d347@news.telepac.pt...
>> I'm planning on developing an application which I intend to be
>> heavily scripted (and scriptable). I also
>> intend to implement a small command line interface, in the excellent
>> tradition of autocad, in order to make
>> the application more user-friendly and take advantage of it's
>> scripting features.
>>
>> With that objective in mind, I've started gathering the app's
>> requirements and evaluating some APIs and
>> components. Nonetheless, I'm having a bit of trouble putting down
>> the basic design for the command line
>> interface. The first option that came to mind was to use the command
>> line interface as a direct interface of
>> the scripting engine, similar to how programs such as maxima, octave
>> and the typical dynamic programming
>> language interpreter. Nonetheless, I'm not sure if it that's a
>> reasonable thing to do and if it wouldn't be
>> better to separate the scripting side of it from the command line
>> interface.
>
> I found it easier to have two languages:
>
> * Command language that the user types in
> * Scripting language used behind the scenes
>
> Now the scripting language can be more shophisticated, and you can
> probably import one from somewhere (although I created my own), and
> the command language can be ultra-simple and with a syntax suitable
> for non-programmers.
>
> If it's anything like Autocad then you can probably knock something
> together fairly quickly, although it's not that trivial as you may
> need to implement expressions, enter points (and other special data of
> your appl), have variables of some sort, and probably macros
> (eg. linked to function keys and the like). This stuff can also be
> stored in a file to create simple scripting.
>
> All that's then needed is one command such as "exec" which links in to
> the scripting language proper when real work needs to be done.
>
> Whatever you do, don't inflict Lisp or it's variants (or, to be fair,
> most languages) on your users!

Some users like lisp!

But my suggestion was rather that once you've hooked lisp in your
application, you can easily add any language you want.

For example, once you have lisp, you can hook in a command-key
language, like in emacs (which is actually a lisp system, but users
just type keys to insert text and command keys to run commands).



For example, one thing that is often disliked by naive users is the
need to put parentheses around toplevel forms.  You can easily write a
REPL that doesn't require these parentheses.  Any command languages
can be easily, most often trivially, implemented in lisp.


C/USER[400]> (defun plrepl () 
               (loop
                    for form  = (progn
                                  (format t "~%> ")
                                  (read-from-string (format nil "(~A)" (read-line))))
                    until (equalp form '(quit))
                    do (print (eval form))))
PLREPL
C/USER[401]> (+ 1 2 3) #| the lisp way |#
6
C/USER[402]> (plrepl)

> + 1 2 3             #| the parenthesis-less way |#

6 

> defvar x 42

X 
> / x 2

21 
> defun draw-rectangle (x y w h) "Draw some rectangle" #|...|# 'drawn

DRAW-RECTANGLE 
> draw-rectangle 0 0 100 50

DRAWN 
> quit

-- 
__Pascal Bourguignon__

bartc wrote:

> I found it easier to have two languages:
> 
> * Command language that the user types in
> * Scripting language used behind the scenes
> 
> Now the scripting language can be more shophisticated, and you can
> probably import one from somewhere (although I created my own), and the
> command language can be ultra-simple and with a syntax suitable for
> non-programmers.
> 
> If it's anything like Autocad then you can probably knock something
> together fairly quickly, although it's not that trivial as you may need to
> implement expressions, enter points (and other special data of your appl),
> have variables of some sort, and probably macros (eg. linked to function
> keys and the like). This stuff can also be stored in a file to create
> simple scripting.
> 
> All that's then needed is one command such as "exec" which links in to the
> scripting language proper when real work needs to be done.

The main point behind the idea of relying on the scripting language as the command language was avoiding 
having to develop a new language from scratch, along with all that work involved in writing a small 
interpreter. Moreover, it would be nice if the users only had to "wrap their heads around" a single, uniform 
way of doing things which, as I intend to make it as easy as possible to contribute scripts, hopefully would 
help users get the hang of it. Hopefully.


> Whatever you do, don't inflict Lisp or it's variants (or, to be fair, most
> languages) on your users!

I've started to realize that Lisp is in fact a surprisingly poor choice for a scripting language. The 
language itself may be elegant and may be even established as an international standard but that doesn't do 
anyone any good if the only tools available are practically unusable and unimplementable. But then again, 
there must be a reason why virtually no one relies on them to do this sort of stuff.

But in that case what scripting language would you suggest? At the moment Lua appears to be a good choice.


Rui Maciel

Pascal J. Bourguignon wrote:
> "bartc" <bartc@freeuk.com> writes:
>
>> "Rui Maciel" <rui.maciel@gmail.com> wrote in message
>> news:4ae20fc3$0$32343$a729d347@news.telepac.pt...
>>> I'm planning on developing an application which I intend to be
>>> heavily scripted (and scriptable). I also
>>> intend to implement a small command line interface, in the excellent
>>> tradition of autocad, in order to make
>>> the application more user-friendly and take advantage of it's
>>> scripting features.

>> I found it easier to have two languages:
>>
>> * Command language that the user types in
>> * Scripting language used behind the scenes
....
>> Whatever you do, don't inflict Lisp or it's variants (or, to be fair,
>> most languages) on your users!
>
> Some users like lisp!

I haven't ruled out Lisp for internal use, but for a command language for 
use by non-programmers it might be better to use something else or disguise 
it.

The user doesn't care how the command language is implemented, if he even 
thinks about it.

I'm assuming the application is nothing to do with programming..

-- 
Bartc 

Pascal J. Bourguignon wrote:

> Some users like lisp!

Not many, you must agree. 


> But my suggestion was rather that once you've hooked lisp in your
> application, you can easily add any language you want.

You must agree that although it may be a cool trick to brag about in practical terms that is a bit 
irrelevant. In fact, autodesk recently added a visual basic interpreter to autocad, one (if not the) prime 
example of practical, real world applications of Lisp as a scripting language. Yet, did they implement VB 
over AutoLisp?


Rui Maciel

Rui Maciel <rui.maciel@gmail.com> writes:

> Pascal J. Bourguignon wrote:
>
>> Some users like lisp!
>
> Not many, you must agree. 
>
>
>> But my suggestion was rather that once you've hooked lisp in your
>> application, you can easily add any language you want.
>
> You must agree that although it may be a cool trick to brag about in
> practical terms that is a bit  irrelevant. In fact, autodesk
> recently added a visual basic interpreter to autocad, one (if not
> the) prime  example of practical, real world applications of Lisp as
> a scripting language. Yet, did they implement VB  over AutoLisp?

I don't know how they did it.

Do you have the same resources as the AutoCad editor to add new
scripting languages to your program?  Perhaps for you it would be more
cost efficient to write your scripting language layers  in lisp rather
than having to do them in C?

-- 
__Pascal Bourguignon__

Rui Maciel wrote:
> bartc wrote:
>
>> I found it easier to have two languages:
>>
>> * Command language that the user types in
>> * Scripting language used behind the scenes
>>
>> Now the scripting language can be more shophisticated, and you can
>> probably import one from somewhere (although I created my own), and
>> the command language can be ultra-simple and with a syntax suitable
>> for non-programmers.
>>
>> If it's anything like Autocad then you can probably knock something
>> together fairly quickly, although it's not that trivial as you may
>> need to implement expressions, enter points (and other special data
>> of your appl), have variables of some sort, and probably macros (eg.
>> linked to function keys and the like). This stuff can also be stored
>> in a file to create simple scripting.
>>
>> All that's then needed is one command such as "exec" which links in
>> to the scripting language proper when real work needs to be done.
>
> The main point behind the idea of relying on the scripting language
> as the command language was avoiding having to develop a new language
> from scratch, along with all that work involved in writing a small

>> Whatever you do, don't inflict Lisp or it's variants (or, to be
>> fair, most languages) on your users!
>
> I've started to realize that Lisp is in fact a surprisingly poor
> choice for a scripting language. The language itself may be elegant
> and may be even established as an international standard but that
> doesn't do anyone any good if the only tools available are
> practically unusable and unimplementable. But then again, there must
> be a reason why virtually no one relies on them to do this sort of
> stuff.
>
> But in that case what scripting language would you suggest? At the
> moment Lua appears to be a good choice.

My main point was that the command language (the one typed at the command 
prompt) and the scripting language can be distinct.

In that case the command language can be simple enough to just write a 
parser for. It depends what sophistication is needed.

A proper scripting language is a lot of work and I wouldn't recommend 
creating your own, even though that's what I do myself.

As for recommendations... Python seems quite popular, and I think can be 
used both ways (embed your application in Python, or vice-versa). But I 
haven't tried it!

-- 
Bartc 

bartc wrote:

> My main point was that the command language (the one typed at the command
> prompt) and the scripting language can be distinct.
> 
> In that case the command language can be simple enough to just write a
> parser for. It depends what sophistication is needed.
> 
> A proper scripting language is a lot of work and I wouldn't recommend
> creating your own, even though that's what I do myself.

Acknowledged. 


> As for recommendations... Python seems quite popular, and I think can be
> used both ways (embed your application in Python, or vice-versa). But I
> haven't tried it!

Bummer. It appears that embedding scripting languages in applications isn't something which is very popular.


Thanks for the help.
Rui Maciel

Pascal J. Bourguignon wrote:

> Do you have the same resources as the AutoCad editor to add new
> scripting languages to your program?  Perhaps for you it would be more
> cost efficient to write your scripting language layers  in lisp rather
> than having to do them in C?

Honestly, I hope I'll never have to do that. Nonethelss, I have to agree that, at least at first sight, it 
does appear that implementing a new scripting language on top of the pre-existing Lisp interpreter, 
particularly on top of a decades-old, time-tested interpreter such as Autocad's, would probably save a lot of 
time and effort, at least in short-term. On the other hand, I would be surprised if Autocad's VB interpreter 
was built in-house instead of just plugging in some component they bought from some company.


Rui Maciel

> From: Rui Maciel <rui.mac...@gmail.com>
> Are you familiar with autocad?

Just barely. During the first year after I got laid off from my job
at Stanford (technically not laid off, just that the 5-year
             contract was finished and Stanford couldn't get any
             new contracts so they had to let *everyone* go except
             the head boss and my supervisor, then a year later the
             head boss Patrick J. Suppes *retired* and shut down
             IMSSS so my former supervisor lost his job too)
one of the job interviews I got was to code for the underlying Lisp
inside AutoCAD. The company used AutoCAD to design custom vacuum
manifolds for some research project(s). The client would specify
the size of the manifold from a set of standard sizes known, and
would specify the location and sizes of the various orfices, such
as to connect a vacuum hose or an instrument or a gas feed or a
particle accelerator or a mechanical manipulator or a viewing
window or a hatch for loading/unloading the main experimetal
apparatus etc., and then my job would be to convert those specs
into Lisp, and I'd view the stereoscopic computer model to verify
it agreed with the original specs (i.e. to check if I made any
mistake with conveting to Lisp notation), and then AutoCAD would
generate the instructions for drilling all the holes automatically
by robotic machinery.

The interviewer kept telling me the job would be really boring
compared to my previous job (5 years to create software to teach
first-year calculus to high-school students), and I responded that
it didn't bother me, that I'd do the job just fine. I thought I got
my point across that I was eager to get the job, but I didn't want
to be rude to him like busting him in the face the next time I had
to hear him called the job "boring" again. After the interview I
waited patiently for him to decide to hire me, but I never got a
second interview or a job offer or any further contact whatsoever
from that company, so I never got any idea why he didn't pick me
for the job. Since that interview, I've continued to be unemployed,
18 years so-far except for a brief 2.5 weeks about a year after
that interview, and I'd still take a job like that if offered to
me, but it was never offered. Some employers are such *turds*!!
Maybe it's time I look in my notes to see what company that was and
go there and see if that turd is still there and bust him in the
face hard enough to remove some of his teeth.

That's the only Lisp-related job opening I ever found in 18 years
of unemployment, so it's high time I stop being such a fucking
pacifist and use some VIOLENCE against that turd.