[erlang-questions] Time for OTP to be Renamed?

Mark Nijhof mark.nijhof@REDACTED
Thu Feb 13 19:42:16 CET 2014


huh what, I was too busy writing Erlang/OTP code :P


On Thu, Feb 13, 2014 at 7:37 PM, Sergej Jurecko <sergej.jurecko@REDACTED>wrote:

> So...
> does anyone else miss the good old days of the erlang-questions mailing
> list? When it did not generate 100 emails a day with endless discussions
> about issues that are obviously never going to change?
>
>
>
> Sergej
>
> On Feb 13, 2014, at 7:28 PM, kraythe . wrote:
>
> Why not learn instead of sell?
>
>
> Because the bank wont take "I learned Erlang this month" in lie of my car
> payment or mortgage. Because innovations are rarely created for the
> purposes of "learn, not sell." Erlang itself was created to Sell, be under
> no misunderstanding. If Ericson couldn't make a case to the "sellers" then
> the language wouldn't have powered their switch. Because capitalism and
> libertarianism work and communism and socialism eventually run out of other
> people's money. And because I don't want to be someone living on someone
> else's dime. I like to create, innovate, invent and get paid for it. That
> lets me provide a better life for my family.
>
> *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
> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>
>
> On Thu, Feb 13, 2014 at 12:22 PM, John Kemp <john@REDACTED> wrote:
>
>> On 02/13/2014 11:44 AM, kraythe . wrote:
>>
>>> Cant agree with you John.
>>>
>>
>> That's fine :)
>>
>>
>>  In an organization you cant simply do what you
>>> want and shrug.
>>> If I tried that in any of the big organizations i have
>>> been involved with my optimal case is being fired.
>>>
>>
>> If I need to "convince" someone about the tech I want to use then I
>> either wouldn't use that tech and would use what they wanted instead, or I
>> would quit.
>>
>> It's absolutely the case that if you are driven by "social context" (by
>> that I mean, roughly, "other people's concerns") alone, you won't choose
>> Erlang.
>>
>> Although I would often choose Erlang for myself, I would often choose
>> another language if I had a programmer of that language to work with, and a
>> tight deadline.
>>
>> In my opinion, professional software developers should choose the best
>> tool for the job -- and the job often includes more than the problem at
>> hand, true. I like to make satisfied customers.
>>
>>
>>  Perhaps if you own
>>> the company you can. But then that relegates Erlang to niche. Makes the
>>> old timers feel pretty superior
>>>
>>
>> As I've said, you can *choose* whatever language you like, and barring
>> the edge cases, you'll be able to build a workable, relatively scalable
>> solution.
>>
>>
>>  but is a horrible waste of what appears
>>> to me to be a very useful language. Also if you go that tact there is no
>>> more point of arguing Erlang vs Scala or vs any language anymore. Erlang
>>> will become like Smalltalk. Useful and cool for the old timers but
>>> virtually IRRELEVANT in the IT industry.
>>>
>>
>> Erlang makes efficient use of computing resources, specifically in
>> distributed environments. It does several other clever things. It's also
>> hard to learn (for some programmers) and doesn't come with a ready "market"
>> of/for proficient software developers. But those who learn it tend to
>> understand the problems which Erlang is good at solving. And they
>> understand why the language choices made in Erlang might be made, in which
>> case, they will often understand other languages better than average
>> devlopers too.
>>
>>
>>
>>> Furthermore, if you argue you don't care about adoption then the
>>> discussion is moot with you. What
>>>
>>
>> I will continue to explain what I have observed about the advantages of
>> Erlang to those who will listen :)
>>
>>
>>  it will mean is whomever is on your
>>> development staff writing Erlang you better be open to paying them
>>> whatever they want and letting them get away with about anything because
>>> replacing them would be nearly impossible.
>>>
>>
>> Unfortunately, I usually work with people who are not in position to
>> understand why one might use Erlang.
>>
>> Imagine that you have been initiated into a secret group of people who
>> will help give you an advantage in your software projects that so few have.
>> How could you use those skills?
>>
>>
>>  Often many tech people cant
>>> see past "oooh list comprehensions !!!!!!" to the actual business behind
>>> it and without the business none of us get paid. That is not something
>>> you can take to management and sell.
>>>
>>
>> Why not learn instead of sell?
>>
>> - johnk
>>
>>>
>>> *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 10:33 AM, John Kemp <john@REDACTED
>>> <mailto:john@REDACTED>> wrote:
>>>
>>>     On Feb 13, 2014, at 11:20 AM, kraythe . <kraythe@REDACTED
>>>     <mailto:kraythe@REDACTED>> wrote:
>>>
>>>              /Java as a language is big and complex, because it has a
>>>>             lot of concepts directly inside the language./
>>>>
>>>>
>>>>     Ahh but here you are wrong. Java itself is analogous to Erlang
>>>>     without OTP. you don't HAVE to use the JDK libraries beyond
>>>>     java.lang. You would be a bit crazy reproducing the wheel if you
>>>>     did so but it is not a requirement of writing java. In fact many
>>>>     Java controlled micro devices only allow a very small subset of
>>>>     the JDK to be used. So there is essentially no difference.
>>>>
>>>>     So Elang is to Java as the Java Development Kit is to the Open
>>>>     Telecom Platform. And there is where we have the "marketing"
>>>>     disconnect. Its not about changing functionality or a triviality
>>>>     to be scoffed over. If we start with the premise that we want more
>>>>     developers to learn and use Erlang then we have to consider how
>>>>     the language and its nomenclature comes across to our audience.
>>>>     You don't name a language the Scalable High Integration Technology
>>>>     because the impression it leaves with adopters is ... unfortunate.
>>>>
>>>
>>>     Why start with that premise instead of starting with the premise
>>>     that developers should try to understand what is useful to them?
>>>     That has nothing to do with marketing, and everything to do with
>>>     software developers understanding their craft better.
>>>
>>>
>>>>     So if you DON'T care about people adopting the language, then the
>>>>     discussion is academic and simply, as one reply put it, a waste of
>>>>     time. Of course if you don't care about adoption then you are
>>>>     wasting your time here because you wont be able to staff a
>>>>     development crew, replace developers that leave or push the
>>>>     language into an organization which isn't currently using it.
>>>>
>>>
>>>     Who is "you" in this case? Does the "Erlang community" want to get
>>>     the language adopted more? Perhaps. Why would that matter to the
>>>     Erlang community - how do they benefit? Why should those who already
>>>     know and benefit from Erlang not simply continue to do so?
>>>
>>>
>>>>     If you DO care about people adopting the language you have to
>>>>     consider its marketing. If I many were to take Erlang to
>>>>     management and propose it for a product the management would see
>>>>     "Open Telecom Platform", object that the company isn't a telecom
>>>>     company and that Erlang is mainly for telecom and that would be
>>>>     the end of that.  In fact, if you really care about adoption you
>>>>     are better off renaming it "Fred" than leaving it as "Open Telecom
>>>>     Platform".
>>>>
>>>
>>>     People reject languages for all kinds of strange reasons. And it's
>>>     the case that in many cases you can simply choose "a language you
>>>     like" and then *make* it work for what you want to do. After all,
>>>     computers have particular resources available to them, and a
>>>     language well-adapted to its environment should support adequate
>>>     performance for most applications. The distinction between threading
>>>     in Ruby and "event-driven" in Node is largely meaningless, for
>>>     example. The real questions are things like "how well does your
>>>     VM/compiler exploit computer hardware resources on the platform
>>>     you're using". Most developers don't understand this, so they argue
>>>     about threads vs. processes vs. events without understanding what
>>>     might actually be the critical differences regarding the performance
>>>     they say they want.
>>>
>>>     Naming won't fix that. And management will never get that. You need
>>>     people to understand what they are doing. Or not. After all, you can
>>>     largely do what you like and apart from at the edges, it will likely
>>>     work.
>>>
>>>     - johnk
>>>
>>>
>>>>     Naming matters and it is also pretty easy to fix.
>>>>
>>>>     *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 9:03 AM, Anthony Ramine <n.oxyde@REDACTED
>>>>     <mailto:n.oxyde@REDACTED>> wrote:
>>>>
>>>>         That's a *HUGE* difference. Erlang as a language is very
>>>>         small; OTP is a very complex piece of software, as is BEAM.
>>>>         The three shouldn't be conflated.
>>>>
>>>>         Java as a language is big and complex, because it has a lot of
>>>>         concepts directly inside the language.
>>>>
>>>>         --
>>>>         Anthony Ramine
>>>>
>>>>         Le 13 févr. 2014 à 15:59, Vlad Dumitrescu <vladdu55@REDACTED
>>>>         <mailto:vladdu55@REDACTED>> a écrit :
>>>>
>>>>
>>>>         > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine
>>>>         <n.oxyde@REDACTED <mailto:n.oxyde@REDACTED>> wrote:
>>>>         >> Java without OOP is a different language.
>>>>         >> Erlang without OTP is still Erlang.
>>>>         >
>>>>         > IMHO the only difference is that OTP is implemented as a
>>>>         library and
>>>>         > doesn't have dedicated language syntax. I make difference
>>>>         between OTP
>>>>         > as design/system building guidelines and its implementation.
>>>> The
>>>>         > former is more like OOP for Java. The latter is more like
>>>>         the JDK.
>>>>         >
>>>>         > /Vlad
>>>>         >
>>>>         >> --
>>>>         >> Anthony Ramine
>>>>         >>
>>>>         >> Le 13 févr. 2014 à 15:21, Vlad Dumitrescu
>>>>         <vladdu55@REDACTED <mailto:vladdu55@REDACTED>> a écrit :
>>>>
>>>>         >>
>>>>         >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau
>>>>         <bchesneau@REDACTED <mailto:bchesneau@REDACTED>> wrote:
>>>>         >>>> I also say Erlang/OTP and often I add to the one that ask
>>>>         that OTP is
>>>>         >>>> a framework, but then people are more puzzled than they
>>>>         were before.
>>>>         >>>> Maybe rust did the right things by  clearly separating
>>>>         the language
>>>>         >>>> and the runtime from the standard library and other libs ?
>>>>         >>>
>>>>         >>> I would say that OTP is to Erlang what OOP is to Java. You
>>>>         can write
>>>>         >>> Java programs that are not object-oriented, but why choose
>>>>         Java for
>>>>         >>> that in the first place?
>>>>         >>>
>>>>         >>> OTP is in my opinion a design philosophy that guides us
>>>>         when it comes
>>>>         >>> to structuring and developing distributed fault-tolerant
>>>>         systems. It
>>>>         >>> comes with library support that is intimately tied to the
>>>>         Erlang
>>>>         >>> libraries: the most basic Erlang apps (kernel and stdlib)
>>>>         are also the
>>>>         >>> ones that implement the OTP concepts. Even more, Erlang
>>>>         code is
>>>>         >>> structured as applications, and an "application" is an OTP
>>>>         concept!
>>>>         >>>
>>>>         >>> I can only see meaning in trying to separate the language
>>>>         from OTP
>>>>         >>> either as an academic exercise or in order to implement a
>>>>         different
>>>>         >>> language on the beam runtime and the new concepts would
>>>>         collide
>>>>         >>> implementation-wise with OTP. Or one wants to create OTP
>>>>         2.0 without
>>>>         >>> interference with 1.0.
>>>>         >>>
>>>>         >>> regards,
>>>>         >>> Vlad
>>>>         >>> _______________________________________________
>>>>         >>> 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 <mailto:erlang-questions@REDACTED
>>>> >
>>>>
>>>>         http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
>>>>     _______________________________________________
>>>>     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-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


-- 
Mark Nijhof
t:   @MarkNijhof <https://twitter.com/MarkNijhof>
s:  marknijhof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140213/c27eec7f/attachment.htm>


More information about the erlang-questions mailing list