Re: The Complexity And Tedium of Software Engineering
verec wrote: On 2009-06-05 21:03:33 +0100, Kenneth Tilton said: When progress stops we will have time to polish our systems, not before. Is that an endorsement of mediocrity? No, of General Patton. hth, kt -- http://mail.python.org/mailman/listinfo/python-list
Re: The Complexity And Tedium of Software Engineering
On 2009-06-05 21:03:33 +0100, Kenneth Tilton said: When progress stops we will have time to polish our systems, not before. Is that an endorsement of mediocrity? -- JFB -- http://mail.python.org/mailman/listinfo/python-list
Re: The Complexity And Tedium of Software Engineering
Xah Lee wrote: On Jun 3, 11:50 pm, Xah Lee wrote: Of interest: • The Complexity And Tedium of Software Engineering http://xahlee.org/UnixResource_dir/writ/programer_frustration.html Addendum: 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. Quibble: those are not /tedious/. Those are as fascinating as an episode of House, trying not only to get new information but how to get it and how to figure out when some information already in hand is actually misinformation, a classic solution to hard problems. Also figuring out coincidences mistaken for cause and effect. But that is just a quibble, ie, I think you need a different word, and it is OK if it still conveys some form of unleasantness. Hair-pulling? Head-banging? 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. 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. I think you are looking for an immaculate road system on a volcanic island still growing ten feet a day. 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. But when would we write the software? Even with all the head-banging, look what we have been able to do with computers, leaving aside for the moment the flight control algorithms of the Airbus? When progress stops we will have time to polish our systems, not before. But then you will be able to use the word "tedium". kt -- http://mail.python.org/mailman/listinfo/python-list
Re: The Complexity And Tedium of Software Engineering
John Thingstad wrote: På Fri, 05 Jun 2009 08:07:39 +0200, skrev Xah Lee : On Jun 3, 11:50 pm, Xah Lee 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. [snip] The actual phrase was "/seemingly/ trivial problems", ie it /looks/ simple at first glance. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Complexity And Tedium of Software Engineering
På Fri, 05 Jun 2009 08:07:39 +0200, skrev Xah Lee : On Jun 3, 11:50 pm, Xah Lee 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 Ubuntu Linux.) 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 redundancy. 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. - John Thingstad -- http://mail.python.org/mailman/listinfo/python-list
Re: The Complexity And Tedium of Software Engineering
On Jun 3, 11:50 pm, Xah Lee wrote: > Of interest: > • The Complexity And Tedium of Software Engineering > http://xahlee.org/UnixResource_dir/writ/programer_frustration.html Addendum: 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. 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. 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. 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. Xah ∑ http://xahlee.org/ ☄ On Jun 3, 11:50 pm, Xah Lee wrote: > Of interest: > • The Complexity And Tedium of Software Engineering > http://xahlee.org/UnixResource_dir/writ/programer_frustration.html > > in particular, there are 2 issues with emacs that might be interesting > here. > > plain text version follows > -- > > The Complexity And Tedium of Software Engineering > > Xah Lee, 2009-06-02 > > This page is a blog of a experience of few examples that illustrates > some seemingly trivial task can become quite tedius and complicated in > the software industry. > > A Complexity with Emacs > > Discovered a emacs problem. > > Summary: > > • Seems that emacs 23 will have a problem loading a css-mode written > by Stefan Monnier > > • The css-mode.el file does not contain any sort of version number, > which makes the problem worse. > > Detail: I have a Mac running emacs 22 with OS X, and i have PC running > emacs 23 and Windows Vista. When i use the emacs 23 to load css mode, > it gives this error: “if: Wrong type argument: integerp, (0 . 8)”. > > The problem seems simple in retrospect, but wasn't simple at all when > you trying to get things done and things don't work as expected. > Here's the story. > > Emacs 22 does not have a css mode, emacs 23 does. There's one css mode > written by Stefan. I've been using it on the Mac for the past couple > of years. The same package is now bundled into emacs 23, which i'm > using on PC. However, the code in the 2 files are not identical. I > have my emacs setup to load css mode. Since i am migrating to PC, > alone with my whole emacs system, and am setting up a Mac and PC and > network that'd let me work with either machine harmoniously. On the > PC, when i start css mode, it gives error, but not always. You don't > know what's wrong. It could be a fuckup in the emacs distro i'm using > on PC (which is emacsW32), or it could be emacs 23 problem (emacs 23 > is still in beta), or it could be something in my emacs customization > that works perfectly well on the Mac but not on the PC with whole new > environment. Eventually, i realized that's because sometimes i started > plain emacs 23 without loading my own setup, it was using the bundled > css mode, so no error, but when i loaded my own emacs setup, it gives > error. This seems still simple in retrospect, but wasn't then. I added > a version check to my emacs init file(s), so that if emacs is 23, > don't load my css mode. The next day, same symptom occurs. Eventually > I realized that's because the load path is set so that my own version > of css mode comes before the bundled css mode, so that, when i load > css, again my old version is loaded. Eventually, the solution is to > check if css mode bundled with emacsW32 runs ok on emacs 22 on my Mac; > if so, simply use that as the single source for my Mac and PC. When > doing this work on checking what versions are the files, i realized > that the 2 css mode's files don't contain version number at all. All > this takes 5 minutes to read, but was one of
