[erlang-questions] node.js vs erlang

[Leonard Boyce]

So with all the complexity issues being talked about would a basic
'app generator' along the lines of yeoman
http://yeoman.io/learning/index.html not be a better fit?

Maybe a binary which can set up the framework for an example
application with the user having to answer a few questions.

Trivial example (assumes name of simperl as binary);

noobie@REDACTED$ ./simperl

- Choose the application example type:
1) Web Server
2) Multi-server Ping-Pong Example
> 1

- Choose the type of Web Server example
1) Simple "Hello World" web server
2) REST "Hello World" web server
3) ....

> 1
Web Server installed and running. Go to http://localhost:12345/

To modify this server to print "Goodbye World" instead, edit file
"simple_hello_world/src/simple_hello_world.erl"
and use the command "./simperl recomplile simple_hello_world"

For more information on how things actually work see:
simple_hello_world/doc/README.md

noobie@REDACTED$

By approaching it in this way you may achieve rapid 'satisfaction' and
the ability to expose the user to anything you want with examples of
differing complexity.

Leonard

On Thu, Jun 19, 2014 at 10:12 AM, Miles Fidelman
<mfidelman@REDACTED> wrote:
> Mahesh Paolini-Subramanya wrote:
>>
>> "Complexity" is a remarkably loaded term - I'm fairly certain that things
>> that are complex for me (Getting anywhere via mass-transit in Tokyo) are
>> pretty trivial for others (e.g., Loic).
>
>
> Well, let's say "complex" in an engineering context, for starters.
>
>> Whats more, complexity of systems has nothing to do with the complexity of
>> the individual components involved (DNA is a bit of a prime example here).
>
>
> Precisely.  I'd venture that one gravitates toward Erlang when one is
> building systems and systems-of-systems with lots of distributed, moving
> parts (e.g., a telephone switching fabric).  If one is building a single,
> stand-alone application, I expect Erlang might not be the "best" choice.
>
>>
>> That said, I would claim that erlang systems are more _comprehensible_
>> than others.
>> Mind you, this does require some mastery of erlang, which is not as much
>> of a chicken-and-egg scenario as you might imagine.
>>
>>
>
> You know, that's a really good point, that highlights two broader issues:
> conceptual models, and tooling that maps onto conceptual models:
>
> - Sequential code is relatively easy to conceptualize and represent - well
> commented code can suffice as a representation, there are plenty of
> debugging and tracing tools for examining run-time behavior
>
> - Object oriented code lends itself to browsers and inspector - though
> execution flow can get pretty arcane (at one point, I worked on military
> simulators - think game engine - each vehicle was an object, but the actual
> work was done by 4 spaghetti coded threads that each ran 20 time a second -
> very ugly, and what led me to discover Erlang)
>
> - Actor formalism (i.e., Erlang) - very easy to conceptualize for
> applications where things naturally map onto independent processes (e.g.,
> the above-mentioned simulator -- tanks and airplanes are a lot easier to
> model as processes than as objects) - but tools for visualizing, designing,
> debugging systems with lots of processes, and the interactions among them,
> are close to non-existent  (a problem for Erlang, but also for anyone
> building highly concurrent, highly distributed systems)
>
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   .... Yogi Berra
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions