[erlang-questions] What about making sense?
Sat Feb 20 19:21:07 CET 2010
On Viernes, 19 de Febrero de 2010 08:10:41 Michael Turner escribió:
> Kenneth Lundin writes:
> "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."
> If in fact it makes perfect sense, why have so many smart people found it
> so confusing?
Admitely, it takes a few reads of the entire docs, to start making your mind
around the applications concept, specially for newbies...
In fact you spect to find some kind of runtime ala Java but you end noticeing
that erlang has a sort of ecosystem where you have truly living creatures and
not just libraries of clases and functions...
IMHO you'll get the whole picture when you start seeing the erlang dist as a
tiny OS on top of your OS.
> Calling a generic library an application makes no sense at all to me.
> One *applies* library functions to practical problems, in the process of
> building software, typically resulting in *programs* that are
> applications. Erlang/OTP's use of "application" to mean all these
> different things bears no relation to its use by the overwhelming
> majority of software engineers.
> If you don't believe me, try testing your TOC out on real learners.
> Give two different groups of programmers different TOCs, one perhaps as
> I have suggested, the other as it currently exists. Ask them, "which
> link would you click first, to try to find stdlib, the Erlang Standard
> Is it so hard to predict the result? With yours, they won't click Basic
> Applications, because stdlib is not an application in any ordinary sense
> they know. Categorizing it as a Basic Application wont' make "perfect
> sense" to them, in fact, will make no sense at all to them.
> "Application" in the Erlang/OTP sense is something most experienced
> programmers must learn, and be reminded of (especially since in OTP
> it's usually something you can start and stop, but in other cases just
> a regular Erlang library, and in yet other cases, not even that. And if
> I'm to believe the much more experienced Jayson, "application"
> actually has *even more* different meanings in Erlang/OTP.)
> Please don't pretend there's no difficulty here. Forthright
> admissions, early and often, that Erlang uses "application" in a
> highly unusual sense (*senses*, actually) would go a long way toward
> helping mere mortals get used to it.
Still when you begin mastering a bit the whole picture you find a enourmous
gap between the management of and erlang applications and a classic OS
Packaging and integration poses a real challenge when you leave the safe
asumptions of the "embedded" smells erlang has.
> Saying there's no real problem sounds, well ... just what kind of
> attitude is conveyed by a sentiment like "Words mean what we say they
> mean, and if you couldn't easily find *where* we defined, precisely and
> completely, what they mean, that's not our problem"?
> Would you want someone with that attitude working on documentation YOU
> were trying to understand?
Maybe there are funny people and like to scare poor newbies up to death! :-)
> -michael turner
> On 2/18/2010, "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".
> >>> 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
> >> 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
Most people know C is not so high level....
...Everybody else just got assembler overdose
More information about the erlang-questions