[erlang-questions] Fear and Loathing in Programming La La Land
Thu Apr 5 20:42:08 CEST 2012
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
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
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
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
More information about the erlang-questions