Priorities

[Laurent Martelli]

>>>>> "Tril" == Tril  <dem@tunes.org> writes:

    Tril> On Sat, 26 Dec 1998, Anders Petersson wrote (in
    Tril> unios@onelist.com):

    >> I was also thinking of "user" as the *final users* of the
    >> system, not developers. I think these two groups are so
    >> different in their needs that they should be separated from
    >> each other. The users could retain their place, while
    >> developers get a higher rank.

    Tril> Here is my philosophy.  Final users are the most important.
    Tril> They are the people who the system should be most convenient
    Tril> for.  The needs of users are so diverse that pre-packaged
    Tril> applications (written by someone else) can't always work.
    Tril> The best solution in every case is to get a program written
    Tril> specifically for that user, for the problem they have right
    Tril> then.  It only makes sense, then, to have the system assist
    Tril> users in creating programs to solve their problems.

Here's mine :

`Programmers' and `end-users' are both users of the system. A user is
an entity which wants something to get done by the system. A
programmer wants to provide new services to users, and end-users just
want to use those services but do not want to build new ones. The more
I think about it, the more I think that the two categories are a false
problem which arose because of bad design of known systems. End-users
usually do not want to build new services because it looks too
complicated to them. They'd have to deal with concepts that have
nothing to do with their application domain and what they want to
achieve. But if the could build new services just by specifying them
using concepts of their application domain, I am sure that they would
do it. (see the code vs specs threads). 

I don't think that we should consider these two arbitrary categories
of users in the design of the system. But I believe that different
users have different needs, and may not want to visualize information
in the same manner. But I postpone the problem in the GUI design
area : we should have a very customizable GUI, allowing different
users to visualize the same information in different ways.

    >> >> [Tril:] >> That means no C-like inability to check array
    >> boundaries (for example).  >> You CAN focus on stability in the
    >> initial design: use strong type >> checking, throughout the
    >> system.  This just means that operations are not >> allowed to
    >> operate on values that don't make sense.  I am currently >>
    >> developing a strong, integrated type system for TUNES, because
    >> I believe >> it is the center of the system.  There will be no
    >> kernel, just this type >> system.  All objects will take part
    >> in the type system (or they won't >> exist).
    >> 
    >> Is the quality of the programmers' code really something system
    >> developers can do anything about? How could it be?

    Tril> Language designers can do something about it.  At least,
    Tril> they can design languages that allow maximum expressibility,
    Tril> so the developer doesn't have to obfuscate the code to adapt
    Tril> it to the language.  This happens a lot in C because
    Tril> programmers have to completely reorganize their program for
    Tril> optimization.  That should be the job of the compiler.  Of
    Tril> course, I go much farther and say that the choice of "data
    Tril> structures", which are usually chosen for speed (linked list
    Tril> vs. arrays vs. trees etc), should be abstracted so the
    Tril> programmer doesn't need to decide, but the system can pick
    Tril> which structure to use for data.

Agreed.

But I don't believe in the concept of `killer-language' which solves
every problems. We always have new needs and therefore new problems,
so to me the killer-language is a simple language which is built
around the idea of extensibility. And the more I think about it, the I
think that Lisp-like languages fullfill the definition. Extensibility
is achieved by adding new functions. 

And the rest is dsign patterns ...

Laurent