To develop a system fit for Web-heroes.

What does it take to develop a programming system
that is appropriate for the web-developing heroes
(not sexism here, Hero is a woman's name) of today?

Let's examine two systems that have been successful
in different ways.

1.  Javascript.

    The recipe starts with one of the back-room boys
    whipping up a language and pilot implementation in
    just 10 days.

    I'm serious.  It's in the official record.  The
    design of Javascript took just 10 days.  It shows.
    https://www.destroyallsoftware.com/talks/wat

    Javascript filled a gap:  a programming language
    that could be used inside a web page (without
    requiring a special download) and could make the
    document being displayed interactive.

    It became part of a popular browser.  A certain
    predatory company trying to take over the market
    therefore adopted it too.  Other browser makers
    followed.  It got incumbent advantage.

    Pretty soon there was a version incompatibility problem.
    Two things happened in response.  An ECMA standard was
    produced -- and has since been revised several times --
    and compatibility libraries were produced.  While the
    *environment* (such as the interface to the document)
    varied from implementation to implementation, there was
    very little *syntactic* difference -- hint, hint -- so
    it was *possible* to develop compatibility libraries,
    making the language even more attractive.  It started
    getting including in WWW recommendations.

    I think you will agree that when a book called
    "<whatever>, The Good Bits" is successful, there is
    something pretty bad in the rest of the language.

    The benefit to web developers is not that Javascript
    is a *good* language, but that it is a *good enough*
    language which is sufficiently the same everywhere
    to serve as a target language for other things (like
    enscripten, Hop, even Haskell to JS compilers).

    Initially the performance was somewhere between bad
    and terrible, but that didn't matter, because there
    wasn't anything that could do the job.  Since then,
    people have pulled off feats of implementation, and
    it's a whole lot better than before.  The subtext
    has always been "write in Javascript and your code
    will be portable, but it will be *extra* good in our
    system."

    There are dozens of "improved Javascript" languages
    around.  And this is only possible because the
    Javascript implementations are as compatible as they
    are.  Build a web browser that only runs something
    better, no JS at all, and they won't come.

2.  Erlang.

    Erlang was designed by programmers doing distributed
    network programming for programmers and engineers
    doing distributed network programming.  Since the
    first book describing it, few major language changes
    have been made:
	- anonymous functions were added, initially faked
	  on top of pre-existing data types -- traces of
          this still lurk in corners of the system -- and
          later moved into the core.
	- the preprocessor was added, admittedly a gross
	  kludge, but good enough that there was little
	  pressure to implement something better, even
	  when designs were offered.
	- the bit syntax. Erlang always had "binaries",
	  uninterpreted sequences of bytes.  A syntax
	  was devised for a form of pattern matching
	  against byte strings that allowed very clear
	  (and surprisingly efficient) parsing of
	  network protocols.  This didn't break anything,
	  and was greeted with cries of joy from practically
	  everyone.
	- maps.  People have been asking for this extension
	  for a long time.  The inventor of the language had
	  a proposal.  Someone else had a quite detailed
	  proposal, even including benchmarks.  What's
	  implemented is something else, but still culturally
	  compatible with the rest of the language and without
	  breaking any existing code whatever.
	- The language is still slowly creeping towards Unicode.
	  There's library support that improves with every

    There are two language changes that have been tried
    experimentally and more or less withdrawn because of
    unanticipated problems:
	- modules with parameters
	- Java-style dotted module names (this wasn't
	  backwards compatible because Erlang atoms could
	  include dots anyway).

   So if the Erlang/OTP people are not bending their language to
   be more like C or Javascript, what _are_ they doing?

   Documentation.

	I don't suppose anyone ever gave Jan money to improve
	the SWI documentation.  For what we pay for it, it's
	better than we deserve.  I bought a copy of the SWI
	Prolog book.

	The documentation for Erlang runs to a *shelf* of books.
	I think there are about half a dozen published Erlang
	books.  

	The Erlang documentation suffers from being written by
	people who have not mastered the English language and
	a professional technical writer or two could do wonders
	for it.  But when you need to know what something does,
	exactly, most programmers would rather look in the
	manual and then ask on the web than go grepping around
	in the sources.  The better the documentation, the
	better things are for programmers.

    Packages.

	What makes SWI Prolog _really_ suitable for web programming?
	Packages.  The SGML/XML parser is a big one.  Database
	interfaces are huge.  Some sort of toolkit for generating
	Javascript might be useful.

	Erlang?  I couldn't begin to list the stuff that's available
	for Erlang.  Want to do streaming video?  There's erlyvideo.
	Want a web server framework?  There's Yaws.  There's Cowboy.
	There's a couple of others.  There's even one "in the box".
	Want to interoperate with things that speak ASN.1?  There's
	a nearly complete ASN.1 compiler comes standard.  Want to
	use SCTP?  That's around.  What about DIAMETER?  Yep.
	Database interfaces?  There's a built in distributed
	replicated database.  There are interfaces.  There's even
	an interface that makes Erlang look like MySQL to clients
	that think they're talking to MySQL.  NoSQL?  There are
	a couple of NoSQL systems written in Erlang.  Cloud?
	Well, there's CloudI.  www.cloudi.org.

	Some of these things are provided by the Erlang/OTP team.
	Some of them are produced by others, and *depend on the
	core language not changing in ways that break existing
	code*.

    System monitoring and reliability.

	The real strength of Erlang for web heroes has always
	been that Erlang isn't really a language, it's a
	*system* that contains a stable core language.  For
	example, there's a built-in protocol so that several
	Erlang nodes in a cluster can talk to each other,
	BUT you can replace that with something more secure.

	There's an Erlang programming language, but it's
	*factorised*:
	- there is a lexical structure, and there's library
	  code for lexing;
	- there is a syntactic structure, and there's
	  library code for parsing;
	- the abstract syntax tree you get after parsing
	  is documented and you can do other things with
	  it or generate it by other means;
	- the compiler turns parsed Erlang into "core Erlang",
	  and that interface is going to be officially
	  exposed and documented soon;
	- there is a virtual machine, and there are compilers
	  for other languages targeting that VM.
	Tools can be written at a variety of levels, whatever
	suits best.

	Above all, there are things like
	- logging,
	- performance monitoring,
	- SMTP,
	- hot loading,
	- tracing,
	...
	which can be applied to running systems.
	A customer complains about a performance problem?
	Hook in and see what's up, without recompiling or
	even restarting...

	This kind of support is implicit in the JVMTI for
	Java, and there are some *amazing* commercial
	system-level tools for Java, which I only wish I
	could afford.  Heck, they'd almost be enough to
	make up for having to use _Java_!

	Testing and validation tools.  Erlang has a couple
	of testing frameworks.  There's Common Test and
	Quviq QuickCheck for Erlang, for example.  There
	are some *amazing* tools for catching concurrency
	bugs in Erlang.  Anyone who wants to *really* help
	web programmers should try to figure out how to
	add something similar to SWI...  And of course there
	is the optional type checker, the Dialyzer.

	Oh, and how could I forget the system building
	tools, including for example 'rebar'.

In both cases, the best thing the underlying language can do
to support programmers is to *not change incompatibly* so that
a tool ecosystem can be built around it.  SWI Prolog has some
of this stuff.  In all seriousness, starting from a language
that's basically OK, *this* is the level that needs the work.