This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
Bradd wrote: >> Pardon my vulgarity, but screw elegance. It means different things to >> everyone, and it's the doom of many a design. The overzealous desire for >> so-called elegance is one of the things that leads to what Bear called >> APIs for stupid programs. >> >> I see this desire for elegance in designers of all kinds, and it almost >> always reflects the author's unreasoning infatuation with some design, >> whether it's actually useful or not. In my opinion, "elegance" should >> never, ever be a design goal; it's a primrose path that leads to Hell. scgmille@xxxxxxxxxxxxxxxxxx wrote: > You sir, are obviously not using the right language then. I'm guessing that you mean, "If you don't like elegance, then why are you using Scheme?" Your premise is false. I *do* like elegance. However, elegance is useless as a design goal, because elegance is in the eye of the beholder. This beholder believes that no design is elegant unless it is highly usable, practical, and efficient. Mere simplicity does not elegance make; for true elegance, a design must be both simple *and* practical. You're doing good on the former but not the latter, IMO. > I agree with this particular operator, but this is simply not true for > many of the operators in Bear's kitchen sink dictionary library. I would agree that Bear's library is not elegant. It is practical but not simple. However, forced to choose between the two, I'd much rather have practical than simple. Then again, a lot depends on point of view. While Bear's interface is not simple, it does help to simplify the code that uses it -- that's one of the things that makes it practical. Which is more important, elegance of the library or elegance of the code that uses it? > Set isn't a subtype of bag because they have subtly different > properties, despite similar interfaces. See: > > http://okmij.org/ftp/Computation/Subtyping/ I'll check it out. >> With no explicit design goals, no complete implementation, and no >> examples of the collections in actual use, how are we supposed to >> trust that these won't be problems? > If you don't trust me, construct a counter-example. That's not how design/code review works. > I'm not going to make a proof by example, since you could very well > argue that it wasn't the 'right' example. If it isn't a good example, you're right -- I would object thus. >> If it seems like I'm being a jerk about this, it's because my day job >> is 100% about quality -- code reviews, design reviews, testing, >> verification, making sure that we have more than just the developer's >> word that a system is good. This "I don't need to prove that my >> design is good" attitude doesn't fly in a code review. And isn't that >> exactly what the SRFI draft process is? > I respect your background, but if it matters so much to you, why not > attempt to write a new bag collection yourself. Again, that isn't how review works. "If you don't like it, do it yourself!" is totally inappropriate. The goal of review is to anticipate problems and to provide advice. The author can ignore the advice if he wants to, although it's dangerous to ignore informed advice. But "Do it yourself, then!" is not an appropriate response. In fact, it's responses like this that undermine my confidence in your product. >>> Name one language with a useful generic collections library that got >>> it this way? >> You have heard of C++, right? > I'm restraining laughter. It isn't perfect, but it *works*, and it was created by factoring interfaces out of real, working collections and algorithms. I know that it works, because I've used it both as library implementor and as library user. I have confidence in it based on experience, something that SRFI-44 lacks. -- Bradd W. Szonye http://www.szonye.com/bradd