First of all your questions are very interesting!

I thing that this issue includes:

1. Physical constrains of computer technology.

2. Human-computer interactions constrains.

For example:

Now “computer” is the “home-made” instrument. If in the future “computer” will be

“autonomous being” are we able to interact with it and how ?

This interesting question was discussed in detail in the SEMAT Workshop on General Theories of Software Engineering (GTSE 2013), this year co-located with the ICSE. You will find pointers to the papers on the workshop 2013 homepage: http://semat.org/?page_id=632.

Yes, some ten papers where presented at the GTSE 2013, and each had a different take on the topic, so that could be interpreted as "we don't know", or at least "we all disagree". Some papers, such as those by Smolander & Päivärinta, Adolph & Kruchten, and Ralph proposed focused on the social forces. Others, such as those by Ekstedt, Perry and Batory, concentrated on the technical aspects.

There is a call for contributions to a special issue of the Science of Computer Programming journal where anyone can submit a paper presenting their views, http://www.journals.elsevier.com/science-of-computer-programming/call-for-papers/special-issue-on-general-theories-of-software-engineering/.

Personally, I think there are three fields that impose laws on software and software engineering: (i) the human cognitive faculties, (ii) organizational structure (in particular communication and coordination), and (iii) formal languages and automata.

Dear Pontus,

May be both (i) and (iii) are partly related ?

Dear Joseph,

As I see it, (iii) contains the "impersonal" laws of software, including requirements of consistency, limits of computability, expressiveness, etc. An example of a type (iii) "law" might be "programs cannot be self-contradictory".

(i), on the other hand, details the limits of our human problem-solving capacities. These cognitive limits explain many aspects of software, for instance why programming languages feature such things as subroutines and information-hiding, why aspect-orientation can be useful, etc. An example of a type (i) "law" might be "the capacities of the human cognitive system limits the complexity of programs."

Dear Pontus,

I need to think about: "the capacities of the human cognitive system limits the complexity of programs." What do you mean: "the complexity of a program" ?

Dear Joseph,

There are various more or less meaningful measures of program complexity, e.g. the Halstead or McCabe complexity measures. You could use such a measure in my proposed type (i) law above.

What I mean is that any program that is too complex for the human mind to grasp, cannot exist. I believe that this is a kind of law of software.

Of course, what the human mind can grasp depends on our tools. High-level programming languages, for instance, make it possible for us to understand (and develop) software systems that are impossible to comprehend in low-level languages.

Dear Peter,

One of the main functions of modern software engineering tools, such as HLLs, is to separate concerns, so that a single developer does not need to understand everything in a system (in particular, at the same time). Yet, even though no single person grasps the whole, some complex systems can be understood, albeit by different developers and at different times.

None of the papers in the workshop focused on automata theory, so you will not find an answer to your question among them.

Interesting question indeed. Here is an interesting read.

Rombach D. Empirical software engineering models: Can they become the equivalent of physical laws in traditional engineering?. Int J Software Informatics, Vol.5, No.3 (2011): 525{534. http://www.ijsi.org/1673-7288/5/i94.htm