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

Thu Feb 13 19:57:08 CET 2014

“Don’t Feed The Trolls”

That is all

Me, I’m off for some well-deserved mortadella and lambrusco…

Mahesh Paolini-Subramanya
That tall bald Indian guy..  
Google+  | Blog   | Twitter  | LinkedIn

On February 13, 2014 at 7:46:30 PM, Steve Vinoski (vinoski@REDACTED) wrote:

Your trolling game is quickly falling apart.

Anybody know how to mute a single thread on this list?

--steve

On Thu, Feb 13, 2014 at 1:28 PM, kraythe . <kraythe@REDACTED> 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

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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140213/726ab8ec/attachment.htm>