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

[Miles Fidelman]

Mind you, we're discussing how many angels can fit on the head of a pin, 
but.... for arguments sake (and to avoid doing real work...)...

Jan Burse wrote:
> Miles Fidelman schrieb:
>> I'd kind of beg to differ on this.  New tools lead to new methods lead
>> to new architectures.  ("Gee, we have a steam engine, let's see what we
>> can do with it." Or, "hmm... nails and a hammer, I bet we could build
>> bigger, taller buildings.")
>
> How I use the term "architecture"
> in information technology:
> Architecture == Fabric, Architecture != Building

Well, that's a fairly limited use of the term.  I generally understand 
the term to mean
"the manner in which the components of a computer or computer system are 
organized and integrated"

That's from Merriam-Webster, by the way, but it's consistent with more 
precise technical uses of the term. (I'm not going to get pedantic and 
start quoting from the systems engineering literature or anything like 
that. :-)

Fabric may be an architectural model, and a pretty loosely defined one 
at that ("protocol fabric," platform, SOA, ....) but it's far from the 
only one.  Fabric =\= Architecture
>
> You cannot just build a new tool. First there has to be an
> architecture already in place, where the tool can work on.
> And second there has to be some method around, which gives
> the tool a place in a process.

Unless you're considering general-purpose computer == architecture, of 
course one can, and we do it all the time.  (And, given that 
general-purpose computers are Turing-equivalent, that's a pretty 
unconstrained architecture.)  Yes, tools are built in a context - say a 
bash script that searches through a text file and pipes output into 
another script (context = Unix, text files, pipes) - but again, that's 
pretty unconstrained.

Do you really have to have a client-server architecture before you 
implement a database?  Or does having a database capability begat 
client-server architectures, and more tools (e.g., clients).

Ok, sure, if we're talking about IDEs (which I believe we are), is Emacs 
a tool, or an architecture, or both?  What about Emacs + a set of 
Erlang-specific plugins?

Most general purpose computer languages are Turing-equivalent - but 
emphasize different world views (LISP is great for some problems, 
horrible fr others.  Same again for APL, or, of course Erlang).  Is a 
language a tool or an embodiment of an architectural approach?  (To my 
mind, the answer is "yes.").  Which comes first?  Kind of depends on the 
language, its history, and its influences.
>
> The end product that you are building with a particular
> tool are applications. And they will share the same
> architecture, independent whether they are innovative
> or conservative, small or tall, etc..

Again, depends on your point of view.  Do all programs ultimately 
execute as machine code... yes.  Do all programs written in C (or in 
Emacs) share the same structure... definitely not.

I've seen systems with a lot of different architectures built in Java, 
Erlang, Fortran, .....   Architecture (e.g., client-server vs. P2P) is 
orthogonal to tools.  If anything, choice of tools can drive the 
architecture of a system (Erlang begats even-driven actor architectures, 
Java begats object-oriented ones.)




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