Re: choice of character for relational division

On Apr 1, 8:42 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> Marshall wrote:
> > ...
> > So ... what kind of code was this? If it was assembly, I could
> > see that working, because the format is so regular. If it's
> > anything in the algol family, I don't see how it could work.
> > There is formatting in the comments. There is formatting
> > in where the line breaks happen in long source lines. None
> > of this info is preserved in object form. And if it was, how
> > would editing be enabled such that everyone could edit
> > this information according to their own style, and yet others
> > could see it in *their* style? I don't see any way to make
> > that work without discarding some set of things programmers
> > are used to having.
>
> No vi or such. Only practical way to write code was to use system's
> built-in editor (which was written in the same language app developers
> used, although it was quite easy to generate object with the system or
> for that matter any other tool you liked, as long as you knew the object
> format which was trivial compared to what most people were used to then
> as well as today.

Yeah, I see the advantages, but I don't think it's something that's going to sell well. You've got to get all the vi guys not to use vi, and all the emacs guys not to use emacs. That won't be pretty.

It kinda reminds me of IBM's VisualAge, and the later Eclipse projects. I *really* hate both of them. They both take the position that the programmer should adapt to their way of doing things. Screw that; I want the tools to adapt to me; they are my servants, not the other way around.

(We used to call VisualAge the "source motel", a la the "roach motel." "Source code checks in but it doesn't check out!")

> Tiny number of verbs, all table oriented, Get,
> Forall, Insert, Replace, Delete. Displays were sets of tables, IMS
> databases were tables, along with all the big-name DB products (to help
> encourage migration), although the preferred storage was the system's
> native organizations. Funny structure to code, conditions preceded all
> imperatives using what looked like a graphical truth table but was
> really just a disguised if then else arrangement. Programmer's interface
> was a table 'row'. Not relational by Codd's standards although I know
> for certain that he was prepared to be its architect around 1990 or so,
> money no problem, a little issue of titles put the kibosh on it.

Interesting.

> However, none of that matters to my point - object code was stored in
> system's own tables which were accessible to any programmer, not just
> the system itself. The point is that original source code was not
> saved. Some users complained that they couldn't add comments but mostly
> we ignored them. To this day, I think source code management systems
> are a bizarre unnecessity.

It seems to me that it would be quite possible to put object (and source
as well) into the system's own tables without having to mandate the use of special purpose editors. Making the object the canonical representation means its harder (if not impossible) to use any existing tools on your code.

Also, comments are a requirement. Whether our code is high level and declarative, or low level and procedural, our code can only capture *what* in the first case or *how* in the second case. Only comments are capable of capturing *why.*

Marshall Received on Mon Apr 02 2007 - 19:17:35 CEST