Various Topics on Programming

..latha..

there is good reason to consider computer science
a foundation for scientific modelling

object-oriented
declarative or imperative
languages are well defined mathematically

the categorial approach to term calculi is well developed

the language naturally develops around a physical ontology
and defining this ontology is rigorous and repeatable

but science cannot stay theoretical
there is technology that couples
and and engineering to be done

the study of this engineering is software architecture
and all the modern architectural knowledge
should be studied by modellers

modern software architecture theory studies reuse patterns
as methodologies for
minimising effort to feature point growth

this is a very practical problem
and the foundation for
thermodynamic approaches to the theory of technology

cl***ical stateful architectural pattern languages
began with work in building architecture
and was imported into software architecture
most famously by the gang of four
( with earlier crosspollination
amongst many engineering sciences )

studying cl***ic idioms and techniques for decoupling
graph regular expressions
of mereological relationships
between objects and their transformations

closing one's modules to change
but allowing them polymorphic behavior
to open feature spaces

model agility directly and immediately benefits technology

" generative programming "
by czarnecki and eisenecker
should be required reading for would-be theoreticians

understanding state machines and lifetimes
helps understand electrons and their evolution

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
galathaea: prankster, fablist, magician, liar

..latha..

On Jun 11, 8:43 pm, galathaea <galath...@gmail.com> wrote:
> there is good reason to consider computer science
> a foundation for scientific modelling
>
> object-oriented
> declarative or imperative
> languages are well defined mathematically
>
> the categorial approach to term calculi is well developed
>
> the language naturally develops around a physical ontology
> and defining this ontology is rigorous and repeatable
>
> but science cannot stay theoretical
> there is technology that couples
> and and engineering to be done
>
> the study of this engineering is software architecture
> and all the modern architectural knowledge
> should be studied by modellers
>
> modern software architecture theory studies reuse patterns
> as methodologies for
> minimising effort to feature point growth
>
> this is a very practical problem
> and the foundation for
> thermodynamic approaches to the theory of technology
>
> cl***ical stateful architectural pattern languages
> began with work in building architecture
> and was imported into software architecture
> most famously by the gang of four
> ( with earlier crosspollination
> amongst many engineering sciences )
>
> studying cl***ic idioms and techniques for decoupling
> graph regular expressions
> of mereological relationships
> between objects and their transformations
>
> closing one's modules to change
> but allowing them polymorphic behavior
> to open feature spaces
>
> model agility directly and immediately benefits technology
>
> " generative programming "
> by czarnecki and eisenecker
> should be required reading for would-be theoreticians
>
> understanding state machines and lifetimes
> helps understand electrons and their evolution

of the modern study
focus has centered on mechanisms of refactoring
in the large scale evolution of software

functional programmers have long known
that a declarative syntax with functional polymorphism
allows for tremendous simplification of expression
and is almost trivially reusable

however
solving problems functionally is not as well studied
as the production of procedural solutions

there are some algebraic reasons for this
but it is possible to train to become better and faster
in functionally solving problem domains

i find refactoring usually brings me towards
an architecture of declarative state machine
( monads and their ilk )
over transport layers
which is of course the same observation hoare made

a science of that form
allowing easy learning of new models

test-driven as necessary an operationalist science

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
galathaea: prankster, fablist, magician, liar

..B

"galathaea" <galathaea@gmail.com> wrote in message
news:1181620906.467376.219800@i13g2000prf.googlegr oups.com...
> On Jun 11, 8:43 pm, galathaea <galath...@gmail.com> wrote:

<snip>

> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> galathaea: prankster, fablist, magician, liar
>

Xah, is that you? :-D

..latha..

On Jun 11, 9:01 pm, galathaea <galath...@gmail.com> wrote:
> On Jun 11, 8:43 pm, galathaea <galath...@gmail.com> wrote:
>
>
>
> > there is good reason to consider computer science
> > a foundation for scientific modelling
>
> > object-oriented
> > declarative or imperative
> > languages are well defined mathematically
>
> > the categorial approach to term calculi is well developed
>
> > the language naturally develops around a physical ontology
> > and defining this ontology is rigorous and repeatable
>
> > but science cannot stay theoretical
> > there is technology that couples
> > and and engineering to be done
>
> > the study of this engineering is software architecture
> > and all the modern architectural knowledge
> > should be studied by modellers
>
> > modern software architecture theory studies reuse patterns
> > as methodologies for
> > minimising effort to feature point growth
>
> > this is a very practical problem
> > and the foundation for
> > thermodynamic approaches to the theory of technology
>
> > cl***ical stateful architectural pattern languages
> > began with work in building architecture
> > and was imported into software architecture
> > most famously by the gang of four
> > ( with earlier crosspollination
> > amongst many engineering sciences )
>
> > studying cl***ic idioms and techniques for decoupling
> > graph regular expressions
> > of mereological relationships
> > between objects and their transformations
>
> > closing one's modules to change
> > but allowing them polymorphic behavior
> > to open feature spaces
>
> > model agility directly and immediately benefits technology
>
> > " generative programming "
> > by czarnecki and eisenecker
> > should be required reading for would-be theoreticians
>
> > understanding state machines and lifetimes
> > helps understand electrons and their evolution
>
> of the modern study
> focus has centered on mechanisms of refactoring
> in the large scale evolution of software
>
> functional programmers have long known
> that a declarative syntax with functional polymorphism
> allows for tremendous simplification of expression
> and is almost trivially reusable
>
> however
> solving problems functionally is not as well studied
> as the production of procedural solutions
>
> there are some algebraic reasons for this
> but it is possible to train to become better and faster
> in functionally solving problem domains
>
> i find refactoring usually brings me towards
> an architecture of declarative state machine
> ( monads and their ilk )
> over transport layers
> which is of course the same observation hoare made
>
> a science of that form
> allowing easy learning of new models
>
> test-driven as necessary an operationalist science

using this as a foundation makes it more rigorous
to formalise objections to some of the modern theories

in particular
string theory has acquired a large set
of ad hoc ***umptions
in an attempt to predict future needs

that is not good agile technique

what was originally a fairly simple extension
that existents are extended objects
with actions proportional to the areas of their worldsheets
has grown through accretion of ideas into a monolith

a dizzying array of symmetries added
dimensions added
exotic topologies
boundary constraints and brane physics

of course
these weren't added without reason

string theory didn't work
they needed superstrings
4 dimensions didn't work
they needed 10/11/26

and all of this structure was added
based on the needs of only one test
the need for quantum gravity

and eventually it achieved this goal
and was the first to do so
so in this respect it was the natural engineering choice
for a possible model of reality

but it carries with it a large space of variability
and little guidance for future evolution of the theory
to future experiments

so as the mathematical foundations have been evaluated
and various essential and nonessential
algebraic ingredients identified
there should be an effort at refactoring

removing the unnecessary complexity
which can make our models difficult to change
in the face of new experience
and focussing on minimal models to drive our experiments

that is where the engineering is needed
because that is where money is involved
and that is where energy and human action is needed

there are new tests on the scene

dark matter
dark energy and the cosmological constant
and all the others regularly brought up

it has been verified that
due to the monolithic complexity of superstrings
little progress has been made to meet these tests
and where some results have been made
they are of high complexity

that is to be expected from a architectural analysis

on the other hand
some of the newer minimal models
have simple solutions to these tests as well

higgs gravities
analogue gravities
have resolved nearly all of the known tests
of modern experiment

and as would be expected
there is overlap with possibilities in superstrings

some superstring vacua predict spontaneous local lorentz violation
as kostelecky predicted years ago
now
it has been seen that some of the more minimal models
can give quantum gravity
as a higgs mechanism result of this violation

so there is not a ruling out by this approach
superstrings are still on the table
but engineering simply dictates
that the simpler approach will ease evolution of our theories

semantic shifts will be smaller and more localised

the same response goes for scientific theories
that ascribe mechanisms the result of
choices of gods and goddesses

every new test requires adding new theory to the model

the models cannot make use of reuse
and prediction suffers

this is how such concerns
so loosely formulated by positivists
can be made rigorous

...

of course
as mathematics
the theoretical foundations should be expanded
in any way a researcher wishes explore

this is not a call to stop any research

it is only a call to evaluate rigorously
models used to drive experiment and technology

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
galathaea: prankster, fablist, magician, liar

..pmi..

galathaea wrote:

> closing one's modules to change
> but allowing them polymorphic behavior
> to open feature spaces

Can I see an actual example of this? I am skeptical of polymorphism
for realistic variation-on-a-theme (VOAT) management unless being
close to the hardware is required such that more flexible VOAT
techniques cannot be used.

-T-

..latha..

On Jun 12, 7:40 pm, topmind <topm...@technologist.com> wrote:
> galathaea wrote:
> > closing one's modules to change
> > but allowing them polymorphic behavior
> > to open feature spaces
>
> Can I see an actual example of this? I am skeptical of polymorphism
> for realistic variation-on-a-theme (VOAT) management unless being
> close to the hardware is required such that more flexible VOAT
> techniques cannot be used.

well
i do not think the architectural open-closed principle
necessarily requires cl***ic polymorphism
in the sense of vtables (or other impl) and interface sigs
( ie. second-order type specifications )
but it requires a consistent access methodology

as long as
plug-ins
deserialised or remote objects
and new development in a feature space
exposes the methodology for working with it
to the code that has closed
then there will be no need to edit or revisit that closed code

and in my experiences with both physics simulations and game engines
i have never had a need to go beyond type polymorphism
( though with regular refactoring and metaprogramming
which probably is equivalent to a more robust voat )

here is an example
------------------

i had a particle simulation engine
that i wanted to expand into a more general simulation engine

it had an object Space
which was basically an ***ociative container for Existents
that ***ociated euclidean Points to each member
and exposed methods to iterate over the Existents
inspect blocks of Space
and so on

each Existent had its own interface
exposed to the PhysicsEngine module
which was a collection of objects
that evolved the Existents in Space
according to some time span
or imaginary time / thermodynamic relaxation

this worked great for my particle simulator
but i found that each Existent was basically holding
another Point object for momentum
and the PhysicsEngine was getting its evolution data
from both the Space and its Existents
and i wanted the existent to only deal with interaction data
( fields and such )
and have the dynamics held by the container
( for the VisualisationEngine components )

in other words
i didn't want Existents to change with time

what i really needed was a StateSpace

but this still exposed much the same container interface
and the refactor was actually quite quick and painless

it was interesting that this change allowed me
to expose basic calculational accessors to the PhysicsEngine
like the poisson bracket
and differentials

at that point
i realised i could actually go much furthur with the design
and abstracted out a Geometry interface
to present this data to the PhysicsEngine components

this turned out an extremely useful abstraction
as i could now model various noneuclidean manifolds
with a generic poisson manifold interface

i even found that narrowing the interface
to only include the bare minimum operations needed
hilbert state spaces were possible
and quantum simulations were possible with the engine

the interface of state data
grew into a facet of observables attached to a given geometry
and these observables were what the VisualisationEngine used

at that point
the engine became sufficiently general
for all things i was interested at the time
and much of the cores of the various components
have remained closed ever since

instead of only Points
the new StateSpace abstraction is general enough
for Fields and other many-dimensional state spaces
and the Geometry interface even allows pointless geometries!

i have been able to run lattice simulations
and other discretisations like graph topologies

...

now
this example may support your point
because refactoring was needed to expand the capabilities

but code development is always needed when adding feature points
and the steps i took
were always just the minimum of what i needed
even though they regularly allowed more variation than needed

also
the core of code that never needed to be touched
grew with each change
so that by the last geometric abstractions
i was modifying boundary interfaces
and new implementation objects
almost exclusively

that i think is the goal of software architecture
and it follows closely the evolution of physics

modern theoretical physics
continues the abstraction process into
more general c* algebras of observables
over various algebraic state spaces
which all seem quite easy to incorporate in such an architecture

noncommutativity of position points
in a general hopf bialgebra setting
is basically accounted for in the interface already
so that direction is possible

i haven't had any need, desire, or time to run such
but that is not the point

the point is that science can progress
by keeping the capabilities of the past
and allowing new and more powerful theories
by adjusting its ontology in these architecturally sound ways

refactorings are semantic shifts
like that which occurred in relativity
when space and time became spacetime
with minkowskian metric and new notions of simultanaeity

since semantic shifts have been rigorised
through rewriting logics and quantaloidal categories
i really think this may be a good foundational approach

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
galathaea: prankster, fablist, magician, liar