On 6/1/2012 11:53 AM, Rupert Swarbrick wrote:
> Richard Fateman<fateman at eecs.berkeley.edu> writes:
>>> furthermore git uses patches compatible with patch(1), thus one can
>>> just cd to the directory with sources (not necessary git-cloned) and
>>> do
>>>
>>> $ patch -p1< patch-file-to-apply
>> Again, this is a retrograde approach to software development, assuming
>> that the real way to make a "fix" is to change the source file, and
>> re-make the whole world.
> A serious question: Can you explain exactly what you mean by
> "retrograde" here?
In 1960 one had to submit programs by punching holes in paper tapes or
cards.
In 1960 one had to recompile, load, test, and debug "batch" mode.
By 1966, timesharing allowed one to use interactive programs like Basic
or Lisp or Joss
to incrementally test-write-test-write ... without recompilation,
loading, "batch" mode.
By 1985 one had a personal workstation to make interaction even more
convenient.
Now we have personal workstations with multiple CPUs, displays, internet
etc etc.
So why do we use as our model of program development something that goes
back
to 1960?
>
>>>> Here is the kind of thing that would be useful. You come up with
>>>> a good idea that other people might want to try out without
>>>> recompiling maxima etc etc. Create a file that can be read in
>>>> like this:
>>>>
>>>> ;;; file defining new feature xxx
>>>> ;;; written by<author> <date>
>>>> ;;; tested in Maxima<version>
>>>>
>>>> (in-package :maxima)
>>>>
>>>> ;;; redefine two functions in file simp.lisp
>>> The problem with this approach is that unless the format is
>>> standardized and the tools are written, it requires a human
>>> intervention "to apply such a patch" -- tedious and error-prone.
>> There are no tools necessary other than a text editor, to make this file.
> And then how do you propose to integrate it with the other code in the
> system when you decide to keep the change?
That is simple. You check out the file.
You delete the old (defun ...) and insert the new (defun ...) in its place
and
check it back in.
I don't know about the check-in/out, but the other operations take about
6 keystrokes in emacs.
>
>>> By the way, just file name is not enough, one also needs to mention
>>> where to put the functions in each file when the patch is "applied".
>> If someone wishes to make the changes to the source file, yes, one
>> would have to
>> search for
>> (defun xxx .....)
>>
>> or perhaps (defmfun xxx ...)
>>
>> delete the definition and insert the new one.
> Don't forget that the brittleness of patches also serves another
> purpose: if other bits of the file have changed, they might well have
> changed how your defun/defmfun will behave, rendering it incorrect even
> though your code didn't change at all. This is particularly problematic
> if there are lots of dynamic variables floating around... like in
> Maxima.
If you change a program that depends upon global variables, you have to
be careful.
I don't know how that benefits from one development environment or another.
>
>>>> I continue to object generally to patches and files whose authorship
>>>> can be discerned only by examining the separate change logs, so any
>>>> alterations to pre-existing functions should have comments
>>>> identifying authors, too.
>>> Why do manually what a program can do? Git has git-blame(1) if one
>>> wants to know who to blame for each line.
>> Why do I have to install git and become an expert in it?
> "Oh no. In order to write a computer program, I'll have to learn to use
> an editor, which is orthogonal to the important business of coding and
> learning to use a programming language."
>
> How is your standpoint different from this caricature?
I have learned about 3 source code control systems, and even taught
students to
use one. I have learned at least 4 different graphics display systems.
I have used numerous editors, but use emacs when I can, and Microsoft
Word when
I must. When someone offers me a NEW IMPROVED version of Word, I do not
appreciate it at all.
So: I have to use an editor for lots of things. I would use git solely
for Maxima, and
how long would that last before it too was replaced?
>
> <snip>
>> Also the description says that this will not help for lines that were
>> deleted or replaced. Knowing the author of a line also does not
>> necessarily provide a comment as to why the new line is superior to
>> the old.
> Yep. That's what commit logs are for.
If they are informative, which they need not be.
>
>> I also sometimes print out programs to read / revise them, and take
>> them away from a computer. It is nice to have the program text provide
>> relevant comments, in my opinion.
> Ok, well I guess we disagree here. For me, a file containing source code
> is not required to be a detailed "biography" of the history of the
> project.
I feel it should contain all that is necessary to read and understand
the program. For
a program like Maxima which has parts that were written in 1965 and have
been
unchanged for 45 years, I think it is relevant to include info as to
why, after 45 years
someone decided that it should be changed, and who that person is.
RJF
> Maxima at math.utexas.edu http://www.math.utexas.edu/mailman/listinfo/maxima