Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6775 > unrolled thread

To all who write uninstallation programs for software you distribute

Back to article view | Back to comp.programming

Contents

  To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-23 18:13 -0400
    Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-24 06:44 +0000
      Re: To all who write uninstallation programs for software you distribute Julio Di Egidio <julio@diegidio.name> - 2016-07-24 04:53 -0700
        Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-25 04:13 +0000
          Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 08:28 +0100
    Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 09:40 +0100
      Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 10:00 -0500
        Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 16:18 +0100
          Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 11:34 -0400
            Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 16:46 +0100
              Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 10:55 -0500
                Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 17:08 +0100
                  Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 12:24 -0400
                    Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 17:37 +0100
                      Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 13:16 -0400
                        Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 18:53 +0100
                          Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 15:11 -0400
                            Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 14:45 -0500
                              Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 21:31 +0100
                                Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 18:06 -0400
                                  Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:53 +0100
                              Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 18:04 -0400
                                Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:47 +0100
                                Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 19:34 -0400
                        Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 14:03 -0400
              Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 12:10 -0400
                Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 17:36 +0100
                Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 11:37 -0500
                  Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 13:24 -0400
                  Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 18:29 -0500
                    Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 20:34 -0400
                    Re: To all who write uninstallation programs for software you distribute Mark Storkamp <mstorkamp@yahoo.com> - 2016-07-25 10:00 -0500
                      Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-25 11:22 -0500
                      Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-25 18:55 +0000
                        Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-26 00:19 -0400
                          Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-26 04:24 +0000
                          Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-26 09:13 -0500
                            Re: To all who write uninstallation programs for software you distribute Öö Tiib <ootiib@hot.ee> - 2016-07-26 14:11 -0700
                            Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-27 02:58 -0400
                              Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-27 13:47 +0000
            Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 13:24 -0400
      Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 13:40 -0400
        Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 13:42 -0400
      Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-24 18:29 +0000
    Re: To all who write uninstallation programs for software you distribute SIKDER EMRAN <sikderemran4321@gmail.com> - 2016-07-31 03:19 -0700

Page 1 of 3  [1] 2 3  Next page →

#6775 — To all who write uninstallation programs for software you distribute

To all who write uninstallation programs for software you distribute:

If your uninstallation program can't leave the machine in the
condition you found it, then tell the user what is different.

I just tried to uninstall a program. Just before the uninstaller
closed, it reported this unhappy message:

"Couldn't remove some components. They can be removed manually."

So the program was smart enough to know that it was leaving trash on
my machine, but the programmer wasn't kind enough to tell me anything
else about the trash.

Those things you couldn't remove were ...?

You know they couldn't be removed, but you wouldn't tell me which ones
(and where) they are ... because?!!

You couldn't find anywhere to leave a text file with this information
... oh, let's see ... maybe the user's Documents folder? They couldn't
have one of those, could they?

[toc] | [next] | [standalone]

#6776

On 2016-07-23, Wally W <ww84wa@aim.com> wrote:
> To all who write uninstallation programs for software you distribute:
>
> If your uninstallation program can't leave the machine in the
> condition you found it, then tell the user what is different.
>
> I just tried to uninstall a program. Just before the uninstaller
> closed, it reported this unhappy message:
>
> "Couldn't remove some components. They can be removed manually."

This strongly suggests that you're using a certain shit OS. Furthermore,
the developers of the pitiful crap that you're (quite understandably)
uninstalling couldn't be bothered to figure out how to use the API
for having "busy" files removed at the next reboot.

[toc] | [prev] | [next] | [standalone]

#6778

On Sunday, July 24, 2016 at 8:44:38 AM UTC+2, Kaz Kylheku wrote:
> On 2016-07-23, Wally W <ww84wa@aim.com> wrote:
> > To all who write uninstallation programs for software you distribute:
> >
> > If your uninstallation program can't leave the machine in the
> > condition you found it, then tell the user what is different.
> >
> > I just tried to uninstall a program. Just before the uninstaller
> > closed, it reported this unhappy message:
> >
> > "Couldn't remove some components. They can be removed manually."
> 
> This strongly suggests that you're using a certain shit OS. Furthermore,
> the developers of the pitiful crap that you're (quite understandably)
> uninstalling couldn't be bothered to figure out how to use the API
> for having "busy" files removed at the next reboot.

I shall eventually conclude that you too are simply a fucking idiot with some degree in computer science and not the faintest what that is actually about.  Condolences.

Julio

[toc] | [prev] | [next] | [standalone]

#6808

On 2016-07-24, Julio Di Egidio <julio@diegidio.name> wrote:
> On Sunday, July 24, 2016 at 8:44:38 AM UTC+2, Kaz Kylheku wrote:
>> On 2016-07-23, Wally W <ww84wa@aim.com> wrote:
>> > To all who write uninstallation programs for software you distribute:
>> >
>> > If your uninstallation program can't leave the machine in the
>> > condition you found it, then tell the user what is different.
>> >
>> > I just tried to uninstall a program. Just before the uninstaller
>> > closed, it reported this unhappy message:
>> >
>> > "Couldn't remove some components. They can be removed manually."
>> 
>> This strongly suggests that you're using a certain shit OS. Furthermore,
>> the developers of the pitiful crap that you're (quite understandably)
>> uninstalling couldn't be bothered to figure out how to use the API
>> for having "busy" files removed at the next reboot.
>
> I shall eventually conclude that you too are simply a fucking idiot
> with some degree in computer science and not the faintest what that is
> actually about.  Condolences.

I'm afraid I'm a hopeless case, but for the benefit of better equipped
others, you might want to share your understanding itself, rather than
mere assurances that you have more of it than someone else.

[toc] | [prev] | [next] | [standalone]

#6809

On 25/07/16 05:13, Kaz Kylheku wrote:
> On 2016-07-24, Julio Di Egidio <julio@diegidio.name> wrote:

<snip>

>> I shall eventually conclude that you too are simply a fucking idiot
>> with some degree in computer science and not the faintest what that is
>> actually about.  Condolences.
>
> I'm afraid I'm a hopeless case, but for the benefit of better equipped
> others, you might want to share your understanding itself, rather than
> mere assurances that you have more of it than someone else.

You're talking to a man who, quite literally, doesn't know the meaning 
of the word 'plonk'.

You and I have by no means always seen eye to eye. Even so, if I were 
ever in a position where I had to bet my life on a choice between your 
understanding and his, I know /exactly/ where my money would go.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6777

On 23/07/16 23:13, Wally W. wrote:
> To all who write uninstallation programs for software you distribute:

Whenever possible, I prefer not to do this. To delete my software, you 
just delete it, and you're done. Either

cd where/did/you/put/it
rm *

or maybe, just maybe, there are sub-directories, so:

cd where/did/you/put/it
rm -rf *

(careful!)

or, if you're on Windows, one of the many Windows equivalents of doing 
the same thing (such as dragging a pretty yellow box onto a picture of a 
dustbin - alas, I can't promise sweeties to those who get this right).

> If your uninstallation program can't leave the machine in the
> condition you found it, then tell the user what is different.

Hear, hear! But if your program /needs/ an uninstallation program, there 
had better be an extraordinarily good reason. (And sometimes there is. 
But it's rarer than many people think.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6779

"Richard Heathfield" wrote:

> On 23/07/16 23:13, Wally W. wrote:
>> To all who write uninstallation programs for software you distribute:
>
> Whenever possible, I prefer not to do this. To delete my software, you 
> just delete it, and you're done. Either
>
> cd where/did/you/put/it
> rm *
>
> or maybe, just maybe, there are sub-directories, so:
>
> cd where/did/you/put/it
> rm -rf *
>
> (careful!)
>
> or, if you're on Windows, one of the many Windows equivalents of doing the 
> same thing (such as dragging a pretty yellow box onto a picture of a 
> dustbin - alas, I can't promise sweeties to those who get this right).
>
>> If your uninstallation program can't leave the machine in the
>> condition you found it, then tell the user what is different.
>
> Hear, hear! But if your program /needs/ an uninstallation program, there 
> had better be an extraordinarily good reason. (And sometimes there is. But 
> it's rarer than many people think.)

I long for the good old days too.

But doesn't your approach fail in one of the most elementary cases on 
Windows?  A new program with a new data file. You want to click on the data 
file and invoke the program. How can you do that without changing the data 
used by the OS?  To me, that is SOP and not rare at all. 

[toc] | [prev] | [next] | [standalone]

#6780

On 24/07/16 16:00, Osmium wrote:
> "Richard Heathfield" wrote:
>
>> On 23/07/16 23:13, Wally W. wrote:
>>> To all who write uninstallation programs for software you distribute:
>>
>> Whenever possible, I prefer not to do this. To delete my software, you
>> just delete it, and you're done. Either
>>
>> cd where/did/you/put/it
>> rm *
>>
>> or maybe, just maybe, there are sub-directories, so:
>>
>> cd where/did/you/put/it
>> rm -rf *
>>
>> (careful!)
>>
>> or, if you're on Windows, one of the many Windows equivalents of doing
>> the same thing (such as dragging a pretty yellow box onto a picture of
>> a dustbin - alas, I can't promise sweeties to those who get this right).
>>
>>> If your uninstallation program can't leave the machine in the
>>> condition you found it, then tell the user what is different.
>>
>> Hear, hear! But if your program /needs/ an uninstallation program,
>> there had better be an extraordinarily good reason. (And sometimes
>> there is. But it's rarer than many people think.)
>
> I long for the good old days too.
>
> But doesn't your approach fail in one of the most elementary cases on
> Windows?  A new program with a new data file. You want to click on the
> data file and invoke the program. How can you do that without changing
> the data used by the OS?  To me, that is SOP and not rare at all.

But the /user/ is responsible for setting up that association. The user 
double-clicks on "foo.bar", and Windows says "huh? You'd better choose a 
program for that", and the user chooses my program, and that's the 
user's choice, so it's the user's problem.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6781

In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
> 
> On 24/07/16 16:00, Osmium wrote:
> > "Richard Heathfield" wrote:
> >
> >> On 23/07/16 23:13, Wally W. wrote:
> >>> To all who write uninstallation programs for software you distribute:
> >>
> >> Whenever possible, I prefer not to do this. To delete my software, you
> >> just delete it, and you're done. Either
> >>
> >> cd where/did/you/put/it
> >> rm *
> >>
> >> or maybe, just maybe, there are sub-directories, so:
> >>
> >> cd where/did/you/put/it
> >> rm -rf *
> >>
> >> (careful!)
> >>
> >> or, if you're on Windows, one of the many Windows equivalents of doing
> >> the same thing (such as dragging a pretty yellow box onto a picture of
> >> a dustbin - alas, I can't promise sweeties to those who get this right).
> >>
> >>> If your uninstallation program can't leave the machine in the
> >>> condition you found it, then tell the user what is different.
> >>
> >> Hear, hear! But if your program /needs/ an uninstallation program,
> >> there had better be an extraordinarily good reason. (And sometimes
> >> there is. But it's rarer than many people think.)
> >
> > I long for the good old days too.
> >
> > But doesn't your approach fail in one of the most elementary cases on
> > Windows?  A new program with a new data file. You want to click on the
> > data file and invoke the program. How can you do that without changing
> > the data used by the OS?  To me, that is SOP and not rare at all.
> 
> But the /user/ is responsible for setting up that association. The user 
> double-clicks on "foo.bar", and Windows says "huh? You'd better choose a 
> program for that", and the user chooses my program, and that's the 
> user's choice, so it's the user's problem.

And the tech support guys think badly of you when they have to remote-
access 10,000 machines and set up that association that _should_ have 
been set up by the installer.

[toc] | [prev] | [next] | [standalone]

#6782

On 24/07/16 16:34, J. Clarke wrote:
> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
>>
>> On 24/07/16 16:00, Osmium wrote:
>>> "Richard Heathfield" wrote:
>>>
>>>> On 23/07/16 23:13, Wally W. wrote:
>>>>> To all who write uninstallation programs for software you distribute:
>>>>
>>>> Whenever possible, I prefer not to do this. To delete my software, you
>>>> just delete it, and you're done. Either
>>>>
>>>> cd where/did/you/put/it
>>>> rm *
>>>>
>>>> or maybe, just maybe, there are sub-directories, so:
>>>>
>>>> cd where/did/you/put/it
>>>> rm -rf *
>>>>
>>>> (careful!)
>>>>
>>>> or, if you're on Windows, one of the many Windows equivalents of doing
>>>> the same thing (such as dragging a pretty yellow box onto a picture of
>>>> a dustbin - alas, I can't promise sweeties to those who get this right).
>>>>
>>>>> If your uninstallation program can't leave the machine in the
>>>>> condition you found it, then tell the user what is different.
>>>>
>>>> Hear, hear! But if your program /needs/ an uninstallation program,
>>>> there had better be an extraordinarily good reason. (And sometimes
>>>> there is. But it's rarer than many people think.)
>>>
>>> I long for the good old days too.
>>>
>>> But doesn't your approach fail in one of the most elementary cases on
>>> Windows?  A new program with a new data file. You want to click on the
>>> data file and invoke the program. How can you do that without changing
>>> the data used by the OS?  To me, that is SOP and not rare at all.
>>
>> But the /user/ is responsible for setting up that association. The user
>> double-clicks on "foo.bar", and Windows says "huh? You'd better choose a
>> program for that", and the user chooses my program, and that's the
>> user's choice, so it's the user's problem.
>
> And the tech support guys think badly of you when they have to remote-
> access 10,000 machines and set up that association that _should_ have
> been set up by the installer.

I understand your point but I don't agree with it. File associations are 
a pain in the neck, because they rely on a false premise - i.e. that the 
file extension uniquely determines the type of the file.

I once had to write a program to inspect the first few bytes of a PDF to 
discover whether it was a Portable Document Format file (a document) or 
a Program Description File (a format used by a screen layout descriptor 
utility for COBOL programmers). The program had to decide which one it 
was, and then call either Acrobat or the screen layout thing - and the 
users associated .pdf with /my/ program, rather than Acrobat or the utility.

File extensions go at least as far back as VM/CMS, but they were never 
designed to uniquely determine the type of file (even VM/CMS used file 
mode descriptors rather than extensions to determine whether a file was 
supposed to be executable). File associations were a badly-designed 
overlay onto file extensions, and Microsoft has done little, if 
anything, to address the problems that file associations cause.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6783

"Richard Heathfield" wrote:

> On 24/07/16 16:34, J. Clarke wrote:
>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
>>>
>>> On 24/07/16 16:00, Osmium wrote:
>>>> "Richard Heathfield" wrote:
>>>>
>>>>> On 23/07/16 23:13, Wally W. wrote:
>>>>>> To all who write uninstallation programs for software you distribute:
>>>>>
>>>>> Whenever possible, I prefer not to do this. To delete my software, you
>>>>> just delete it, and you're done. Either
>>>>>
>>>>> cd where/did/you/put/it
>>>>> rm *
>>>>>
>>>>> or maybe, just maybe, there are sub-directories, so:
>>>>>
>>>>> cd where/did/you/put/it
>>>>> rm -rf *
>>>>>
>>>>> (careful!)
>>>>>
>>>>> or, if you're on Windows, one of the many Windows equivalents of doing
>>>>> the same thing (such as dragging a pretty yellow box onto a picture of
>>>>> a dustbin - alas, I can't promise sweeties to those who get this 
>>>>> right).
>>>>>
>>>>>> If your uninstallation program can't leave the machine in the
>>>>>> condition you found it, then tell the user what is different.
>>>>>
>>>>> Hear, hear! But if your program /needs/ an uninstallation program,
>>>>> there had better be an extraordinarily good reason. (And sometimes
>>>>> there is. But it's rarer than many people think.)
>>>>
>>>> I long for the good old days too.
>>>>
>>>> But doesn't your approach fail in one of the most elementary cases on
>>>> Windows?  A new program with a new data file. You want to click on the
>>>> data file and invoke the program. How can you do that without changing
>>>> the data used by the OS?  To me, that is SOP and not rare at all.
>>>
>>> But the /user/ is responsible for setting up that association. The user
>>> double-clicks on "foo.bar", and Windows says "huh? You'd better choose a
>>> program for that", and the user chooses my program, and that's the
>>> user's choice, so it's the user's problem.
>>
>> And the tech support guys think badly of you when they have to remote-
>> access 10,000 machines and set up that association that _should_ have
>> been set up by the installer.
>
> I understand your point but I don't agree with it. File associations are a 
> pain in the neck, because they rely on a false premise - i.e. that the 
> file extension uniquely determines the type of the file.
>
> I once had to write a program to inspect the first few bytes of a PDF to 
> discover whether it was a Portable Document Format file (a document) or a 
> Program Description File (a format used by a screen layout descriptor 
> utility for COBOL programmers). The program had to decide which one it 
> was, and then call either Acrobat or the screen layout thing - and the 
> users associated .pdf with /my/ program, rather than Acrobat or the 
> utility.
>
> File extensions go at least as far back as VM/CMS, but they were never 
> designed to uniquely determine the type of file (even VM/CMS used file 
> mode descriptors rather than extensions to determine whether a file was 
> supposed to be executable). File associations were a badly-designed 
> overlay onto file extensions, and Microsoft has done little, if anything, 
> to address the problems that file associations cause.

I probably agree with all that.  But it's a bit like complaining about the 
way words are spelled in the English language.  For the most part, it works, 
and people expect other people to honor the conventions. 

[toc] | [prev] | [next] | [standalone]

#6784

On 24/07/16 16:55, Osmium wrote:
> "Richard Heathfield" wrote:
>
>> On 24/07/16 16:34, J. Clarke wrote:
>>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
>>>>
>>>> On 24/07/16 16:00, Osmium wrote:
>>>>> "Richard Heathfield" wrote:
>>>>>
>>>>>> On 23/07/16 23:13, Wally W. wrote:
>>>>>>> To all who write uninstallation programs for software you
>>>>>>> distribute:
>>>>>>
>>>>>> Whenever possible, I prefer not to do this. To delete my software,
>>>>>> you
>>>>>> just delete it, and you're done. Either
>>>>>>
>>>>>> cd where/did/you/put/it
>>>>>> rm *
>>>>>>
>>>>>> or maybe, just maybe, there are sub-directories, so:
>>>>>>
>>>>>> cd where/did/you/put/it
>>>>>> rm -rf *
>>>>>>
>>>>>> (careful!)
>>>>>>
>>>>>> or, if you're on Windows, one of the many Windows equivalents of
>>>>>> doing
>>>>>> the same thing (such as dragging a pretty yellow box onto a
>>>>>> picture of
>>>>>> a dustbin - alas, I can't promise sweeties to those who get this
>>>>>> right).
>>>>>>
>>>>>>> If your uninstallation program can't leave the machine in the
>>>>>>> condition you found it, then tell the user what is different.
>>>>>>
>>>>>> Hear, hear! But if your program /needs/ an uninstallation program,
>>>>>> there had better be an extraordinarily good reason. (And sometimes
>>>>>> there is. But it's rarer than many people think.)
>>>>>
>>>>> I long for the good old days too.
>>>>>
>>>>> But doesn't your approach fail in one of the most elementary cases on
>>>>> Windows?  A new program with a new data file. You want to click on the
>>>>> data file and invoke the program. How can you do that without changing
>>>>> the data used by the OS?  To me, that is SOP and not rare at all.
>>>>
>>>> But the /user/ is responsible for setting up that association. The user
>>>> double-clicks on "foo.bar", and Windows says "huh? You'd better
>>>> choose a
>>>> program for that", and the user chooses my program, and that's the
>>>> user's choice, so it's the user's problem.
>>>
>>> And the tech support guys think badly of you when they have to remote-
>>> access 10,000 machines and set up that association that _should_ have
>>> been set up by the installer.
>>
>> I understand your point but I don't agree with it. File associations
>> are a pain in the neck, because they rely on a false premise - i.e.
>> that the file extension uniquely determines the type of the file.
>>
>> I once had to write a program to inspect the first few bytes of a PDF
>> to discover whether it was a Portable Document Format file (a
>> document) or a Program Description File (a format used by a screen
>> layout descriptor utility for COBOL programmers). The program had to
>> decide which one it was, and then call either Acrobat or the screen
>> layout thing - and the users associated .pdf with /my/ program, rather
>> than Acrobat or the utility.
>>
>> File extensions go at least as far back as VM/CMS, but they were never
>> designed to uniquely determine the type of file (even VM/CMS used file
>> mode descriptors rather than extensions to determine whether a file
>> was supposed to be executable). File associations were a
>> badly-designed overlay onto file extensions, and Microsoft has done
>> little, if anything, to address the problems that file associations
>> cause.
>
> I probably agree with all that.  But it's a bit like complaining about
> the way words are spelled in the English language.  For the most part,
> it works, and people expect other people to honor the conventions.

If it's in the program spec, fair enough, but there'd better be a way to 
remove it, also in the program spec.

If it's not in the program spec, then it's just extra work for no benefit.

And that's true for pretty much any "it", not just file associations.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6786

In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says...
> 
> On 24/07/16 16:55, Osmium wrote:
> > "Richard Heathfield" wrote:
> >
> >> On 24/07/16 16:34, J. Clarke wrote:
> >>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
> >>>>
> >>>> On 24/07/16 16:00, Osmium wrote:
> >>>>> "Richard Heathfield" wrote:
> >>>>>
> >>>>>> On 23/07/16 23:13, Wally W. wrote:
> >>>>>>> To all who write uninstallation programs for software you
> >>>>>>> distribute:
> >>>>>>
> >>>>>> Whenever possible, I prefer not to do this. To delete my software,
> >>>>>> you
> >>>>>> just delete it, and you're done. Either
> >>>>>>
> >>>>>> cd where/did/you/put/it
> >>>>>> rm *
> >>>>>>
> >>>>>> or maybe, just maybe, there are sub-directories, so:
> >>>>>>
> >>>>>> cd where/did/you/put/it
> >>>>>> rm -rf *
> >>>>>>
> >>>>>> (careful!)
> >>>>>>
> >>>>>> or, if you're on Windows, one of the many Windows equivalents of
> >>>>>> doing
> >>>>>> the same thing (such as dragging a pretty yellow box onto a
> >>>>>> picture of
> >>>>>> a dustbin - alas, I can't promise sweeties to those who get this
> >>>>>> right).
> >>>>>>
> >>>>>>> If your uninstallation program can't leave the machine in the
> >>>>>>> condition you found it, then tell the user what is different.
> >>>>>>
> >>>>>> Hear, hear! But if your program /needs/ an uninstallation program,
> >>>>>> there had better be an extraordinarily good reason. (And sometimes
> >>>>>> there is. But it's rarer than many people think.)
> >>>>>
> >>>>> I long for the good old days too.
> >>>>>
> >>>>> But doesn't your approach fail in one of the most elementary cases on
> >>>>> Windows?  A new program with a new data file. You want to click on the
> >>>>> data file and invoke the program. How can you do that without changing
> >>>>> the data used by the OS?  To me, that is SOP and not rare at all.
> >>>>
> >>>> But the /user/ is responsible for setting up that association. The user
> >>>> double-clicks on "foo.bar", and Windows says "huh? You'd better
> >>>> choose a
> >>>> program for that", and the user chooses my program, and that's the
> >>>> user's choice, so it's the user's problem.
> >>>
> >>> And the tech support guys think badly of you when they have to remote-
> >>> access 10,000 machines and set up that association that _should_ have
> >>> been set up by the installer.
> >>
> >> I understand your point but I don't agree with it. File associations
> >> are a pain in the neck, because they rely on a false premise - i.e.
> >> that the file extension uniquely determines the type of the file.
> >>
> >> I once had to write a program to inspect the first few bytes of a PDF
> >> to discover whether it was a Portable Document Format file (a
> >> document) or a Program Description File (a format used by a screen
> >> layout descriptor utility for COBOL programmers). The program had to
> >> decide which one it was, and then call either Acrobat or the screen
> >> layout thing - and the users associated .pdf with /my/ program, rather
> >> than Acrobat or the utility.
> >>
> >> File extensions go at least as far back as VM/CMS, but they were never
> >> designed to uniquely determine the type of file (even VM/CMS used file
> >> mode descriptors rather than extensions to determine whether a file
> >> was supposed to be executable). File associations were a
> >> badly-designed overlay onto file extensions, and Microsoft has done
> >> little, if anything, to address the problems that file associations
> >> cause.
> >
> > I probably agree with all that.  But it's a bit like complaining about
> > the way words are spelled in the English language.  For the most part,
> > it works, and people expect other people to honor the conventions.
> 
> If it's in the program spec, fair enough, but there'd better be a way to 
> remove it, also in the program spec.
> 
> If it's not in the program spec, then it's just extra work for no benefit.
> 
> And that's true for pretty much any "it", not just file associations.

Are you one of those guys who can't figure out what features are needed 
until someone else writes a spec and then you do the bare minimum 
necessary to meet the spec?

[toc] | [prev] | [next] | [standalone]

#6789

On 24/07/16 17:24, J. Clarke wrote:
> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says...
>>
>> On 24/07/16 16:55, Osmium wrote:
>>> "Richard Heathfield" wrote:
>>>
>>>> On 24/07/16 16:34, J. Clarke wrote:
>>>>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
>>>>>>
>>>>>> On 24/07/16 16:00, Osmium wrote:
>>>>>>> "Richard Heathfield" wrote:
>>>>>>>
>>>>>>>> On 23/07/16 23:13, Wally W. wrote:
>>>>>>>>> To all who write uninstallation programs for software you
>>>>>>>>> distribute:
>>>>>>>>
>>>>>>>> Whenever possible, I prefer not to do this. To delete my software,
>>>>>>>> you
>>>>>>>> just delete it, and you're done. Either
>>>>>>>>
>>>>>>>> cd where/did/you/put/it
>>>>>>>> rm *
>>>>>>>>
>>>>>>>> or maybe, just maybe, there are sub-directories, so:
>>>>>>>>
>>>>>>>> cd where/did/you/put/it
>>>>>>>> rm -rf *
>>>>>>>>
>>>>>>>> (careful!)
>>>>>>>>
>>>>>>>> or, if you're on Windows, one of the many Windows equivalents of
>>>>>>>> doing
>>>>>>>> the same thing (such as dragging a pretty yellow box onto a
>>>>>>>> picture of
>>>>>>>> a dustbin - alas, I can't promise sweeties to those who get this
>>>>>>>> right).
>>>>>>>>
>>>>>>>>> If your uninstallation program can't leave the machine in the
>>>>>>>>> condition you found it, then tell the user what is different.
>>>>>>>>
>>>>>>>> Hear, hear! But if your program /needs/ an uninstallation program,
>>>>>>>> there had better be an extraordinarily good reason. (And sometimes
>>>>>>>> there is. But it's rarer than many people think.)
>>>>>>>
>>>>>>> I long for the good old days too.
>>>>>>>
>>>>>>> But doesn't your approach fail in one of the most elementary cases on
>>>>>>> Windows?  A new program with a new data file. You want to click on the
>>>>>>> data file and invoke the program. How can you do that without changing
>>>>>>> the data used by the OS?  To me, that is SOP and not rare at all.
>>>>>>
>>>>>> But the /user/ is responsible for setting up that association. The user
>>>>>> double-clicks on "foo.bar", and Windows says "huh? You'd better
>>>>>> choose a
>>>>>> program for that", and the user chooses my program, and that's the
>>>>>> user's choice, so it's the user's problem.
>>>>>
>>>>> And the tech support guys think badly of you when they have to remote-
>>>>> access 10,000 machines and set up that association that _should_ have
>>>>> been set up by the installer.
>>>>
>>>> I understand your point but I don't agree with it. File associations
>>>> are a pain in the neck, because they rely on a false premise - i.e.
>>>> that the file extension uniquely determines the type of the file.
>>>>
>>>> I once had to write a program to inspect the first few bytes of a PDF
>>>> to discover whether it was a Portable Document Format file (a
>>>> document) or a Program Description File (a format used by a screen
>>>> layout descriptor utility for COBOL programmers). The program had to
>>>> decide which one it was, and then call either Acrobat or the screen
>>>> layout thing - and the users associated .pdf with /my/ program, rather
>>>> than Acrobat or the utility.
>>>>
>>>> File extensions go at least as far back as VM/CMS, but they were never
>>>> designed to uniquely determine the type of file (even VM/CMS used file
>>>> mode descriptors rather than extensions to determine whether a file
>>>> was supposed to be executable). File associations were a
>>>> badly-designed overlay onto file extensions, and Microsoft has done
>>>> little, if anything, to address the problems that file associations
>>>> cause.
>>>
>>> I probably agree with all that.  But it's a bit like complaining about
>>> the way words are spelled in the English language.  For the most part,
>>> it works, and people expect other people to honor the conventions.
>>
>> If it's in the program spec, fair enough, but there'd better be a way to
>> remove it, also in the program spec.
>>
>> If it's not in the program spec, then it's just extra work for no benefit.
>>
>> And that's true for pretty much any "it", not just file associations.
>
> Are you one of those guys who can't figure out what features are needed
> until someone else writes a spec and then you do the bare minimum
> necessary to meet the spec?

Yup. I guess you're one of those guys who keeps adding features until 
the machine crashes under the weight of them, and then removes the last one.

It's /so/ easy to denigrate other people's design choices, isn't it?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6790

In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says...
> 
> On 24/07/16 17:24, J. Clarke wrote:
> > In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says...
> >>
> >> On 24/07/16 16:55, Osmium wrote:
> >>> "Richard Heathfield" wrote:
> >>>
> >>>> On 24/07/16 16:34, J. Clarke wrote:
> >>>>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
> >>>>>>
> >>>>>> On 24/07/16 16:00, Osmium wrote:
> >>>>>>> "Richard Heathfield" wrote:
> >>>>>>>
> >>>>>>>> On 23/07/16 23:13, Wally W. wrote:
> >>>>>>>>> To all who write uninstallation programs for software you
> >>>>>>>>> distribute:
> >>>>>>>>
> >>>>>>>> Whenever possible, I prefer not to do this. To delete my software,
> >>>>>>>> you
> >>>>>>>> just delete it, and you're done. Either
> >>>>>>>>
> >>>>>>>> cd where/did/you/put/it
> >>>>>>>> rm *
> >>>>>>>>
> >>>>>>>> or maybe, just maybe, there are sub-directories, so:
> >>>>>>>>
> >>>>>>>> cd where/did/you/put/it
> >>>>>>>> rm -rf *
> >>>>>>>>
> >>>>>>>> (careful!)
> >>>>>>>>
> >>>>>>>> or, if you're on Windows, one of the many Windows equivalents of
> >>>>>>>> doing
> >>>>>>>> the same thing (such as dragging a pretty yellow box onto a
> >>>>>>>> picture of
> >>>>>>>> a dustbin - alas, I can't promise sweeties to those who get this
> >>>>>>>> right).
> >>>>>>>>
> >>>>>>>>> If your uninstallation program can't leave the machine in the
> >>>>>>>>> condition you found it, then tell the user what is different.
> >>>>>>>>
> >>>>>>>> Hear, hear! But if your program /needs/ an uninstallation program,
> >>>>>>>> there had better be an extraordinarily good reason. (And sometimes
> >>>>>>>> there is. But it's rarer than many people think.)
> >>>>>>>
> >>>>>>> I long for the good old days too.
> >>>>>>>
> >>>>>>> But doesn't your approach fail in one of the most elementary cases on
> >>>>>>> Windows?  A new program with a new data file. You want to click on the
> >>>>>>> data file and invoke the program. How can you do that without changing
> >>>>>>> the data used by the OS?  To me, that is SOP and not rare at all.
> >>>>>>
> >>>>>> But the /user/ is responsible for setting up that association. The user
> >>>>>> double-clicks on "foo.bar", and Windows says "huh? You'd better
> >>>>>> choose a
> >>>>>> program for that", and the user chooses my program, and that's the
> >>>>>> user's choice, so it's the user's problem.
> >>>>>
> >>>>> And the tech support guys think badly of you when they have to remote-
> >>>>> access 10,000 machines and set up that association that _should_ have
> >>>>> been set up by the installer.
> >>>>
> >>>> I understand your point but I don't agree with it. File associations
> >>>> are a pain in the neck, because they rely on a false premise - i.e.
> >>>> that the file extension uniquely determines the type of the file.
> >>>>
> >>>> I once had to write a program to inspect the first few bytes of a PDF
> >>>> to discover whether it was a Portable Document Format file (a
> >>>> document) or a Program Description File (a format used by a screen
> >>>> layout descriptor utility for COBOL programmers). The program had to
> >>>> decide which one it was, and then call either Acrobat or the screen
> >>>> layout thing - and the users associated .pdf with /my/ program, rather
> >>>> than Acrobat or the utility.
> >>>>
> >>>> File extensions go at least as far back as VM/CMS, but they were never
> >>>> designed to uniquely determine the type of file (even VM/CMS used file
> >>>> mode descriptors rather than extensions to determine whether a file
> >>>> was supposed to be executable). File associations were a
> >>>> badly-designed overlay onto file extensions, and Microsoft has done
> >>>> little, if anything, to address the problems that file associations
> >>>> cause.
> >>>
> >>> I probably agree with all that.  But it's a bit like complaining about
> >>> the way words are spelled in the English language.  For the most part,
> >>> it works, and people expect other people to honor the conventions.
> >>
> >> If it's in the program spec, fair enough, but there'd better be a way to
> >> remove it, also in the program spec.
> >>
> >> If it's not in the program spec, then it's just extra work for no benefit.
> >>
> >> And that's true for pretty much any "it", not just file associations.
> >
> > Are you one of those guys who can't figure out what features are needed
> > until someone else writes a spec and then you do the bare minimum
> > necessary to meet the spec?
> 
> Yup. I guess you're one of those guys who keeps adding features until 
> the machine crashes under the weight of them, and then removes the last one.
> 
> It's /so/ easy to denigrate other people's design choices, isn't it?

In other words you're a programmer who has never held nor aspired to the 
systems analyst role.

[toc] | [prev] | [next] | [standalone]

#6795

On 24/07/16 18:16, J. Clarke wrote:
> In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says...
>>
>> On 24/07/16 17:24, J. Clarke wrote:
>>> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says...
>>>>
>>>> On 24/07/16 16:55, Osmium wrote:
>>>>> "Richard Heathfield" wrote:
>>>>>
>>>>>> On 24/07/16 16:34, J. Clarke wrote:
>>>>>>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
>>>>>>>>
>>>>>>>> On 24/07/16 16:00, Osmium wrote:
>>>>>>>>> "Richard Heathfield" wrote:
>>>>>>>>>
>>>>>>>>>> On 23/07/16 23:13, Wally W. wrote:
>>>>>>>>>>> To all who write uninstallation programs for software you
>>>>>>>>>>> distribute:
>>>>>>>>>>
>>>>>>>>>> Whenever possible, I prefer not to do this. To delete my software,
>>>>>>>>>> you
>>>>>>>>>> just delete it, and you're done. Either
>>>>>>>>>>
>>>>>>>>>> cd where/did/you/put/it
>>>>>>>>>> rm *
>>>>>>>>>>
>>>>>>>>>> or maybe, just maybe, there are sub-directories, so:
>>>>>>>>>>
>>>>>>>>>> cd where/did/you/put/it
>>>>>>>>>> rm -rf *
>>>>>>>>>>
>>>>>>>>>> (careful!)
>>>>>>>>>>
>>>>>>>>>> or, if you're on Windows, one of the many Windows equivalents of
>>>>>>>>>> doing
>>>>>>>>>> the same thing (such as dragging a pretty yellow box onto a
>>>>>>>>>> picture of
>>>>>>>>>> a dustbin - alas, I can't promise sweeties to those who get this
>>>>>>>>>> right).
>>>>>>>>>>
>>>>>>>>>>> If your uninstallation program can't leave the machine in the
>>>>>>>>>>> condition you found it, then tell the user what is different.
>>>>>>>>>>
>>>>>>>>>> Hear, hear! But if your program /needs/ an uninstallation program,
>>>>>>>>>> there had better be an extraordinarily good reason. (And sometimes
>>>>>>>>>> there is. But it's rarer than many people think.)
>>>>>>>>>
>>>>>>>>> I long for the good old days too.
>>>>>>>>>
>>>>>>>>> But doesn't your approach fail in one of the most elementary cases on
>>>>>>>>> Windows?  A new program with a new data file. You want to click on the
>>>>>>>>> data file and invoke the program. How can you do that without changing
>>>>>>>>> the data used by the OS?  To me, that is SOP and not rare at all.
>>>>>>>>
>>>>>>>> But the /user/ is responsible for setting up that association. The user
>>>>>>>> double-clicks on "foo.bar", and Windows says "huh? You'd better
>>>>>>>> choose a
>>>>>>>> program for that", and the user chooses my program, and that's the
>>>>>>>> user's choice, so it's the user's problem.
>>>>>>>
>>>>>>> And the tech support guys think badly of you when they have to remote-
>>>>>>> access 10,000 machines and set up that association that _should_ have
>>>>>>> been set up by the installer.
>>>>>>
>>>>>> I understand your point but I don't agree with it. File associations
>>>>>> are a pain in the neck, because they rely on a false premise - i.e.
>>>>>> that the file extension uniquely determines the type of the file.
>>>>>>
>>>>>> I once had to write a program to inspect the first few bytes of a PDF
>>>>>> to discover whether it was a Portable Document Format file (a
>>>>>> document) or a Program Description File (a format used by a screen
>>>>>> layout descriptor utility for COBOL programmers). The program had to
>>>>>> decide which one it was, and then call either Acrobat or the screen
>>>>>> layout thing - and the users associated .pdf with /my/ program, rather
>>>>>> than Acrobat or the utility.
>>>>>>
>>>>>> File extensions go at least as far back as VM/CMS, but they were never
>>>>>> designed to uniquely determine the type of file (even VM/CMS used file
>>>>>> mode descriptors rather than extensions to determine whether a file
>>>>>> was supposed to be executable). File associations were a
>>>>>> badly-designed overlay onto file extensions, and Microsoft has done
>>>>>> little, if anything, to address the problems that file associations
>>>>>> cause.
>>>>>
>>>>> I probably agree with all that.  But it's a bit like complaining about
>>>>> the way words are spelled in the English language.  For the most part,
>>>>> it works, and people expect other people to honor the conventions.
>>>>
>>>> If it's in the program spec, fair enough, but there'd better be a way to
>>>> remove it, also in the program spec.
>>>>
>>>> If it's not in the program spec, then it's just extra work for no benefit.
>>>>
>>>> And that's true for pretty much any "it", not just file associations.
>>>
>>> Are you one of those guys who can't figure out what features are needed
>>> until someone else writes a spec and then you do the bare minimum
>>> necessary to meet the spec?
>>
>> Yup. I guess you're one of those guys who keeps adding features until
>> the machine crashes under the weight of them, and then removes the last one.
>>
>> It's /so/ easy to denigrate other people's design choices, isn't it?
>
> In other words you're a programmer who has never held nor aspired to the
> systems analyst role.

And it's also very easy to jump to incorrect conclusions.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6798

In article <nn2vbj$o1h$1@dont-email.me>, rjh@cpax.org.uk says...
> 
> On 24/07/16 18:16, J. Clarke wrote:
> > In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says...
> >>
> >> On 24/07/16 17:24, J. Clarke wrote:
> >>> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says...
> >>>>
> >>>> On 24/07/16 16:55, Osmium wrote:
> >>>>> "Richard Heathfield" wrote:
> >>>>>
> >>>>>> On 24/07/16 16:34, J. Clarke wrote:
> >>>>>>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
> >>>>>>>>
> >>>>>>>> On 24/07/16 16:00, Osmium wrote:
> >>>>>>>>> "Richard Heathfield" wrote:
> >>>>>>>>>
> >>>>>>>>>> On 23/07/16 23:13, Wally W. wrote:
> >>>>>>>>>>> To all who write uninstallation programs for software you
> >>>>>>>>>>> distribute:
> >>>>>>>>>>
> >>>>>>>>>> Whenever possible, I prefer not to do this. To delete my software,
> >>>>>>>>>> you
> >>>>>>>>>> just delete it, and you're done. Either
> >>>>>>>>>>
> >>>>>>>>>> cd where/did/you/put/it
> >>>>>>>>>> rm *
> >>>>>>>>>>
> >>>>>>>>>> or maybe, just maybe, there are sub-directories, so:
> >>>>>>>>>>
> >>>>>>>>>> cd where/did/you/put/it
> >>>>>>>>>> rm -rf *
> >>>>>>>>>>
> >>>>>>>>>> (careful!)
> >>>>>>>>>>
> >>>>>>>>>> or, if you're on Windows, one of the many Windows equivalents of
> >>>>>>>>>> doing
> >>>>>>>>>> the same thing (such as dragging a pretty yellow box onto a
> >>>>>>>>>> picture of
> >>>>>>>>>> a dustbin - alas, I can't promise sweeties to those who get this
> >>>>>>>>>> right).
> >>>>>>>>>>
> >>>>>>>>>>> If your uninstallation program can't leave the machine in the
> >>>>>>>>>>> condition you found it, then tell the user what is different.
> >>>>>>>>>>
> >>>>>>>>>> Hear, hear! But if your program /needs/ an uninstallation program,
> >>>>>>>>>> there had better be an extraordinarily good reason. (And sometimes
> >>>>>>>>>> there is. But it's rarer than many people think.)
> >>>>>>>>>
> >>>>>>>>> I long for the good old days too.
> >>>>>>>>>
> >>>>>>>>> But doesn't your approach fail in one of the most elementary cases on
> >>>>>>>>> Windows?  A new program with a new data file. You want to click on the
> >>>>>>>>> data file and invoke the program. How can you do that without changing
> >>>>>>>>> the data used by the OS?  To me, that is SOP and not rare at all.
> >>>>>>>>
> >>>>>>>> But the /user/ is responsible for setting up that association. The user
> >>>>>>>> double-clicks on "foo.bar", and Windows says "huh? You'd better
> >>>>>>>> choose a
> >>>>>>>> program for that", and the user chooses my program, and that's the
> >>>>>>>> user's choice, so it's the user's problem.
> >>>>>>>
> >>>>>>> And the tech support guys think badly of you when they have to remote-
> >>>>>>> access 10,000 machines and set up that association that _should_ have
> >>>>>>> been set up by the installer.
> >>>>>>
> >>>>>> I understand your point but I don't agree with it. File associations
> >>>>>> are a pain in the neck, because they rely on a false premise - i.e.
> >>>>>> that the file extension uniquely determines the type of the file.
> >>>>>>
> >>>>>> I once had to write a program to inspect the first few bytes of a PDF
> >>>>>> to discover whether it was a Portable Document Format file (a
> >>>>>> document) or a Program Description File (a format used by a screen
> >>>>>> layout descriptor utility for COBOL programmers). The program had to
> >>>>>> decide which one it was, and then call either Acrobat or the screen
> >>>>>> layout thing - and the users associated .pdf with /my/ program, rather
> >>>>>> than Acrobat or the utility.
> >>>>>>
> >>>>>> File extensions go at least as far back as VM/CMS, but they were never
> >>>>>> designed to uniquely determine the type of file (even VM/CMS used file
> >>>>>> mode descriptors rather than extensions to determine whether a file
> >>>>>> was supposed to be executable). File associations were a
> >>>>>> badly-designed overlay onto file extensions, and Microsoft has done
> >>>>>> little, if anything, to address the problems that file associations
> >>>>>> cause.
> >>>>>
> >>>>> I probably agree with all that.  But it's a bit like complaining about
> >>>>> the way words are spelled in the English language.  For the most part,
> >>>>> it works, and people expect other people to honor the conventions.
> >>>>
> >>>> If it's in the program spec, fair enough, but there'd better be a way to
> >>>> remove it, also in the program spec.
> >>>>
> >>>> If it's not in the program spec, then it's just extra work for no benefit.
> >>>>
> >>>> And that's true for pretty much any "it", not just file associations.
> >>>
> >>> Are you one of those guys who can't figure out what features are needed
> >>> until someone else writes a spec and then you do the bare minimum
> >>> necessary to meet the spec?
> >>
> >> Yup. I guess you're one of those guys who keeps adding features until
> >> the machine crashes under the weight of them, and then removes the last one.
> >>
> >> It's /so/ easy to denigrate other people's design choices, isn't it?
> >
> > In other words you're a programmer who has never held nor aspired to the
> > systems analyst role.
> 
> And it's also very easy to jump to incorrect conclusions.

You expect someone else to do the design and when it comes acropper you 
point the finger at them instead of yourself, so it is difficult to draw 
any other conclusion.

[toc] | [prev] | [next] | [standalone]

#6799

"J. Clarke" <j.clarke.873638@gmail.com> wrote in message 
news:MPG.31fedcfe5aa7cb6298a3b8@news.eternal-september.org...
> In article <nn2vbj$o1h$1@dont-email.me>, rjh@cpax.org.uk says...
>>
>> On 24/07/16 18:16, J. Clarke wrote:
>> > In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says...
>> >>
>> >> On 24/07/16 17:24, J. Clarke wrote:
>> >>> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says...
>> >>>>
>> >>>> On 24/07/16 16:55, Osmium wrote:
>> >>>>> "Richard Heathfield" wrote:
>> >>>>>
>> >>>>>> On 24/07/16 16:34, J. Clarke wrote:
>> >>>>>>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
>> >>>>>>>>
>> >>>>>>>> On 24/07/16 16:00, Osmium wrote:
>> >>>>>>>>> "Richard Heathfield" wrote:
>> >>>>>>>>>
>> >>>>>>>>>> On 23/07/16 23:13, Wally W. wrote:
>> >>>>>>>>>>> To all who write uninstallation programs for software you
>> >>>>>>>>>>> distribute:
>> >>>>>>>>>>
>> >>>>>>>>>> Whenever possible, I prefer not to do this. To delete my 
>> >>>>>>>>>> software,
>> >>>>>>>>>> you
>> >>>>>>>>>> just delete it, and you're done. Either
>> >>>>>>>>>>
>> >>>>>>>>>> cd where/did/you/put/it
>> >>>>>>>>>> rm *
>> >>>>>>>>>>
>> >>>>>>>>>> or maybe, just maybe, there are sub-directories, so:
>> >>>>>>>>>>
>> >>>>>>>>>> cd where/did/you/put/it
>> >>>>>>>>>> rm -rf *
>> >>>>>>>>>>
>> >>>>>>>>>> (careful!)
>> >>>>>>>>>>
>> >>>>>>>>>> or, if you're on Windows, one of the many Windows equivalents 
>> >>>>>>>>>> of
>> >>>>>>>>>> doing
>> >>>>>>>>>> the same thing (such as dragging a pretty yellow box onto a
>> >>>>>>>>>> picture of
>> >>>>>>>>>> a dustbin - alas, I can't promise sweeties to those who get 
>> >>>>>>>>>> this
>> >>>>>>>>>> right).
>> >>>>>>>>>>
>> >>>>>>>>>>> If your uninstallation program can't leave the machine in the
>> >>>>>>>>>>> condition you found it, then tell the user what is different.
>> >>>>>>>>>>
>> >>>>>>>>>> Hear, hear! But if your program /needs/ an uninstallation 
>> >>>>>>>>>> program,
>> >>>>>>>>>> there had better be an extraordinarily good reason. (And 
>> >>>>>>>>>> sometimes
>> >>>>>>>>>> there is. But it's rarer than many people think.)
>> >>>>>>>>>
>> >>>>>>>>> I long for the good old days too.
>> >>>>>>>>>
>> >>>>>>>>> But doesn't your approach fail in one of the most elementary 
>> >>>>>>>>> cases on
>> >>>>>>>>> Windows?  A new program with a new data file. You want to click 
>> >>>>>>>>> on the
>> >>>>>>>>> data file and invoke the program. How can you do that without 
>> >>>>>>>>> changing
>> >>>>>>>>> the data used by the OS?  To me, that is SOP and not rare at 
>> >>>>>>>>> all.
>> >>>>>>>>
>> >>>>>>>> But the /user/ is responsible for setting up that association. 
>> >>>>>>>> The user
>> >>>>>>>> double-clicks on "foo.bar", and Windows says "huh? You'd better
>> >>>>>>>> choose a
>> >>>>>>>> program for that", and the user chooses my program, and that's 
>> >>>>>>>> the
>> >>>>>>>> user's choice, so it's the user's problem.
>> >>>>>>>
>> >>>>>>> And the tech support guys think badly of you when they have to 
>> >>>>>>> remote-
>> >>>>>>> access 10,000 machines and set up that association that _should_ 
>> >>>>>>> have
>> >>>>>>> been set up by the installer.
>> >>>>>>
>> >>>>>> I understand your point but I don't agree with it. File 
>> >>>>>> associations
>> >>>>>> are a pain in the neck, because they rely on a false premise - 
>> >>>>>> i.e.
>> >>>>>> that the file extension uniquely determines the type of the file.
>> >>>>>>
>> >>>>>> I once had to write a program to inspect the first few bytes of a 
>> >>>>>> PDF
>> >>>>>> to discover whether it was a Portable Document Format file (a
>> >>>>>> document) or a Program Description File (a format used by a screen
>> >>>>>> layout descriptor utility for COBOL programmers). The program had 
>> >>>>>> to
>> >>>>>> decide which one it was, and then call either Acrobat or the 
>> >>>>>> screen
>> >>>>>> layout thing - and the users associated .pdf with /my/ program, 
>> >>>>>> rather
>> >>>>>> than Acrobat or the utility.
>> >>>>>>
>> >>>>>> File extensions go at least as far back as VM/CMS, but they were 
>> >>>>>> never
>> >>>>>> designed to uniquely determine the type of file (even VM/CMS used 
>> >>>>>> file
>> >>>>>> mode descriptors rather than extensions to determine whether a 
>> >>>>>> file
>> >>>>>> was supposed to be executable). File associations were a
>> >>>>>> badly-designed overlay onto file extensions, and Microsoft has 
>> >>>>>> done
>> >>>>>> little, if anything, to address the problems that file 
>> >>>>>> associations
>> >>>>>> cause.
>> >>>>>
>> >>>>> I probably agree with all that.  But it's a bit like complaining 
>> >>>>> about
>> >>>>> the way words are spelled in the English language.  For the most 
>> >>>>> part,
>> >>>>> it works, and people expect other people to honor the conventions.
>> >>>>
>> >>>> If it's in the program spec, fair enough, but there'd better be a 
>> >>>> way to
>> >>>> remove it, also in the program spec.
>> >>>>
>> >>>> If it's not in the program spec, then it's just extra work for no 
>> >>>> benefit.
>> >>>>
>> >>>> And that's true for pretty much any "it", not just file 
>> >>>> associations.
>> >>>
>> >>> Are you one of those guys who can't figure out what features are 
>> >>> needed
>> >>> until someone else writes a spec and then you do the bare minimum
>> >>> necessary to meet the spec?
>> >>
>> >> Yup. I guess you're one of those guys who keeps adding features until
>> >> the machine crashes under the weight of them, and then removes the 
>> >> last one.
>> >>
>> >> It's /so/ easy to denigrate other people's design choices, isn't it?
>> >
>> > In other words you're a programmer who has never held nor aspired to 
>> > the
>> > systems analyst role.
>>
>> And it's also very easy to jump to incorrect conclusions.
>
> You expect someone else to do the design and when it comes acropper you
> point the finger at them instead of yourself, so it is difficult to draw
> any other conclusion.

That's not what he said at all - he said he wanted someone else to write the 
specification. 

[toc] | [prev] | [next] | [standalone]

#6800

On 24/07/16 20:45, Osmium wrote:
> "J. Clarke" <j.clarke.873638@gmail.com> wrote in message
> news:MPG.31fedcfe5aa7cb6298a3b8@news.eternal-september.org...
>> In article <nn2vbj$o1h$1@dont-email.me>, rjh@cpax.org.uk says...
>>>
>>> On 24/07/16 18:16, J. Clarke wrote:
>>> > In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says...
>>> >>
>>> >> On 24/07/16 17:24, J. Clarke wrote:
>>> >>> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says...
>>> >>>>
>>> >>>> On 24/07/16 16:55, Osmium wrote:
>>> >>>>> "Richard Heathfield" wrote:
>>> >>>>>
>>> >>>>>> On 24/07/16 16:34, J. Clarke wrote:
>>> >>>>>>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
>>> >>>>>>>>
>>> >>>>>>>> On 24/07/16 16:00, Osmium wrote:
>>> >>>>>>>>> "Richard Heathfield" wrote:
>>> >>>>>>>>>
>>> >>>>>>>>>> On 23/07/16 23:13, Wally W. wrote:
>>> >>>>>>>>>>> To all who write uninstallation programs for software you
>>> >>>>>>>>>>> distribute:
>>> >>>>>>>>>>
>>> >>>>>>>>>> Whenever possible, I prefer not to do this. To delete my
>>> >>>>>>>>>> software,
>>> >>>>>>>>>> you
>>> >>>>>>>>>> just delete it, and you're done. Either
>>> >>>>>>>>>>
>>> >>>>>>>>>> cd where/did/you/put/it
>>> >>>>>>>>>> rm *
>>> >>>>>>>>>>
>>> >>>>>>>>>> or maybe, just maybe, there are sub-directories, so:
>>> >>>>>>>>>>
>>> >>>>>>>>>> cd where/did/you/put/it
>>> >>>>>>>>>> rm -rf *
>>> >>>>>>>>>>
>>> >>>>>>>>>> (careful!)
>>> >>>>>>>>>>
>>> >>>>>>>>>> or, if you're on Windows, one of the many Windows
>>> equivalents >>>>>>>>>> of
>>> >>>>>>>>>> doing
>>> >>>>>>>>>> the same thing (such as dragging a pretty yellow box onto a
>>> >>>>>>>>>> picture of
>>> >>>>>>>>>> a dustbin - alas, I can't promise sweeties to those who
>>> get >>>>>>>>>> this
>>> >>>>>>>>>> right).
>>> >>>>>>>>>>
>>> >>>>>>>>>>> If your uninstallation program can't leave the machine in
>>> the
>>> >>>>>>>>>>> condition you found it, then tell the user what is
>>> different.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Hear, hear! But if your program /needs/ an uninstallation
>>> >>>>>>>>>> program,
>>> >>>>>>>>>> there had better be an extraordinarily good reason. (And
>>> >>>>>>>>>> sometimes
>>> >>>>>>>>>> there is. But it's rarer than many people think.)
>>> >>>>>>>>>
>>> >>>>>>>>> I long for the good old days too.
>>> >>>>>>>>>
>>> >>>>>>>>> But doesn't your approach fail in one of the most
>>> elementary >>>>>>>>> cases on
>>> >>>>>>>>> Windows?  A new program with a new data file. You want to
>>> click >>>>>>>>> on the
>>> >>>>>>>>> data file and invoke the program. How can you do that
>>> without >>>>>>>>> changing
>>> >>>>>>>>> the data used by the OS?  To me, that is SOP and not rare
>>> at >>>>>>>>> all.
>>> >>>>>>>>
>>> >>>>>>>> But the /user/ is responsible for setting up that
>>> association. >>>>>>>> The user
>>> >>>>>>>> double-clicks on "foo.bar", and Windows says "huh? You'd better
>>> >>>>>>>> choose a
>>> >>>>>>>> program for that", and the user chooses my program, and
>>> that's >>>>>>>> the
>>> >>>>>>>> user's choice, so it's the user's problem.
>>> >>>>>>>
>>> >>>>>>> And the tech support guys think badly of you when they have
>>> to >>>>>>> remote-
>>> >>>>>>> access 10,000 machines and set up that association that
>>> _should_ >>>>>>> have
>>> >>>>>>> been set up by the installer.
>>> >>>>>>
>>> >>>>>> I understand your point but I don't agree with it. File >>>>>>
>>> associations
>>> >>>>>> are a pain in the neck, because they rely on a false premise -
>>> >>>>>> i.e.
>>> >>>>>> that the file extension uniquely determines the type of the file.
>>> >>>>>>
>>> >>>>>> I once had to write a program to inspect the first few bytes
>>> of a >>>>>> PDF
>>> >>>>>> to discover whether it was a Portable Document Format file (a
>>> >>>>>> document) or a Program Description File (a format used by a
>>> screen
>>> >>>>>> layout descriptor utility for COBOL programmers). The program
>>> had >>>>>> to
>>> >>>>>> decide which one it was, and then call either Acrobat or the
>>> >>>>>> screen
>>> >>>>>> layout thing - and the users associated .pdf with /my/
>>> program, >>>>>> rather
>>> >>>>>> than Acrobat or the utility.
>>> >>>>>>
>>> >>>>>> File extensions go at least as far back as VM/CMS, but they
>>> were >>>>>> never
>>> >>>>>> designed to uniquely determine the type of file (even VM/CMS
>>> used >>>>>> file
>>> >>>>>> mode descriptors rather than extensions to determine whether a
>>> >>>>>> file
>>> >>>>>> was supposed to be executable). File associations were a
>>> >>>>>> badly-designed overlay onto file extensions, and Microsoft has
>>> >>>>>> done
>>> >>>>>> little, if anything, to address the problems that file >>>>>>
>>> associations
>>> >>>>>> cause.
>>> >>>>>
>>> >>>>> I probably agree with all that.  But it's a bit like
>>> complaining >>>>> about
>>> >>>>> the way words are spelled in the English language.  For the
>>> most >>>>> part,
>>> >>>>> it works, and people expect other people to honor the conventions.
>>> >>>>
>>> >>>> If it's in the program spec, fair enough, but there'd better be
>>> a >>>> way to
>>> >>>> remove it, also in the program spec.
>>> >>>>
>>> >>>> If it's not in the program spec, then it's just extra work for
>>> no >>>> benefit.
>>> >>>>
>>> >>>> And that's true for pretty much any "it", not just file >>>>
>>> associations.
>>> >>>
>>> >>> Are you one of those guys who can't figure out what features are
>>> >>> needed
>>> >>> until someone else writes a spec and then you do the bare minimum
>>> >>> necessary to meet the spec?
>>> >>
>>> >> Yup. I guess you're one of those guys who keeps adding features until
>>> >> the machine crashes under the weight of them, and then removes the
>>> >> last one.
>>> >>
>>> >> It's /so/ easy to denigrate other people's design choices, isn't it?
>>> >
>>> > In other words you're a programmer who has never held nor aspired
>>> to > the
>>> > systems analyst role.
>>>
>>> And it's also very easy to jump to incorrect conclusions.
>>
>> You expect someone else to do the design and when it comes acropper you
>> point the finger at them instead of yourself, so it is difficult to draw
>> any other conclusion.
>
> That's not what he said at all - he said he wanted someone else to write
> the specification.

I didn't even say /that/.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6802

In article <nn38ib$omn$2@dont-email.me>, rjh@cpax.org.uk says...
> 
> On 24/07/16 20:45, Osmium wrote:
> > "J. Clarke" <j.clarke.873638@gmail.com> wrote in message
> > news:MPG.31fedcfe5aa7cb6298a3b8@news.eternal-september.org...
> >> In article <nn2vbj$o1h$1@dont-email.me>, rjh@cpax.org.uk says...
> >>>
> >>> On 24/07/16 18:16, J. Clarke wrote:
> >>> > In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says...
> >>> >>
> >>> >> On 24/07/16 17:24, J. Clarke wrote:
> >>> >>> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says...
> >>> >>>>
> >>> >>>> On 24/07/16 16:55, Osmium wrote:
> >>> >>>>> "Richard Heathfield" wrote:
> >>> >>>>>
> >>> >>>>>> On 24/07/16 16:34, J. Clarke wrote:
> >>> >>>>>>> In article <nn2m7t$o38$2@dont-email.me>, rjh@cpax.org.uk says...
> >>> >>>>>>>>
> >>> >>>>>>>> On 24/07/16 16:00, Osmium wrote:
> >>> >>>>>>>>> "Richard Heathfield" wrote:
> >>> >>>>>>>>>
> >>> >>>>>>>>>> On 23/07/16 23:13, Wally W. wrote:
> >>> >>>>>>>>>>> To all who write uninstallation programs for software you
> >>> >>>>>>>>>>> distribute:
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> Whenever possible, I prefer not to do this. To delete my
> >>> >>>>>>>>>> software,
> >>> >>>>>>>>>> you
> >>> >>>>>>>>>> just delete it, and you're done. Either
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> cd where/did/you/put/it
> >>> >>>>>>>>>> rm *
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> or maybe, just maybe, there are sub-directories, so:
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> cd where/did/you/put/it
> >>> >>>>>>>>>> rm -rf *
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> (careful!)
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> or, if you're on Windows, one of the many Windows
> >>> equivalents >>>>>>>>>> of
> >>> >>>>>>>>>> doing
> >>> >>>>>>>>>> the same thing (such as dragging a pretty yellow box onto a
> >>> >>>>>>>>>> picture of
> >>> >>>>>>>>>> a dustbin - alas, I can't promise sweeties to those who
> >>> get >>>>>>>>>> this
> >>> >>>>>>>>>> right).
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>> If your uninstallation program can't leave the machine in
> >>> the
> >>> >>>>>>>>>>> condition you found it, then tell the user what is
> >>> different.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> Hear, hear! But if your program /needs/ an uninstallation
> >>> >>>>>>>>>> program,
> >>> >>>>>>>>>> there had better be an extraordinarily good reason. (And
> >>> >>>>>>>>>> sometimes
> >>> >>>>>>>>>> there is. But it's rarer than many people think.)
> >>> >>>>>>>>>
> >>> >>>>>>>>> I long for the good old days too.
> >>> >>>>>>>>>
> >>> >>>>>>>>> But doesn't your approach fail in one of the most
> >>> elementary >>>>>>>>> cases on
> >>> >>>>>>>>> Windows?  A new program with a new data file. You want to
> >>> click >>>>>>>>> on the
> >>> >>>>>>>>> data file and invoke the program. How can you do that
> >>> without >>>>>>>>> changing
> >>> >>>>>>>>> the data used by the OS?  To me, that is SOP and not rare
> >>> at >>>>>>>>> all.
> >>> >>>>>>>>
> >>> >>>>>>>> But the /user/ is responsible for setting up that
> >>> association. >>>>>>>> The user
> >>> >>>>>>>> double-clicks on "foo.bar", and Windows says "huh? You'd better
> >>> >>>>>>>> choose a
> >>> >>>>>>>> program for that", and the user chooses my program, and
> >>> that's >>>>>>>> the
> >>> >>>>>>>> user's choice, so it's the user's problem.
> >>> >>>>>>>
> >>> >>>>>>> And the tech support guys think badly of you when they have
> >>> to >>>>>>> remote-
> >>> >>>>>>> access 10,000 machines and set up that association that
> >>> _should_ >>>>>>> have
> >>> >>>>>>> been set up by the installer.
> >>> >>>>>>
> >>> >>>>>> I understand your point but I don't agree with it. File >>>>>>
> >>> associations
> >>> >>>>>> are a pain in the neck, because they rely on a false premise -
> >>> >>>>>> i.e.
> >>> >>>>>> that the file extension uniquely determines the type of the file.
> >>> >>>>>>
> >>> >>>>>> I once had to write a program to inspect the first few bytes
> >>> of a >>>>>> PDF
> >>> >>>>>> to discover whether it was a Portable Document Format file (a
> >>> >>>>>> document) or a Program Description File (a format used by a
> >>> screen
> >>> >>>>>> layout descriptor utility for COBOL programmers). The program
> >>> had >>>>>> to
> >>> >>>>>> decide which one it was, and then call either Acrobat or the
> >>> >>>>>> screen
> >>> >>>>>> layout thing - and the users associated .pdf with /my/
> >>> program, >>>>>> rather
> >>> >>>>>> than Acrobat or the utility.
> >>> >>>>>>
> >>> >>>>>> File extensions go at least as far back as VM/CMS, but they
> >>> were >>>>>> never
> >>> >>>>>> designed to uniquely determine the type of file (even VM/CMS
> >>> used >>>>>> file
> >>> >>>>>> mode descriptors rather than extensions to determine whether a
> >>> >>>>>> file
> >>> >>>>>> was supposed to be executable). File associations were a
> >>> >>>>>> badly-designed overlay onto file extensions, and Microsoft has
> >>> >>>>>> done
> >>> >>>>>> little, if anything, to address the problems that file >>>>>>
> >>> associations
> >>> >>>>>> cause.
> >>> >>>>>
> >>> >>>>> I probably agree with all that.  But it's a bit like
> >>> complaining >>>>> about
> >>> >>>>> the way words are spelled in the English language.  For the
> >>> most >>>>> part,
> >>> >>>>> it works, and people expect other people to honor the conventions.
> >>> >>>>
> >>> >>>> If it's in the program spec, fair enough, but there'd better be
> >>> a >>>> way to
> >>> >>>> remove it, also in the program spec.
> >>> >>>>
> >>> >>>> If it's not in the program spec, then it's just extra work for
> >>> no >>>> benefit.
> >>> >>>>
> >>> >>>> And that's true for pretty much any "it", not just file >>>>
> >>> associations.
> >>> >>>
> >>> >>> Are you one of those guys who can't figure out what features are
> >>> >>> needed
> >>> >>> until someone else writes a spec and then you do the bare minimum
> >>> >>> necessary to meet the spec?
> >>> >>
> >>> >> Yup. I guess you're one of those guys who keeps adding features until
> >>> >> the machine crashes under the weight of them, and then removes the
> >>> >> last one.
> >>> >>
> >>> >> It's /so/ easy to denigrate other people's design choices, isn't it?
> >>> >
> >>> > In other words you're a programmer who has never held nor aspired
> >>> to > the
> >>> > systems analyst role.
> >>>
> >>> And it's also very easy to jump to incorrect conclusions.
> >>
> >> You expect someone else to do the design and when it comes acropper you
> >> point the finger at them instead of yourself, so it is difficult to draw
> >> any other conclusion.
> >
> > That's not what he said at all - he said he wanted someone else to write
> > the specification.
> 
> I didn't even say /that/.

Your argument seems to be that you code to the specification and that 
the specification is not your responsibility.  If that is not what you 
mean then what _do_ you mean.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.programming

csiph-web