[erlang-questions] Fear and Loathing in Programming La La Land
Fri Apr 6 01:36:42 CEST 2012
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.
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
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
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the erlang-questions