Is erlang too small?
Mon May 10 16:26:03 CEST 2004
Rudolph van Graan <> 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:
> Database (Not internet, but still)
> (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
Do you by "one-author-per-interface model" refer to how the the OTP
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
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 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