The Complexity And Tedium of Software Engineering
jpthing at online.no
Fri Jun 5 03:32:05 EDT 2009
På Fri, 05 Jun 2009 08:07:39 +0200, skrev Xah Lee <xahlee at gmail.com>:
> On Jun 3, 11:50 pm, Xah Lee <xah... at gmail.com> wrote:
> The point in these short examples is not about software bugs or
> problems. It illustrates, how seemingly trivial problems, such as
> networking, transferring files, running a app on Mac or Windwos,
> upgrading a app, often involves a lot subtle complexities. For mom and
> pop users, it simply stop them dead. For a senior industrial
> programer, it means some conceptually 10-minutes task often ends up in
> hours of tedium.
What on earth gave you the idea that this is a trivial problem?
Networks have been researched and improved for the last 40 years!
It is a marvel of modern engineering that they work as well as they do.
> In some “theoretical” sense, all these problems are non-problems. But
> in practice, these are real, non-trivial problems. These are
> complexities that forms a major, multi-discipline, almost unexplored
> area of software research.
Again, it is it not a trivial problem theoretically.
Unexplored? What world are you on?
> I'm trying to think of a name that
> categorize this issue. I think it is a mix of software interface,
> version control, release control, formal software specification,
> automated upgrade system, etc. The ultimate scenario is that, if one
> needs to transfer files from one machine to another, one really should
> just press a button and expect everything to work. Software upgrade
> should be all automatic behind the scenes, to the degree that users
> really don't need fucking to know what so-called “version” of software
> he is using.
Actually they mostly are. At least on my machine. (I use Windows XP and
> Today, with so-called “exponential” scientific progress, and software
> has progress tremendously too. In our context, that means there are a
> huge proliferation of protocols and standards. For example, unicode,
> gazillion networking related protocols, version control systems,
> automatic update technologies, all comes into play here. However, in
> terms of the above visionary ideal, these are only the beginning.
> There needs to be more protocols, standards, specifications, and more
> strict ones, and unified ones, for the ideal scenario to take place.
No, there are already to many protocols and the ideas of how a network
infrastructure should be built are mostly in place. I think we would
benefit from "cleaning up" the existing interface. That is by removing
What does need further research is distributed processing. Again this is a
highly complex problem and a lot of work has been put into trying to make
simpler and more manageable interfaces and protocol's. See for example the
languages Erlang and Oz to get an idea.
More information about the Python-list