Re (2): 'canonical' library-set ?

Replying to Jason & H. S. Lahman

In article <4a331365-d48a-490e-b27f-525a874b7512@u10g2000prn.googlegroups.co
m>, "jason.cipriani@gmail.com" <jason.cipriani@gmail.com> wrote:

> I am not sure I understand what you are asking...
>
> On Mar 26, 3:01 am, problems@gmail wrote: 
>
> Are you thinking of something specific? Both the C standard runtime
> library and the Java runtime / component library (among many, many
> others -- just using those two as an example, since you mentioned them
> both) could be described as sufficient to do 'any' task.
> 
>
> Well, I mean, "navigating" the C and Java runtime libraries would
> consist of "reading the documentation"... unless you mean something
> else?
>
No ! you don't read the dictionary; you navigate it ?
 
>
> The Java API documentation is fairly well organized...
> 
>
> I think they do this by reading the documentation. If you mean
> browsing methods of classes programmatically, this is part of a
> feature called "reflection" -- some languages have this feature (such
> as Java), others do not... but I don't see how reflection helps you
> out here (what are you trying to do?).
>
Increase productivety, by AVOIDING dumb redundant reading.
 
>
> Depends on how good they are at reading. :-)
>
That's exactly what I'm trying to AVOID.
Think 2008 productive data-overload killer: you recognise
[not read] a token which by learned reflex directs you to a
1 of 8 selection selection, thereby reducing your search-space by
87% in 300 mSec ...etc. Like realtime battle/traffic navigation.

Not 1950s: sharpen your pencil, light up your cigarette and
get comfortable to 'read'.
============ replying to H. S. Lahman 
>
H. S. Lahman wrote:-
> Yes -- if you are programming in a procedural or functional language
> this sort of functional decomposition was the basis of Structured
> Development and it is the most intuitive way to build complex modules
> from atomic functional elements like language operators or library
> functions.
>
The 'to decompose or not' decision has already been taken.
I'm talking about TimeAndMotion of increasing productivety doing it.
 
>
> Not really. OO development uses a completely different paradigm for
> developing program structure. In fact, one can argue that the main goal
> of OO development is to avoid the hierarchical dependencies usually
> associated with functional decomposition. Instead, the OO paradigm
> creates software elements by direct abstraction of problem space
> entities and those elements collaborate on a peer-to-peer basis to solve
> the problem in hand. The browsers provided by the language IDEs are
> primarily a tool for navigating the program structure once it has been
> defined.
>
So what is the theoretical basis of these IDE browsers ?
Anything can be designed haphazardly or more formally/theoretically.
Since selecting the procedure/function is so important I'd expect
that there are studies/theories on how to arrange/structure the
selection mechanism.   Software development needs move
away from being an art towards being more formal.

After you've seen fifty different library-sets, all differently arranged,
with different elements, don't you ever think "what would be a
canonical arrangement" ?      Some standard ?

I use and sometimes modify/extend the ETH-Oberon OS/language
and when I look at the sources it seems that every 'application' has
eg. written it's own eg. Hex2Decimal routine because it was too
much trouble to use a single standard common routine.

== Chris Glur.

Responding to problems...

> ============ replying to H. S. Lahman 
> H. S. Lahman wrote:- 
> The 'to decompose or not' decision has already been taken.
> I'm talking about TimeAndMotion of increasing productivety doing it.

Trying to butter up a basic functional decomposition with OO trimmings
like classes won't help and it may result in the worst of both worlds.
 
> So what is the theoretical basis of these IDE browsers ?

They serve a human need to organize things. For example, when doing
maintenance it may be necessary to examine all the clients of a service
to ensure that they are not broken by a change to the service. A browser
that uses the language's syntax to identify all invocations of a changed
method makes life much easier for the developer...

> Anything can be designed haphazardly or more formally/theoretically.
> Since selecting the procedure/function is so important I'd expect
> that there are studies/theories on how to arrange/structure the
> selection mechanism.   Software development needs move
> away from being an art towards being more formal.

OTOH, in the OO paradigm one employs militant decoupling to minimize the
number of times it is *necessary* to check all the clients. For example,
one can use DbC to define contracts and if the change does not break the
contract, one doesn't need to evaluate the clients.

In the OO world one depends upon OOA/D methodologies to provide the
formalism that at least encourages getting things right and avoiding
pitfalls. That's why it is so important to understand OOA/D before
trying to code in an OOPL. If one goes directly from procedural
development to OOPL coding one will essentially get C or FORTRAN
programs with strong typing but precious little else in the way of
maintainability. And on the downside one might get a call graph that
would make a typical procedural program look like a paragon of simplicity.

> After you've seen fifty different library-sets, all differently arranged,
> with different elements, don't you ever think "what would be a
> canonical arrangement" ?      Some standard ?

That reflects a fundamental problem for any software. Any complex
semantics can usually be accessed by multiple different syntaxes. There
is no absolute basis for deciding one syntax is better than another and
the "best" syntax will largely depend on the specific problem context.

So one gets into situations where a new client for an old service wants
to use a different interface than the one provided by the service. They
are not at all  about the semantics of the service provided, but
they still can't communicate because they don't speak the same language.
Hence interface design is raised to an art form in all software
development arenas.

The OO paradigm can't solve that problem but it does provide some tools
and a design mindset than usually minimizes the difficulties by reducing
coupling. It also employs abstraction to capture the invariants of
service subject matters in their interfaces, which tends to make those
interfaces more reusable. The OO paradigm also raises data to have equal
stature with behavior and provides mechanisms for allowing them to play
together properly so that detailed differences can be expressed in data
while invariants are encoded in behaviors. IOW, the OO paradigm provides
better tools to solve the problem, but the developer still needs to bake
the cake.

[The categories "Application Partitioning" and "Invariants and
Parametric Polymorphism" on my blog provide some examples of how such a
methodological approach can at least minimize the scope of the problem
(e.g., the Bridge Model).]


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development".  Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

<problems@gmail> wrote in message news:
1206602682.569499@vasbyt.isdsl.net... 
> No ! you don't read the dictionary; you navigate it ?

Well, you would navigate the documentation before reading it;
"reading" the documentation, I guess, is the logical next step after
navigating it but I guess that may not apply to your problem. It
depends on what your end goal is... see next paragraph.
 
> Increase productivety, by AVOIDING dumb redundant reading.

How so? Redundant *reading* would be a consequence of poor
descriptions. The major redundancy in looking things up in
documentation is that you know what you are trying to find the
documentation for, but you must nonetheless search for it by hand
(e.g. I see a Forth word, I open a separate set of documentation [note
that I'm viewing documentation as simply a dictionary of item ->
description], I search for that same word -- it is not implicit in the
original word that I saw). The solution to this particular redundancy
comes in the form of tools that eliminate it -- for example, a Forth
development environment that displayed the documentation (i.e.
"dictionary entry") for the Forth word on the screen when you
positioned the cursor over the word.

What is the precise purpose of the dictionary you described? What end
goal are you trying to accomplish? Is it something that you want to
find programmatically? E.g. you want to write a Forth program that
looks up Forth words in a dictionary and displays the descriptions? Or
is it that you simply want information available to your brain, and
not necessarily to a Forth program (not considering the case where
your own brain is implemented in Forth :-)?
 
> That's exactly what I'm trying to AVOID.
> Think 2008 productive data-overload killer: you recognise
> [not read] a token which by learned reflex directs you to a
> 1 of 8 selection selection, thereby reducing your search-space by
> 87% in 300 mSec ...etc. Like realtime battle/traffic navigation.
>
> Not 1950s: sharpen your pencil, light up your cigarette and
> get comfortable to 'read'.

Would this not be addressed by working in a development environment
that took care of the navigation step for you? Such as the above
example of a Forth editor that automatically displayed the description
of a Forth word.

Of course, even that leaves some redundancy, if you wanted to get nit-
picky. If you are staring at the Forth word on the screen that you
want to find the description for, why must you also position the
cursor over it? The technology does exist to eliminate that as well,
for example, a head-mounted eye tracker can detect where you are
looking, and display the documentation for the word you are probably
looking at. Of course, that is not realistic, so you have to accept
some amount of redundancy. I am assuming that your goal is to have
information available to your brain. Are you talking about having this
information available to your own program?

In any case this also requires somebody to generate that dictionary of
word -> description. The developer would have to enter it by hand. The
only way to eliminate *that* would be to use Forth words that always
described exactly what they did; but then having to retype the
description of a word every time you wanted to use it may get to be a
nuisance after a few minutes. :-)

> ============ replying to H. S. Lahman 
> So what is the theoretical basis of these IDE browsers ?
> Anything can be designed haphazardly or more formally/theoretically.
> Since selecting the procedure/function is so important I'd expect
> that there are studies/theories on how to arrange/structure the
> selection mechanism.   Software development needs move
> away from being an art towards being more formal.

Most of these IDE browsers would aim to provide interfaces that
parallel the actual organization of the program, in OO programs, that
is. For example, a hierarchy of classes in code would be represented
as the same hierarchy in the browser's interface; typically a tree
with nodes representing classes and children/parents representing the
hierarchy defined by the program. There is really no other sane way to
do it (other than listing everything flat, and, say, alphabetically)
in this context, as an OO programmer already has that hierarchy in
mind, an OO parser is aware of it as well, and so it is most natural
for the browser to present the same organization (natural for both the
browser implementation, and for the programmer using it).

> After you've seen fifty different library-sets, all differently arranged,
> with different elements, don't you ever think "what would be a
> canonical arrangement" ?      Some standard ?

Where you are coming from is starting to become a lot clearer.

In fact, I do think this. And I agree. However, there are a *lot* of
factors to consider. To mention a small subset:

1) People very often have a tendency to reinvent wheels. This is for
many, many, many different reasons, not the least of which are a) the
empowerment some feel by doing things themselves, b) lack of knowledge
of existing ways (or lack of motivation to gain such knowledge), c)
lack of existing ways along with the inability to make (or
inconvenience of making) a new way standard. I believe that you are
well aware of these reasons, and in particular you are trying to solve
(b) and (c).  Much of (c) stems from the massive amount of languages
and options that are available for development -- for example, would a
standard SML specification and implementation for Hex2Decimal really
apply to a Java program? Other than the function having a similar name
[which isn't always possible either, consider the language Whitespace,
for example], there would not be much of a parallel between the two.

2) Language differences; which I just mentioned at the end of the last
paragraph.

3) Once a wheel has been reinvented, using the redundant method
becomes commonplace in whatever context it was developed in. It
becomes so integrated into other things, that it is no longer
realistic to try to make it conform to a standard way of doing things
once a standard is invented/discovered (as the case may be). In many
cases, conforming to a standard simply for the sake of consistency is
not, in fact, a compelling enough reason to make major changes to an
existing program. For example, if suddenly, today, Hex2Decimal become
"standard", but you had your own implementation that you have been
using for years (since before it was standard) in a very complex piece
of software, or in a library that others were already relying on, is
it *really* worth the effort to scrap your own implementation and go
for the standard?

> I use and sometimes modify/extend the ETH-Oberon OS/language
> and when I look at the sources it seems that every 'application' has
> eg. written it's own eg. Hex2Decimal routine because it was too
> much trouble to use a single standard common routine.

I think you are confusing two different things, however. Firstly,
there is the Hex2Decimal routine in language X. And every time you see
a program in language X, it seems that somebody has implemented their
own Hex2Decimal. This, viewed as an isolated case, is merely a
shortcoming of language X. It is not necessarily related to some
global standard. It is just like a spoken language -- if people are
constantly forming long phrases to describe a common idea, it's
probably about time to come up with a new word for that commonly
expressed idea. In the programming world, people frequently attempt to
solve this problem by coming up with their own libraries that simplify
repetitive code. Unfortunately, as you know, everybody has their own
ideas about what the libraries should be. However, it is important to
note that such libraries generally only exist to fill in gaps in the
language itself -- you will not find a library in C that contains a
utility function to, say, end a program, as such a function (exit())
is part of the C standard and is distributed with all compliant C
implementations. Therefore, these kinds of things are more shortcoming
of specific languages.

The thing you may be confusing this with, is a global standard of some
way of doing things that is independent of the language you are using.
However, this is not really feasible, as I mentioned above, there are
far too many differences between languages to have something like this
happen. What would be your goal in having such a global standard? If
your goal is to allow any programmer with knowledge of language A to
look at language B and immediately understand it -- well really what
you are attempting to do is transform language B into language A; in
that case the programmer should just stick with language A.

In other words, I think that it is not feasible to talk about such a
"canonical standard" on a global level. You have to consider it per
language. In that regard, work is being done in many languages to do
just that. Java has a rich set of standard components for performing
many tasks, while it is not "canonical" globally, it is certainly
"canonical" within Java itself. C++ also has a rich runtime-library
that is part of the language standard -- and in fact, the next C++
standard is going to incorporate a lot of new elements that have
typically been in the domain of third-party libraries in the past --
such as the inclusion of many concepts from the C++ library, boost, in
the language standard itself; also the new C++ standard will address
issues such as multithreading, which currently you must handle on a
per-platform basis, and so everybody and their brother has their own
"platform-independent" wrappers around these things (which is what I
was talking about above -- the task is so common that it is becoming
part of the language standard precisely so that all the independent
implementations can be removed).

Jason

On Mar 29, 12:34 am, "jason.cipri...@gmail.com"
<jason.cipri...@gmail.com> wrote:
> This, viewed as an isolated case, is merely a
> shortcoming of language X. It is not necessarily related to some
> global standard. It is just like a spoken language -- if people are
> constantly forming long phrases to describe a common idea, it's
> probably about time to come up with a new word for that commonly
> expressed idea. In the programming world, people frequently attempt to
> solve this problem by coming up with their own libraries that simplify
> repetitive code.

Heh, in fact, these could be compared to various dialects of a certain
spoken language, in which case it seems like you have a monster like
English, but what you really want is French. :-)