>===== Original Message From Pete Hornsby <[EMAIL PROTECTED]> =====
>>> I'm not exactly clear what "end user programming" is.
>>> If a physicist, who would strongly object to being called a
>>> programmer, writes a 15,000 line program in FORTRAN 2000
>>> to solve a physics problem, is that end user programming?
>>
>>IMO Yes.
I'm not so sure
>>> If I write an Excel script to manage my expenses, is that
>>> end user programming? [I am employed writing programs for
>>> other people to use.]
>>
>>IMO Yes.
I'd agree.
The distinction here may in part be intention...
To me, EUP implies that
1) there is a set of programming tools that extend functionality of an
application (e.g. a spreasheet) for which "producing" a program is not a
primary objective. This distingushes the Fortran case since the intention of
a programming language/environment is to enable (programmers!) to produce
programs.
2) there is an underlying assumption that those programming tools are provided
as part of the package - not an add-on that is purchased separately. In the
case of the spreadsheet, the macro/scripting language and tools and be
considered an integral part of the package. This may be a weaker argument.
3) there is no "protection" against the user discovering the existence
programming environment by investigating the menus (and help system). Again
this is a question of availability.
I don't think that the title "programmer" is relevant. I'm also not sure that
the fact that the physicist is using his/her own program is a major factor
here - I develop spreadsheet scripts both as an end-user (i.e. my goal is to
produce my expense report) and as a software engineer (my goal to produce
programs that others use). Of course, I could be mixing up with the
expert/novice programmer distinction :-)
----------------------------------------------
Ron Newsham - Armillary Ltd
