RE: [Edu-sig] RE: [Tutor] Off topic musings
On 20 Aug 01, at 22:06, Morris, Steve wrote:
Maybe. Really I'm just interested in what exactly a theoretical basis for software engineering would look like.
I think my problem with this discussion, and the cause of the different approaches, is that you ask your question in ambiguous terms. You ask for a "theory of everything" in the generic category of software engineering. Software engineering is not a science but a discipline, or perhaps a skill, or maybe just programming. The term 'software engineering" usually refers to the process of writing programs with the imputation that these programs match some standard; whether it be correctness, or matching the specs, or merely being useful. It is thus not suprising that we keep getting lost in the process and techniques of programming. That statement is almost a tautology. What else would a theory of "software engineering" address. I would like you to restate your query with a better idea of the specific questions you are trying to answer. I know what specific questions a "unified field theory" is trying to answer. What question are you trying to answer?
On 21 Aug 01, at 10:26, Morris, Steve wrote:
On 20 Aug 01, at 22:06, Morris, Steve wrote:
Maybe. Really I'm just interested in what exactly a theoretical basis for software engineering would look like.
I think my problem with this discussion, and the cause of the different approaches, is that you ask your question in ambiguous terms. You ask for a "theory of everything" in the generic category of software engineering.
Sure but as Insaid in another pist thats because the SOTA papers I was reading were headed "Software Engineering". It is the generally used term, although I note that there does seem to be a trend to other names such as Infomatics. This is probably a good thing, where SE is a subset of Infomatics.
Software engineering is not a science but a discipline, or perhaps a skill, or maybe just programming.
With this I disagree however. The original concept of SE was to get away from that view, to industrialise the production of software, eventually to automate it in the sameway that other engineering disciplines automate production. When an electrical engineer takes a basic requirement and transforms it into a soecification which in turn is synthesised as a circuit the entire process is built on a fundamental understanding of the nature of the raw materials. The point made in the papers was that in SE we do not have that basic understanding. We do not really know the materials with which we work.
the process of writing programs with the imputation that these programs match some standard; whether it be correctness, or matching the specs, or merely being useful.
That is one aspect but it neglects areas such as the study of softawre entropy, maintenance, performance and automatic production. Arguably these are related to software production, but they are much more than just writing programs.
What else would a theory of "software engineering" address.
Indeed, thats why I probably should be saying CS or Infomatics. But the basic question remains valid.
I would like you to restate your query with a better idea of the specific questions you are trying to answer.
OK, I'll try again. Basically I was asking two questions: 1) Given the SOTA papers repeated insistence that to make further significant progress we need a better understanding of xxxx where xxxx is whatever fundamental subject matter underpins CS. I therefore ask, What would xxx look like so that we might study it? 2) My personal guess is that xxx is "information" and that one approach would be to model it ina layered fashion. Has anyone else done this? OIf so where can I get a reerence? Is that any clearer? Alan g
At 06:28 PM 8/21/2001 +0100, you wrote:
The point made in the papers was that in SE we do not have that basic understanding. We do not really know the materials with which we work.
The compiler is a mass-production module which you might say automates a lot of steps. But at the higher level, we have human ingenuity developing algorithms based on insights. I don't see any way to automate that entirely. The algorithm thread stretches back to pre-computer days and is therefore "platform independent" in a stronger sense. I'd start with algorithms, which is not entirely distinct from data structures; the two concepts are intimately interwoven, as are "game rules" and "game board" or "game apparatus". Kirby
On 21 Aug 01, at 18:28, alan.gauld@freenet.co.uk wrote:
approach would be to model it ina layered fashion. Has anyone else done this? OIf so where can I get a reerence?
3 typos in two lines - Doh! My new mail client has a spell checker, I really must get used to using it before I send. Sorry for that. Alan G
FYI, still doing my usual math-through-programming schtick w/ the math teachers on math-learn etc., with Python peaking through at every turn. Recent examples: http://www.mathforum.com/epigone/math-learn/vultingsheld http://www.mathforum.com/epigone/math-learn/kinblilrend Mostly redundant with earlier posts, but maybe interesting to those who haven't tuned in my standard stuff. I understand we'll be able to subclass modules soon, treating them pretty much like classes. That's interesting. I always look forward to new versions of Python. Kirby
participants (3)
-
alan.gauld＠freenet.co.uk -
Kirby Urner -
Morris, Steve