[erlang-questions] What about making sense?

[Michael Turner]

Well, it seems I was wrong about a marketing *origin* for the use of the
term "application" in Erlang/OTP.  But now that I know that "OTP
application" is the basic unit of *sales and support* for Erlang/OTP,
it certainly makes sense that marketing imperatives would perpetuate the
use of the term, even if some elements of Erlang/OTP sold under that
rubric don't actually conform to Erlang/OTP's own definition of
"application".  At this point, I guess it would just cause customer
confusion (at some not very technical level, of course) to say something
like this:

  "Well, sorry, but a few of the things we've been selling to you all
along aren't actually applications, even in our own terms, but rather
just libraries.  But there's no loss of functionality in describing
these things in more conventional terms.  There's actually a slight
gain in programmer educability, if you care about that.  You're still
getting all the same things.  Which you were happy enough with, up to
the present day, right?"

No, somebody on the customer side would make an issue of it, a bargaining
point.  That's just how business people are: always looking for
leverage in negotiations, present and future.

I've experienced worse.  I remember once having the term "rapid
prototyping" expunged from a presentation I'd prepared.  The
explanation was that the key person with the most signature authority in
the presentation's intended audience had once been sold on a "rapid
prototyping" project that ended up taking 3 years and 20 programmers to
complete.  "But," I spluttered, "that's not rapid prototyping!" 
Guess what?  It didn't matter.  They couldn't afford to spook the guy.
 They substituted some other term.

I've also seen better: A telecom network management software company I
worked for under contract a few times used the blanket term "services
package" for its software products  So, for example, their whiz-bang
super-buzzword-compliant persistent object store was called OSP - Object
Services Package.  Pretty vague term, perhaps, but at least not actually
wrong.  After all, it was a batch of software tools and middleware with
a C++ API for objects stored in the RDBMS of the customer's choice.  It
was a package of library functions, and it had server software and
interfaces that you started and stopped.  At that
critically-important-but-maddeningly-ignorant bureaucratic level where
people in corporations sign for purchases they don't understand, the
word "services" sounded mighty good, especially when all wrapped up in
a "package."  As for "objects", well, they're all over these
magazine covers, y'see, so nobody's going to get fired for following
that crowd.

-michael turner

On 2/19/2010, "Joe Armstrong" <erlang@REDACTED> wrote:

>On Thu, Feb 18, 2010 at 10:27 PM, Kenneth Lundin
><kenneth.lundin@REDACTED> wrote:
>> On Wed, Feb 17, 2010 at 4:52 PM, Michael Turner <leap@REDACTED> wrote:
>>>
>>>
>>> On 2/17/2010, "Robert Virding" <rvirding@REDACTED> wrote:
>>>
>>>>Without getting into the discussion how difficult, or not, it is to
>>>>navigate the Erlang docs one source of the problem is that all the
>>>>standard OTP libraries are proper Applications.
>>>
>>> People should think of the trigonometric functions as part of the STDLIB
>>> Application, just because gen_server is grouped in with them, in stdlib?
>>>
>>> What sense does this make?
>>
>> I agree with you in that the documentation can be improved with better
>> descriptions and more examples and guidelines. There is also need for
>> good search facilities. We are working on both and we are releasing
>> the complete documentation sources plus support to build the doc. The
>> purpose with this is to make it possible for the community to help us
>> improve the docs.
>>
>> I don't agree at all when you criticise the organization in :
>> Toplevel System documentation plus all the "applications".
>> Already on the introduction page at top-level (http://erlang.org/doc) it says
>> "Erlang/OTP is divided into a number of OTP applications. An
>> application normally contains Erlang modules. Some OTP applications,
>> such as the C interface erl_interface, are written in other languages
>> and have no Erlang modules. "
>>
>> As everything is organized as "applications" in the source code tree
>> and applications actually are
>> groups of modules which are released and upgraded together it makes
>> perfect sense to structure the
>> documentation the same way.
>>
>> An application can be a service that can be started and stopped or it
>> can be a library of passive modules with functions it does not matter.
>> The important thing is that an application is the smallest unit we
>> handle when it comes to deliverables. We always provide a complete new
>> version of a full application including documentation when we release
>> binary patches.
>> The documentation is treated the same way as code and is released
>> together with the code to assure
>> that you always have the documentation corresponding to the code.
>>
>> Our experience is that this is a very efficient way to handle
>> documentation. We have no intention to change this. The documentation
>> can and will be improved anyway.
>>
>> STDLIB and Kernel are unfortunately 2 basic (core) applications with a
>> very mixed content.
>> The criterias for what's in Kernel and what's in STDLIB ?are unclear ,
>> we have discussed to
>> reorganize them some day but it has not been important enough to do
>> it. It will also introduce
>> potential incompatibilities.
>>
>> Regarding the name "application" I think it is somewhat unfortunate
>> since everyone has an own idea
>> about what an application is in general. For example in Ericsson an
>> "application" is a complete product sold to end users. In Erlang it is
>> a group of modules handled together, possibly started as a service. I
>> think you have to blame Joe for naming it "application".
>
>I'm guilty - but we had to give these "things" a name so we could talk
>about them. We could have called them glurks - "a glurk is a ..." but
>this would be crazy. The nice thing about natural language is that the
>meaning of a word is context dependent - so in the Erlang context
>Application means "...". Now were Erlang to become wildly popular, to
>the point where everybody lived breathed and dreamed Erlang dreams,
>then the Erlang use of the world Application would become the de.
>facto. standard and any other uses of the world would be viewed
>suspect.
>
>Another bad word is "lists" - the things we call lists are not lists, they
>are *stacks* if T is a stack then [H|T] is a new stack formed by pushing
>H onto the stack.
>
>Stack is a much better word than list.
>
>"Kenneth - get your guys to stop what they're doing and change
>all the use of the word stack to lists - and change all the modules
>that use the world lists - from now on lists are stacks."
>
>"Sorry Joe, we have a problem,
>the guys don't stacken to what I say"
>
>Sure there are problems with the terminology - did I say "problems"
>
>"Sorry Guv I meant 'issues',
>"Did you mean 'challenges?'"
>"Nnnn nnno .. 'Opportunities'
>
>/Joe
>
>
>
>>>
>>>> So when when the
>>>>documentation is organised around "applications", in one sense, it is
>>>>being entirely logical and consistent. Of course, until you are more
>>>>experienced and groked this it can be very confusing and difficult to
>>>>find things.
>>>
>>> But in the meantime, conceptual/terminological confusion impedes the
>>> learner, whenever he/she needs to resort to the Reference Manual. ?Given
>>> that Erlang already poses quite a learning curve for some, this will
>>> reduce the rate at which people become "more experienced and grok
>>> this", and for that matter, it will reduce the number of people who
>>> even want to get that far with Erlang.
>>
>> I don't really understand what you mean are the
>> conceptual/terminological confusions except maybe
>> application.
>>
>>>
>>> What sense does this make?
>>>
>>> What goal does this serve?
>>>
>>> The goal of making it easier to autogenerate the documentation?
>>
>> I don't understand what you mean here. Most of the documentation 95%
>> is handwritten.
>> We strongly believe in single source and many generated presentations
>> but this has no negative
>> impact on the actual documentation.
>>
>>
>>>
>>> Well, I remember the days when we humans did a lot of things to make life
>>> easier for the system. ?As I recall, it involved punching a lot of cards.
>>>
>>>
>>> -michael turner
>>>
>> /Kenneth, Erlang/OTP Ericsson
>>>
>>>
>>>
>>> ________________________________________________________________
>>> erlang-questions (at) erlang.org mailing list.
>>> See http://www.erlang.org/faq.html
>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>>
>>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>