Re: repeating groups

dawn wrote:
> Marshall Spight wrote:
> <snip>
> > > Metaphors of all kinds are useful for interface design, including
> > > visual, language, and mathematics. If you try to use understandable
> > > variable names, you recognize the importance of modeling with language.
> >
> > Okay, I guess I kinda see what you mean.
> >
> > I'm not sure, though, if mathematics belongs in the above list.
> > I think when we do software, we are doing actual math,
> > not metaphorical math.
>
> We are using mathematics as a metaphor for some aspect of reality. A
> mathematical model is a metaphor. I agree that when we program we are
> doing mathematics. We are modeling. We are designing. We are
> constructing. We are solving business problems. We are communicating.

Agreed.

> It isn't exclusively mathematics, but that certainly is a significant
> aspect of it.

Hmmm. It seems like it's all math to me-- the programming part is all math. Talking to customers and doing the design isn't math; is that what you meant?

> > I recognize that this isn't what most
> > programmers think they're doing.
>
> I always thought of programming as writing proofs.

I wish it was *more* like writing proofs.

What I really appreciate about being able to write in a statically typed language is that I can leverage the type system to be able to prove properties of my code. I wish there were more opportunities to do this, actually, to the point that I'd like to see a proof language embedded in a programming language. I guess the big difficulty in doing so is not the implementation complexity but that proof solving is horrendously CPU expensive.

> > (I would propose that it would be better to model bags with sets than
> > with lists, though-- side point.)
>
> You can implement an arbitrary conceptual bag as a logical list, but
> not as a set because you might need to indicate the same value multiple
> times -- coin flip as example.

Oh, that's easy-- just add a count attribute and viola! A bag.

> > Yeah, I hear that. I'm not sure you sufficiently appreciate the
> > added complexity that comes from making the system be irregular,
> > though.
>
> While I don't have a full appreciation of it from an implementation
> standpoint, I do understand from an elegance standpoint. I was drawn
> to the RM because of its logical elegance. I only appreciated MV based
> on results and then tried to figure out why this somewhat odd mix of
> pieces was so useful. What you get with this approach of functions
> being first-class citizens and nested structures being lists only to
> two levels deep is that every value within a namespace may be reached
> by the function
>
> fileName(recordID,attributeNumber,valueNumber,subvalueNumber) If you
> go beyond that to subsubvalues and down the line, what might you lose
> in conceptual simplicity and is it worth what you gain?

It doesn't seem like it would be so bad. It's just like unix pathnames.

> > Heh. Sometimes I feel I'm being very patient with you, and other times
> > I feel you're being very patient with me.
>
> I just read mAsterdam's response to this and didn't understand it, so
> maybe he or you could clue me in. But I appreciate your comment.

Yeah, I didn't get that either. My best guess was he was talking about barf bags. :-)

> It seemed to work as I see no major points of disagreement on this
> matter now. The biggest might be that I would still rather start with
> MV and add in whatever it is you think you must have (provided it
> doesn't mess things up) while you would like to start with the RM and
> do similarly.

Well, one starts with what one knows. Anyway, my current starting point isn't the classical relational algebra but the Tropashko algebra.

> I would rather start with anarchy and add in what
> additional constraints are helpful instead of starting with locks on
> all the doors trying to free myself somehow. Cheers! --dawn

D'oh! I hate those kinds of analogies. As if being in prison was somehow related to having a useful algebra.

Marshall Received on Tue Feb 21 2006 - 09:26:04 CET