# Re: repeating groups

Date: 21 Feb 2006 00:26:04 -0800

Message-ID: <1140510364.302633.157300_at_g43g2000cwa.googlegroups.com>

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.
*

> > 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