>> 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.
>
>> 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.
Both seconded. EUP to my mind is centered around people whose main task is
not programming, performing programming tasks to aid their main job.
Definitions can be found at:
http://www.cs.uml.edu/~hgoodell/EndUser/Definitions.htm
I'd really distinguish EUP from 'professional' programming by the idea that
EUP programs are typically single-user and standalone; there is no notion
of sharing the program with someone else, it is just a convenient means of
getting a job done. The analogy is perhaps a quick hack to get a job done
by a systems admin (raising shields for incoming systems admin fire...).
>> I would argue that both of these are prefectly good examples
>> of end user programming. If my examples are acceptable,
>> then end user programming really has nothing to do with
>> issues such as specification versus design, etc. It merely
>> has to do with who the customer is.
>
>Right. The programmer is the "end user", the person who
>uses the system. The programmer's customer is herself.
>If that isn't the meaning of "end user programming", it
>should be, otherwise there's something rotten with the
>definition of "end user". I think the original discussant
>took aim at the "programming" part of EUP, drawing
>attention to how small a part of the overal development
>activity programming often plays.
Agreed. For professionals, design is an important part of the systems
development process. For EUP, it seems to be a case of 'jump in and hack'.
My concern is with how effective this can be. A lot of EUP environments
seem to be focussed towards teaching children the fundamentals of
programming. I think there is a question of whether this approach is
beneficial since presumably the child must hold all the problem information
in his brain, and in for larger problems, will be unable to do this. Of
course, if the goal is simply to interest the child, letting them produce
things quickly is one way to do this.
>Lots of people can program a system they use, including
>trained developers (e.g. writing customization scripts
>for Rational Rose). I would call Makefile writing EUP.
>Probably most professional developers are EU programmers.
>
>> If, on the other hand, end user programming can only
>> be done by people who have no experience in programming
>> in conventional notations, then the main thrust of end user
>> programming must be to reduce the amount of learning that has
>> to be done before useful work can be performed. If this is so,
>> ...
>
>I don't think its so. Obviously, less experienced programmers
>constitute an important segment of the end user population,
>hence the focus for research. I'd prefer to think that the
>issue of reducing learning requirements for programmers is
>an orthogonal issue to end user programming. How about making
>programmers with 6 months experience be as effective as the
>developer with 20 years (dreaming), or making the next language
>you learn masterable in an afternoon?
There are a lot of factors involved. A major thrust of EUP stuff is making
use of what the end user already knows - e.g. LabVIEW using electrical
notation. If the environment (the computer as tool, the notations
available, the pen and paper on the desk, etc.) is particularly suitable
for the task and the user (e.g. it fits well with the task and the users
way of working) then the user does not need to work as hard to get a job
done.
Some systems allow the user to record macros, and this sort of programming
by example is another form of EUP. The weakness with this is that what the
user is doing is not documented, and the user is limited to creating
programs within an existing framework. Unless, of course, he learns the
underlying language, which is moving him more towards conventional
programming and increasing his workload.
>> ...it would be interesting to characterize what
>> things a professional programmer absolutely needs to know
>> that an end-user programmer doesn't need to learn.
>> Ruven Brooks
>
>Yeah, www.swebok.org and computer.org/education/cc2001 would
>sure like to know. The corollary question is: if EUP becomes
>significantly easier for the untrained (play along with me
>here), what characterizes the things that universities and
>programmer certification courses will no longer need to teach?
I think there are definite limits on how much easier EUP can become.
Although I have expressed the view above of a more appropriate system
creation environment making the task easier for the human, the question
then arises of the number of environments that would be needed to help the
user fulfill all possible tasks - and I don't believe this is a realistic
scenario. I would however suggest that creating 'overlays' for traditional
programming languages might be beneficial. Java Studio was one such idea
which looked promising for a while, but was disontinued.
Pete
------------------------------------------------------------------------
Peter Hornsby,
Department of Computer Science
Loughborough University,
Loughborough,
Leicestershire,UK EMAIL:[EMAIL PROTECTED]
LE11 3TU. Tel: +44 (0)1509 222799
Fax: +44 (0)1509 211586
"The whole problem with the world is that fools and fanatics are always
so certain of themselves, and wiser people so full of doubts."
--Bertrand Russell
------------------------------------------------------------------------
