Is erlang too small?

Kent Boortz kent@REDACTED
Mon May 10 16:26:03 CEST 2004


Rudolph van Graan <rvg@REDACTED> writes:
> So... What can we (as a community) do to make sure erlang can
> communicate with things in the real (internet) world? One cannot
> escape Soap, nor communicating with relational db's. Personally, I
> think that the open source guys do a great job, but can we follow and
> stay up to date with all the important developments? How does one make
> sure that erlang does evolve?
>
> My opinion is that we must focus on the important internet interfaces
> and make sure they work? Examples:
>
> XML,
> SOAP,
> Database (Not internet, but still)
> SMTP,
> HTTP
>
> (XML and HTTP does have erlang components and I appreciate the
> author's efforts, but they still need a lot of work in order to keep
> up with all the specifications out there)
>
> My feeling is that the only way forward is to get away from the
> one-author-per-interface model, and to get a larger support base in
> place.

Do you by "one-author-per-interface model" refer to how the the OTP
team work?

With the work load and responsibility of quality to the paying
customers there will always be a controversy between the demand for
features from the OpenSource community and the needs of the paying
customers. As I see it there are two ways to contribute to Erlang

  - Do your own thing, like yaws. It is not part of the main
    OTP distribution and not supported by the OTP team.

  - Work as close as possible to the OTP development model and try to
    convince the OTP team to add your code.  In short I think this
    require you to follow the rules

      o A functionality that lack test cases doesn't exist!!

        The "write code and wait for someone to report bugs" model of
        development isn't enough for OTP, the code has to be tested
        with lots of test cases.  The OTP team should release *all*
        test suites to make it easy to add your test cases. It is very
        easy to add tests for the test server (it is OpenSource).

      o A functionality that lack documentation doesn't exists!!

        There is for example a http client that has no documentation
        and no test cases. When I tried it there is an obvious bug
        that the most simple test cases would have caught.

        For small changes submit plain text documentation that the
        responsible in the OTP team can add. For a new application or
        a larger addition you should write documentation in SGML. This
        require that the OTP team release the documentation tools or
        at least the DTD:s.

      o For code that may require special changes on Windows it should
        have been tested on Windows as well, including running the
        test suites.

      o Code that isn't 100% portable across Unix platforms should be
        written in a way that new targets are easy to add and that the
        code is easy to exclude for unsupported platforms.

      o Code that uses Java or other language should use the most
        "common" version of that language/compiler/development kit.
        For Java it means the most "common" JDK found or that it is
        tested on several JDK versions. The version of third party
        products used in the OTP testing is documented in the README
        for the binary releases. I'm not sure it is documented in the
        OpenSource release, if not it should be added so that OpenSource
        developer can know how to test the code before submission.

      o Do careful changes to existing code. Write comments and change
        logs so that changes can easily be understood. A huge patch on
        existing code will require extensive work from the OTP team
        and there may not be time to do it. If you change ugly
        indentation or other whitespace you are doomed ;-)

      o Make sure the code you add compiles without warnings.

      o You must think as an OTP member ;-) This code I write will run
        in a telephony station or similar product used by tousands or
        millions of users that will be very unsatisfied if you
        introduced a bug that prevent them for using the service.
        The commercial view is not as different than the OpenSource
        one, it is all about making others happy ;-)

I can't speak for the OTP team, just my opinion,

kent

-- 
Kent Boortz, Senior Software Developer
MySQL AB, www.mysql.com
Office: +46 702 279 11 71

Are you MySQL certified?  www.mysql.com/certification



More information about the erlang-questions mailing list