<problems@[EMAIL PROTECTED]
> wrote in message news:
1206602682.569499@[EMAIL PROTECTED]
>> 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 ?
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.
>> > Perhaps java-programmers do this by 'browsing' the methods of classes
?
>>
>> 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.
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 :-)?
>> > Does it work ?
>>
>> 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'.
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
>> > Perhaps java-programmers do this by 'browsing' the methods of classes
?
>>
>> 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 im****tant 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 im****tant 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 incor****ate 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
|
