For Programmers: Free Programming Magazines  


Home > Archive > Software Engineering > September 2007 > Philosophy and Formal Methods. (Was: New theory of Software Engineering)









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Philosophy and Formal Methods. (Was: New theory of Software Engineering)
Valery Kolesnyk

2007-09-21, 4:21 am

I welcome readers of NewsGroup

Two years ago I have informed that has developed the new theory of
programming. My message has been met negatively. But here has passed
two years and anything new has not appeared. I again approve: "Exit
from deadlock in Software Engineering is possible already now". I
again come back to this theme.
Among positive characteristics of the offered theory I have mentioned
new capacious system of concepts. Now I understand, that it is the
main and most essential advantage of the theory.
In a basis of transition from programming on a machine code to
programming in language of the assembler, and then (that is more
essential) to programming on string algorithmic languages change of
concepts laid. There was a movement from less capacious concepts to
more capacious. Transition has been accomplished from a writing of
the command with numbers of cells as operands to a writing of the
operator which was realized in the form of several commands (from one
up to several tens).
The same process - change of concepts - should proceed.
Now string algorithmic languages became the deterrent in development
Software Engineering. The damnation of string languages prevails above
Software Engineering
Modern algorithmic languages in the basis have very small detailed
concepts. Basic graphic means of an algorithmic language is the
operator. But it is necessary to manipulate certain models or designs
(hyperoperators) which cover tens and more operators of an existing
algorithmic language. Other concepts should underlie these models or
designs (hyperoperators).
At a writing of the program the programmer thinks about actions which
are represented by the operator and operands and does not think of
realization of the operator in the form of a code. Progress in
productivity will be reached when the programmer will think of actions
which are realized by certain hyperoperators. The hyperoperator will
be adequate to tens operators of an algorithmic language. The
programmer will not think of how this hyperoperator is realized in
operators of an algorithmic language or in a machine code. The
operator of an algorithmic language is supported, as a rule, by a
reliable code. As well the hyperoperator should be supported, a
reliable code.
Also it is necessary to compress control structures so to not write a
condition of branching or a condition of end of a cycle.
Instead of replacement of one algorithmic language with another it is
necessary to speak about replacement of one concepts or abstraction
other one - more capacious. And what sort syntax will realize these
concepts and abstraction, not so essentially. It can be graphic
language, tabulared one, or a certain symbiosis of graphic, tabulared
and string language though the most preferable is graphic one. And
this direction does not have alternative in Software Engineering (on
the present level of development).
In scientific community already there is a understanding of that
Software Engineering sharply requires in high-level abstractions: "-
Abstraction. Real systems are difficult to specify and verify without
abstractions. We need to identify different kinds of abstractions,
perhaps tailored for certain kinds of systems or problem domains, and
we need to develop ways to justify them formally, perhaps using
mechanical help. (Formal Methods: State of the Art and Future
Directions EDMUND M. CLARKE, JEANNETTE M. WING, ET AL.) "
The question consists in how to construct abstraction or where them to
find. On my belief, for this purpose the philosophy also is necessary.
The kernel and power of the offered theory is system of abstraction
and system of defaults. For development and researches of system of
abstraction I used some aspects Cartesian philosophy and a number of
categories which have been researched recently. The method of research
is the analysis of interaction of categories: form - content; object -
image of object; subject - process; function - structure, etc. It has
allowed to create system of abstraction and capacious concepts.
The approach with use of philosophical categories transforms the
mechanism of creation of methods of programming from a circuit of
casual events with uncertain time intervals into predicted, systematic
continuous process.
The problem of creation of system of new, more capacious and more
effective concepts is not solved by means of Software Engineering. It
is a single, unusual problem for such kind of activity. In Software
Engineering there are no necessary means. It is a problem of
philosophy.
My philosophical preparation is far from referring to good. But even
my current rather weak level of preparation has allowed me to create
universal algorithmic model which contains required system of
concepts.
System of concepts, that I have offered, as well as algorithmic model
not complex, but unusual. I earlier have sincerely warned that for its
understanding it is necessary to have a small philosophical practice.
I was not going to humiliate or offend anybody. For understanding of
algorithmic model it is necessary to have experience of abstraction
and a concrete definition, it is necessary to have experience of
vision in two operators of an algorithmic language which are located
nearby, interaction of philosophical categories (form - contents,
object - image of object, structure - function, element - system,
etc.). A problem, which I solve (or which should be solved at deeper
level to scientific community), in an initial stage of the decision -
philosophical, and then mathematical. It is not a problem of
programming.
I am ready to publish, that has made all.
More detailed information on SITE http://WWW.k-v-g.pochta.ru

Yours faithfully

Valery Kolesnyk
Ukraine
****************
Note 1.
My idea that only the philosophy can help to find to researchers a way
out of deadlock in which is Software Engineering, has met a sneer:
"May I suggest you move beyond Kuhn and Plato, try a little Hume and
Wittgenstein, Frege and Russell (but be prepared to disagree), more
recent fellows like Chomksy, Fodor, Dennett, Quine, Cummins, Searle,
Derrida, some additional history of science like Suppe, some anti-
science like Feyerabend, go back and give a charitable reading to
Descartes, and get back to us real soon with something shorter and
clearer and more narrowly focused."
But idea that only the philosophy can and should help to leave
deadlock to applied sciences, not I the first have told. Philosophers-
materialists spoke about it. Schopenhauer spoke about it directly.
Hilbert was the mathematician and the philosopher. Also great opening
in the physics in the beginning of the last century were accompanied
by the deep analysis of gnoseological bases of a physical science
(Niels Bohr, Verner Gejzenberg, S.I.Vavilov).
That the modern philosophy cannot make it(or does not want) is .
What the philosophy has put itself in such position what even idea to
address to it for the help is represented ridiculous (or heretical?)
is even more .
Note 2.
The first. That is " ... Something shorter and clearer and more narrowly
focused ", - already was more than enough.
The second. That I offer, is not complex for understanding. And that
in Software Engineering laid on a surface and has been easily
understood, is already opened and is invented.
The third. That I earlier spread on site, was in the compressed form
and all is far not. Unfortunately, at one university do not teach, to
that as in the compressed and clear form (on two - three pages) to
state internally coordinated system of abstraction for the theory of
programming.

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2010 codecomments.com