<div dir="ltr"><div class="gmail_extra">Hi!</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, May 6, 2014 at 11:16 AM, Torben Hoffmann <span dir="ltr"><<a href="mailto:torben.hoffmann@erlang-solutions.com" target="_blank">torben.hoffmann@erlang-solutions.com</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">It may come across as a bottom-up approach, but Jesper and I started out using OPM to<br>





describe Erlang Concurrency Patterns, which sort of worked, but then I was strongly<br>
advised to invent Visual Erlang by someone who had been down the OPM route with<br>
Erlang.<br>
<br>
So Visual Erlang is born out of a need to be able to express these concurrency<br>
patterns.<br>
I admit, that it is not something at scale, so there is a to-do on documenting<br>
something bigger before we reach v1.0.0.<br>
<br>
Right now I just want to close what to me is an obvious void on the architectural<br>
level and then take the next problem after that.<br></div></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">(just thinking out loud)</div><div class="gmail_extra"><br></div>It appears to me from the discussion so far that such a high-level architectural description of Erlang systems has two important usage categories that are not quite overlapping: </div>




<div class="gmail_extra">A) describe and document existing systems and architectures</div><div class="gmail_extra">B) open up for new and better ways to architect and orchestrate Erlang systems</div><div class="gmail_extra">


<br></div><div class="gmail_extra">A involves among other things handling existing idioms (for example, when using gen_servers it is most often true that one can equate a process with a module, so it is reasonable to have a shortcut notation for that) </div>


<div class="gmail_extra"><br></div><div class="gmail_extra">B would include support for protocols and structural patterns, for example.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Like it was noted before, it's probably difficult to have something that works well for both cases. A layered approach might work: a low-level notation that can handle anything, and a higher-level one that builds upon it. </div>


<div class="gmail_extra"><br></div><div class="gmail_extra">best regards,</div><div class="gmail_extra">Vlad</div><div class="gmail_extra"><br><br></div></div>