[erlang-questions] Fear and Loathing in Programming La La Land

[Miles Fidelman]

Jan Burse wrote:
> Miles Fidelman schrieb:
>> it's a toolbox that's particularly suited
>> to the actor design pattern (architecture).
>
> Design pattern or architecture? A design
> pattern is usually implemented on top of
> an architecture.
To my mind, a design pattern IS an architecture, with a specific 
system's architecture being a specialization of that general 
architecture.  E.g.,. a specific client-server system design.
>
> A main characteristic of an architecture
> is ubiquity in an application. So the
> same architecture elements will be used
> over an over for different use cases.
> These use case might be designed with
> the help of design patterns.
Huh?

A use case sets the requirements for a system (or application), a design 
pattern defines an overall architectural approach (e.g., client server), 
the system's architecture identifies the major components of a specific 
system and their inter-relationships (notably their interfaces).

(Of course there are other uses of the word, such as a specific service 
oriented architecture, or a protocol architecture), but I believe we're 
talking software/system architecture at the moment.

>
> And I cannot agree that the Java suite
> begets "object orientation" as architecture.
> I rather see the fundamental architecture as:
> - multi threaded
> - single class inheritance (extends)
> - multiple interface inheritance (implements)
> - What else?

Well, most of the folks I know who build Java-based systems, seem to 
build object-oriented systems.  By contrast, most of the folks I know 
who use Erlang build actor type systems.
>
> The actor design pattern is not that difficult
> to implement in the above architecture. And
> it is also not that difficult to elevate
> the fundamental architecture by actor like
> elements.
Unless you actually want your system to perform.  Show me 20,000 
concurrent actors in Java and I'll show you a grid-locked system.

And, last time I looked, Java is far more oriented toward invoking 
methods on objects - leaving it to you to design your control flows - 
where Erlang/OTP provides all kinds of pre-defined components for 
managing actors, actor states, and messaging among actors.

Real-world example:  I used to work at a firm that built CGF (Computer 
Generated Forces) simulators - think "game engine simulating 2000 tanks 
on a battlefield."  Coming from a network background, I simply assumed 
that the system spawned a process for each tank (the same way a protocol 
engine spawns a process for each connection or transaction).  Nope... I 
was assured that context switching overhead made that impossible.  
Instead, each tank is an object, and every 1/20th second, 4 different 
main threads wind their way through each and every object in the 
system.  Very ugly.  I discovered Erlang when I went searching for a 
run-time environment that COULD support an actor-oriented approach to 
simulation (not that I went and rebuilt all that code, mind you).  
(Note: This is a slightly contrived example, as most of the core 
simulation code was in C++, but the same model and constraints apply.)

Give me 20,000 things to manage in Java, I'll probably create 20,000 
objects and come up with some kind serialization code to manage the flow 
of events.  In Erland, I'll just spawn 20,000 state machines and let the 
OTP infrastructure deal with eventing.

Available tools are a primary set of constraints that drive system 
architecture decisions.

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra