[erlang-questions] Time for OTP to be Renamed?
Francesco Cesarini
francesco@REDACTED
Fri Feb 14 10:01:09 CET 2014
No, no no Thomas... You can not move away from OTP. It even has its
official music video:
http://www.youtube.com/watch?v=7VjYUnvnTog
On a serious note, I flagged the issues about the T in Telecom when
speaking at the Erlang User Conference in 2001. A company in France,
working on a Jabber proxy, did not use OTP behaviors or even look at the
documentation because they were not developing Telecom products. In the
book I'm co-authoring on OTP, the word Telecom will get one mention. In
the introduction, alongside a rant over why it is called that way. In
the rest of the chapters, it will be an acronym. (BTW, dealing with
management and those sitting on the budget on a daily basis, I agree in
full with Robert. A marketing hat would at times help).
Francesco
On 13/02/2014 18:54, Thomas Lindgren wrote:
> OK, if the acronym drives your managers nuts, fork it, rename it (how
> about "Blue Gorilla", "Customer Yacht" or "Uhuru Scalable Mountain")
> and write in the docs that it's based on OTP (tip: below the fold).
> I'm sure Erlang Solutions can sell your company Blue Gorilla training
> and contractors if you ask them.
>
> Best,
> Thomas
>
>
> On Thursday, February 13, 2014 7:16 PM, kraythe . <kraythe@REDACTED>
> wrote:
>
> I have read portions of your book and appreciate your insight.
> However, I think you underestimate the task here. Convincing
> developers may be difficult, but if they are good devs they might
> come around. Convincing management with control over budget and
> staffing when the naming is wrong? Nearly impossible. Thats why
> massive advertising companies have made billions off of just
> naming things correctly. All of the other concerns you posted are
> very legit and I have had and still do have many of them myself.
> But those concerns are at the tech level and only of minor
> interest to the manager wondering why would he staff for erlang
> and not scala or ruby?
>
> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/
> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/
>
>
> On Thu, Feb 13, 2014 at 12:05 PM, Fred Hebert <mononcqc@REDACTED
> <mailto:mononcqc@REDACTED>> wrote:
>
> Answers inline.
>
> On 02/13, kraythe . wrote:
> > I Guess my answers would be:
> > 0) If there is a business case, you can convince them. Low
> adoption hurts
> > their maintainability and staffing much more than it does
> for the startup
> > or small company. They are a business, not a bunch of
> unreasonable oafs.
>
> That may be doable. I'm not saying the opposite.
>
> > 1) Why rewrite the libs if you use the same initials. I
> wouldn't worry
> > about that. The programming world is replete with examples
> of such things.
>
> If we can use the same initials, then that's gained and
> removes a bunch
> of issues.
>
> > 2) and updating the docs will take ... 10 man hours? Do we
> not have search
> > and replace capable tools?
> > 3) Same answer as 2.
>
> Yes, but we do not have administration rights to mirrors, say
> http://erldocs.com/ and translations that can be hosted by the
> community.
>
> The work done with the OTP documentation goes further than the
> OTP team
> itself.
>
> > 4) Dont need to "make sure" of anything. If the books want
> to be accurate
> > they will use the new name, if not "shrug" thats their
> problem. Trust me
> > someone on amazon will post "Its not called Open Telecom
> Platform since
> > 2014, it stands for "Open Technology Platform". There are
> enough pedantic,
> > basement living, people on the internet that will annoy
> authors into
> > submission.
>
> That doesn't sound like a pleasant experience for everyone.
> Again, it's
> not an insurmountable challenge. It's just one more challenge.
>
> > 5) Small matter of documentation. "It used to be called X
> but was renamed
> > to Y in 2014"
>
> Documentation lives on way longer than expected. People still
> read and
> order reprints of the Erlang book published in 1994 (and 1996
> for the
> second edition), some of which are translations.
>
> Many older versions of books are what is in libraries and
> whatnot, since
> Joe's first version in early 2000s. For people using these
> versions, you
> end up with inaccurate terminology regarding half the name of the
> language.
>
> It's a matter of documentation, but it's a matter of trying to
> do it
> right to reduce the amount of confusion. If people look for "Open
> Telecom Platform Erlang" it would be sweet to get the new
> documentation
> and content.
>
> Maybe it's easy, but it's still part of a roadmap.
>
> Alternatively, would 'Open Telecom Platform, a framework that
> is not
> just about telecoms' going to be more cumbersome in documentation?
>
> > 6) History is history. Those investigating the language will
> get it. It
> > startedo ut being a telecoms thing and migrated to a general
> language. No
> > problem. Live web sites can easily add in blurbs. Old
> articles will be out
> > of date but not from the time frame of when they were
> written. No big deal.
> > The sky isnt actually falling.
>
> I could see that being made as a decision, yes.
>
> > 7) Obviously this one is just frothing. The man could update
> the next
> > version of his book with more information, cool tricks,
> whatever and sell
> > it as a second edition.
>
> Yes. I like to insert a bit of non-serious content here and there.
>
> > 8) What "traditional SDK" are you referring to? The LISP
> standard lib? ;-)
> > Java? C? Ruby? Haskell? Which one is the "normal" one?
> Normal is defined in
> > the context of the language, not in the context of another
> language? In
> > fact the vast majority of SDKs for java are third party to
> the JDK itself
> > anyway.
>
> I went from this thread's usage of SDK as a similar point to OTP.
> Erlang/SDK if you will. If you want to keep it as Erlang/OTP,
> that can
> work, but needs to be significantly better than what it is
> right now to
> have an actually measurable impact.
>
> Otherwise, we're throwing stuff at the wall to see what
> sticks, with no
> proof that it actually helped anything.
>
> > 9) Trying to crystal ball the future will only give you a
> headache. The key
> > is to move from where yo are to a point where progress has
> been made and
> > recursively loop on that algorithm, not be paralyzed by
> "what if .... ?"
> >
>
> Non-serious content here also. Not to be taken seriously, but
> I wouldn't
> be surprised if it were to happen.
>
> > You may have been doing Erlang for ages and feel quite the
> man but the
> > question really boils down to "what would you like for the
> future of Erlang
> > to be?" If the answer to that in your mind is "A niche
> language that I can
> > call myself a guru at and everyone looks at me quizzically
> and puts up with
> > my eccentricity or dare say arrogance." then the current
> name and trend is
> > fine. If the answer is, "A powerful general purpose
> programming language
> > for developing applications using functional paradigms and
> widely accepted
> > as being the solution to the next generation of software
> problems." Then
> > marketing is important.
>
> Oh I love that one. I want Erlang to be adopted so much I wrote an
> entire book about it and put it online for free, without
> advertisement.
> This has taken over 3 years of my spare time, because I wanted
> Erlang to
> be more accessible. I invite you to visit it at
> http://learnyousomeerlang.com
> <http://learnyousomeerlang.com/>, and maybe buy an ebook or
> print copy if
> you feel like it would be nicer to read that way. If you
> prefer a free
> electronic copies, there are scripts on github to convert it
> to the
> kindle format, and a wget line in the FAQ to download a local
> copy.
>
> I also kept writing multiple blog posts at http://ferd.ca
> <http://ferd.ca/> that guide and
> show more tutorials about Erlang, use cases, and tries to sell
> it as a
> language as a whole.
>
> The reason I'm answering to your suggestion negatively isn't
> that I
> don't want Erlang to succeed, it's that I do not believe that
> changing
> the meaning of 'OTP' from 'Open Telecom Platform' to 'Open
> Technology
> Platform' will have a noticeable impact.
>
> Some people do ask the question 'but I don't want to do
> telecoms', but
> in my experience, people's issues are the following, to a much
> higher
> degree:
>
> - The syntax is unfamiliar (or ugly)
> - It's difficult to work with single assignment, recursion,
> immutable
> algorithms (most of your algorithm books that rely on arrays
> with O(1)
> access to work fine are no longer going to be trivial to
> translate!
> That's huge!)
> - The tooling (rebar, relx, etc.) isn't up to par with other
> languages,
> even if it keeps getting better.
> - Lack of IDEs (that was your prime concern when you joined
> these lists)
> - Fighting the idea that "it will be hard to hire Erlang
> developers" to
> make it enter and stay in the enterprise.
>
> All of those criticism, in the years I've been in the Erlang
> community,
> have come up time and time again. They've also have come up
> orders of
> magnitude more often than OTP as a name, even if it does come
> up from
> time to time.
>
> I'm sorry I came up as harsh. I do want better adoption for
> Erlang and
> took months if not years of my free time working that way. I
> do not
> think renaming OTP is worth the effort, but I'll be glad to be
> proven
> wrong through bigger adoption if someone steps up and decides
> to do it.
>
> Now if you please, I'll go back to spending my lunch time
> working on an
> post-scripted chapter to the LYSE site introducing maps to people.
>
> Regards,
> Fred.
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
--
Erlang Solutions Ltd.
http://www.erlang-solutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140214/3274e03c/attachment.htm>
More information about the erlang-questions
mailing list