[erlang-questions] What I dislike about Erlang

[Richard O'Keefe]

On 1/09/2012, at 5:42 AM, Evan Miller wrote:

> Richard,
> 
> Thanks for your comments. To preface, I plead guilty to charges of
> gross negligence in failing to document TinyMQ's internals. This was
> laziness on my part.

I do hope that I did not give offence.
There would not have been any point in criticising something *bad*.
I picked on your code for three reasons:
 - I had just downloaded it and spent some time reading it carefully.
 - It was small enough that I *could* read it carefully in full.
 - The problems I had doing that are ones that I have had over and
   over again, and the biggest of them is nothing to do with you.

> I released TinyMQ only because I felt guilty for sitting on the code
> for about a year. Like many open-source programmers, I have a lot of
> demands on my attention, and it is not clear in advance what
> documentation is actually worth writing.

Limitations and examples.

> The @spec and @doc strings
> for the public API seemed like a good start. But if it turned out that
> no one was interested in using the library in the first place, why
> should I bother documenting internal protocols and data structures?

All I can say is that the best programmers I have worked with
wrote the documentation *first*.  It's part of the "research" phase
that Joe Armstrong mentioned.  It's how you get quality code.

As Dijkstra once meant but said differently, "I am a bear of very
little brain", and the first person I have to explain the code to
is myself.

> I've wasted many hours in the past documenting, refactoring, and
> generally cleaning up application internals for the benefit of
> nebulous "others", only to receive zero patches and no indication that
> any of my efforts were of any assistance to anyone.
> 
> So in the spirit of your capitalized complaints, I will just say:
> 
> ALL YOU HAVE TO DO IS ASK
> 
> Want to know about the big-O performance characteristics?

But this is where you *START* the design!

If it's a well known data structure, you can get away with leaving
it to the books, but sliding windows, while common, are _not_ a
well known data structure.  (Well, ones where the window is a *count*
of elements are tolerably well known, but ones where the window is
an *age* are not.  I asked about this in the Haskell mailing list,
and Chris Okasaki -- Mr Functional Data Structures himself -- didn't
know of anything off-the-shelf, although he did suggest something
that might just work.  He also raised an interesting question about
the interface.)

> Just ask.

By the time I've asked and got a reply, seeing as we're in very
different time zones, I'd have written my own.

Last year I was involved in a project where I had to "just ask".
The turnaround time was a week at best, and about half of my
questions never did get answered.

> Now, I know you were not trying to pick on TinyMQ, and your interest
> is more in how Erlang tends to result in lumps of code that obscure
> key characteristics of the application. I agree with the assessment,
> but I am not quite as hopeless about the situation.
> 
> I would like to see the development of graphical tools that let you
> see in an instant how applications are structured and how they behave.
> I am thinking of something like Pman on steroids, where I can *watch*
> messages travel between processes, *inspect* gen_server state, and
> *test* the system by seeing the result of single function calls or
> many (load-testing). I'd like to be able to do all this with my mouse,
> and generally get the feeling that I am watching the operation of a
> machine that *shows* me how messages are passed, processes are
> created, and state is updated.

Something very like such graphical tools already exists;
I recall viewing some videos someone had made using Ubigraph
showing the dynamic process structure of Erlang programs.
What I want, though, is to see the structure of something without
having to run it or even compile it.

I'm thinking more in terms of some sort of preprocessor taking
something visibly and obviously a server process and emitting the
lower-level Erlang code.  The thing is that I believe that it is
better to make something really obvious at the outset than to
provide better tools for undoing obfuscation.



Oh, let's put this all in perspective.

Apart from my general complaint that all Erlang code tends to
look alike (just like all Smalltalk or Prolog or Haskell or Lisp
code tends to look alike), the internal documentation
that I'd have liked to see is this:

	TinyMQ is a gen_server guarding a dictionary mapping
	channel names (normally strings) to channels, where
	a channel is a supervised gen_server guarding a
	list of subscribers and a list of {Message,Timestamp}
	pairs.  Messages expire after MaxAge seconds but are
	not removed until the next time the channel does something

There's an hour's close reading time saved right there.