[erlang-questions] idea: service pack one

[Brandon Black]

[oops, I sent this directly to YC earlier, can we get a Reply-To
header on the list?]

On Nov 13, 2007 7:28 PM, YC <yinso.chen@REDACTED> wrote:
> Whether it's flash or ajax or other platforms, it simply lives outside of
> erlang.  I think it makes sense for erlang to focus on its strength in
> server development and interfaces, rather than trying to dictate a
> particular UI solution of which it's not a part of, thus allows developers
> to make their own decisions.  But certainly supporting the necessary
> protocols will help with that regard :)
>
> But if we are talking about tackling protocols, then IMO some other ones are
> more important (for new comers such as myself) -
>
> - better ODBI support (specifically prepared statements)
> - official native database connectivity support for various databases -
> including prepared statements as well
> - official support for other inet protocols such as smtp, imap, etc.
>
> And I'm also interested to see leex being included in official distribution
> sometime in the future ;)
>
> My 2 cents,
> yc
>

I view things like database and mail protocols similarly to how you
(and I) view UIs - these are things that belong in extension
libraries, not as some core part of a language distribution.  The
popular protocols will change over time, and the popular
implementations of those protocols will change as well.  Old
implementations will naturally be replaced with increasingly superior
abstractions if you let the more external stuff evolve in a darwinian
fashion somewhere like CEAN.  Even really good implementations will
get replaced by newer ones that follow newer and better best practices
that evolve over the years.  Embedding early implementations of what's
popular today into the main distro is counterproductive if anything.
Once you bundle something with the core, your stuck with it as legacy
baggage for a very long time for fear of breaking upgraders, and
people tend to use it "because it's there" long after it's a very
unrecommended practice to still be using it.  Keep the core as minimal
as possible, IMHO.

Here's my personal shortlist of the most important usability
improvements.  These are the ones I think are the real "high value
targets" for making Erlang more accessible and giving it a brighter
future:

1) Explicit versioned compile/run-time module dependency and
autoloading.  Basically, the equivalent of the Perl idiom where if the
package "HTTP" needs to make use of the package "TCP", it can have a
single statement near the top that says "use TCP v0.02", and the TCP
module will be loaded/compiled/whatever if it isn't already, and
checked for minimum version requirements.

2) Hierarchical module namespace.  Flat namespace (or random
conventions for hierarchy with random local policies about separators)
is not conducive to having a well-organized CEAN.

[Can you tell yet that all of my suggestions boil down to stealing the
best things from Perl?]

3) Integrate CEAN with the main distribution, in the same way that a
stock Perl install comes with a CPAN module and a "cpan" commandline
program, which together with the bundled build/make tools can be used
to automatically fetch CPAN modules and automatically resolve their
dependencies on other CPAN modules.  This probably means coming up
with distribution-level (where a distribution is a collection of
related modules published by an author to CEAN as a unit in a single
archive of some kind) and module-level metadata standards.  I"m sure
that given that CEAN exists, some work has been done on this front
already, but I haven't looked at it in detail.

4) Simple code inheritance for the simple sake of easy reuse by
importing functions from other modules (some of which might be
"abstract" in the sense that they are useless other than to provide
said shared common code to child modules).  No need to get into OO
modeling crap here, this is just about typing less to get the same job
done.  Sometimes the idea of abstracting things as generalized
functions with function reference arguments and/or return values makes
the most sense, but at other times, code inheritance really makes more
sense.  I would recommend that we study other language's models here
and do it right from the start, instead of trying to hackishly alter
this as we go down the road.  The big decisions, and how I feel about
them (feel free to disagree):

A) Single Inheritance vs Multiple Inheritance vs Roles/Traits -
Roles/Traits is arguably superior, but MI is sometimes easier for
people who haven't grasped the necessary level of meta-ness.  There's
no good reason a language can't support both of course.  Having
neither (meaning that one can only have simple singular inheritance)
is very limiting, so if you don't put them in the core, someone will
hack them on later and do it with less care for correctness.  I would
highly recommend C3 as the algorithm for MI if implemented, it fixes
the diamond-shaped problems, etc.
http://en.wikipedia.org/wiki/C3_linearization .  The wiki entry is a
little out of date, in that it doesn't mention that C3 will also be
available (but not the default) in the next major release of Perl 5 (I
did that work, so I've got some level of experience to contribute here
on implementing this stuff).

B) Compiletime vs Runtime.  Runtime-modifiable inheritance (and I
don't mean during Erlang-style code upgrades, I mean at actual runtime
in a single version of the code) is a lot trickier to implement, and I
think it's probably a very poor fit for Erlang anyways.
Compile-time-only inheritance (specified in some module-level metadata
fields) would be simpler and a good fit.

-- Brandon