real world problems vs. abstract problems - distinctions? policy?

real world problems vs. abstract problems - distinctions? policy?

[MON KEY]

One often encounters certain like or similar terms/phrases w/re Emacs
bugs, errors, (mis)interpretations of functionality etc. which hinge
on party-A's dismissal of party-B's understanding/interpretation of a
problem as being somehow not of the "real world". Presumably the
counter to a "real world problem" is a problem which occurs as an
"abstract problem".

I'm interested to learn how with regards Emacs and Emacs development
this distinction between "real world problems" and "abstract problem"
is understood by the emacs-devels and to inquire for some informal
public policy which exposes what the emacs-devels collectively
understand these distinctions to entail.

As an exercise I drafted the following as an attempt to clarify how a
problem moves through the collective emacs-devel community.

----

An 'abstract problem' is one in the set of problem types which are not
immediately recognizable as constituting a 'real world problem'.

These include (but are not limited to) those types of problems termed:
'dismissible', 'un-producable', 'un-verifiable', 'unprofitably
addressable', 'addressably unprofitable', 'bikeshedably prolongable',
'prolongably bikeshedabe', 'license terms puntable', 'user un-visble',
'un-fixable', 'breakably fixable', etc.

The extent, temporal specificity, and locality (whether purely abstract
or formally syntactic), in which the set of 'real world problem'
problem types is said to contain a particular 'abstract problem' need
not be formally specified with the informal caveat that in order for
an 'abstract problem' problem type to transition into the set of 'real
world problem' types it may do so iff it is enclosed by the scope of
those problematic types which are known to be either 'addressably
profitable' or 'profitably addressable'. When a 'real world problem'
is known to be either 'addressably profitable' or 'profitably
addressable' it can be said to have 'surfaced'. This is an important
distinction, an un-surfaced problem is not unlike the tree that falls
in the forest with no one around, it may make a noise but if no one is
their to hear it...

An exception to the above informal caveat is a more formal
(semi-formal?) constraint which guards against the informal
inclusionary conditional that an 'abstract problem' which is either
'addressably profitable' or 'profitably addressable' may become a
'real world' and surfaced problem type. This guard is placed around a
certain set (or sometimes subsets) of 'abstract problem' types which
intersect with one or more members of the set of problem types termed
'deficient implementation details'.

A 'deficient implementation detail' type is a problem type
characterized by one or more claims or assertions of problems arising
from a 'deficient implementation'. The veracity of such claims or
assertions being independent of whether the problem type's details,
implementation, and/or deficiency(ies) are existent and obvious, nor
whether any one or more of these be so for any one or more person(s)
party(ies), groups, factions etc.

A 'deficient implementation detail' problem type should not receive
consideration for inclusion among the set of other 'real world'
problem types until the addressable details of a particular 'defective
implementation detail' problem type are said to have surfaced.

Surfacing a 'deficient implementation detail' problem type involves
the following stages:

- an enumeration of the deficiency details is made indicating:
  -- observability, verifiability, reproducibility;
- a veracity of claim must be acknowledged
- a determination/disclosure of the problem
  -- 'addressable profitability' or 'profitable addressabilty'

For acknowledgment of a 'deficient implementation details' type
problem to occur an enumeration of the putative problem's
'defenciency details' must exist. Such an enumeration is said to
constitute the details of a 'deficient implementation'.

Enumeration of 'deficiency details' requires verifiability of one
or more deficiency detail.  A particular deficiency detail is said
to be verifiable if during normal execution at the user level the
detail of an implementation deficiency can be observed. A deficiency
detail is said to be observable at the user level iff all code
executed in the current user environment is free of both user written
code execution at the user level and/or execution of user-level code
changes to non user-level code. If it can be said that an observable
deficiency detail of an implementation deficiency is verifiable, then
the detail is said to be reproducible.  When an arbitrarily sufficient
number or amount of such deficiency details is enumerated the
cumulative effect is that a 'deficient implementation detail' can be
said to be reproducible.

Note however that reproducibility (whether cumulative or piece-wise)
of the details regarding a claim to a 'deficient implementation' does
not verify that the claim is correct nor that there is in fact a
problem only that the possibility of one may exist.

When a consensus of like minded overseers (this being comprised of
individuals with the requisite suitable experience commiserate for
inclusion among such a a peerage of the like minded) that a claim of
'deficient implementation detail' has veracity will an
acknowledgment of such be made known. Presumably at the collective
discretion of the peerage will dictate what is proper.  However, there
is no mandate that such an acknowledgment occur and any such
acknowledgment need not be shared outside the enclave of the peerage.

When the veracity of a claim of 'deficient implementation detail' is
made known or otherwise acknowledged, the peerage may at their
discretion, choose also to accompany the acknowledgment with an
informal statement, hint, or indication as to whether the problem type
was determined to be 'addressably profitible' or 'profitably
addressable' and possibly the extent to which this determination might
change according to unforeseen or unacknowledged mitigating
circumstance(s).

The above exploration of informal policy and its qualifiers:
"abstract problem", "dismissible", "real world", "obvious",
"deficient" "implementation", "detail", "profitable", "addressable",
"surface", "reproducible", and "user level" are intentionally left
unspecified.


--
/s_P\

Re: real world problems vs. abstract problems - distinctions? policy?

[Uday S Reddy]

On 10/4/2010 1:17 AM, MON KEY wrote:

> One often encounters certain like or similar terms/phrases w/re Emacs
> bugs, errors, (mis)interpretations of functionality etc. which hinge
> on party-A's dismissal of party-B's understanding/interpretation of a
> problem as being somehow not of the "real world". Presumably the
> counter to a "real world problem" is a problem which occurs as an
> "abstract problem".

No, not really.  The "counter to a real world problem" is a theoretical problem, i.e., a problem that exists in theory but doesn't arise in practice or arises so rarely that it is not worth the effort worrying about it.  It is a judgment call.  (It doesn't have to be.  You can produce evidence of real-world importance if you care to.)

Since Emacs is free software and the emacs developers are volunteering their time and effort, the onus is on the rest of us to convince them that a problem is important and worth their effort.  They don't have to convince anybody of anything.  If we think a problem is important, we are welcome to go and solve it ourselves!

Cheers,
Uday

Re: real world problems vs. abstract problems - distinctions? policy?

[Stefan Monnier]

> Since Emacs is free software and the Emacs developers are volunteering
> their time and effort, the onus is on the rest of us to convince them
> that a problem is important and worth their effort.

Actually, the same is true of software you pay for (maybe even more so,
since the commercial constraints forces coders to concentrate on
bugfixes with a clear monetary value, whereas volunteers may opt to fix
a purely theoretical bug simply because they enjoy doing it).


        Stefan

Re: real world problems vs. abstract problems - distinctions? policy?

[Uday S Reddy]

On 10/6/2010 12:47 AM, Stefan Monnier wrote:

> Actually, the same is true of software you pay for (maybe even more so,
> since the commercial constraints forces coders to concentrate on
> bugfixes with a clear monetary value, whereas volunteers may opt to fix
> a purely theoretical bug simply because they enjoy doing it).

Agreed.

However, commercial houses also have commercial pressures which might send them in directions that are not clearly aligned to monetary value.  Sun Microsystems, for instance, developed a lot of software out of "theoretical" interest.  Google might be doing the same but is perhaps better able to balance its theoretical and commercial interests.

Commercial houses also get revenue from their products and they can use it to employ people and splurge on "theoretical" issues which might or might not have immediate monetary value.  Microsoft apparently has 5th biggest citation counts in the world for computing-related research, which was kind of surprising to me when I discovered it.

Commercial houses have hierarchical management.  So, somebody higher up can be sold on a theoretical issue and get his/her people to work on it without concern for monetary benefit.  The general incompetence of management structures means that such "wastage" of resources might go unnoticed for a long time.

Come to think of it, commercial pressures or "market pressures", if you wish, are just as much at play in free software as in commercial software.  We compete with other free software for our users and our developers.  But we are less likely to waste resources in general because we don't have incompetent management structures and we don't have money to splurge.

But, the real reason I brought up the issue of free software in my response was that a commercial developer might feel an obligation to explain to his/her users why some issue isn't important.  A free software developer is under no such obligation.  He/she just develops whatever he/she enjoys doing.  That is the end of that!

Cheers,
Uday

Re: real world problems vs. abstract problems - distinctions? policy?

[PJ Weisberg]

On Wed, Oct 6, 2010 at 3:43 AM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
> But, the real reason I brought up the issue of free software in my response
> was that a commercial developer might feel an obligation to explain to
> his/her users why some issue isn't important.  A free software developer is
> under no such obligation.  He/she just develops whatever he/she enjoys
> doing.  That is the end of that!

If it's an issue of real-world vs. abstract problems the explanation
would have to be "this problem isn't important because you're not
actually experiencing it."  Steve Jobs himself would only be able to
get away with that one so many times. ;-)

PJ