On Wed, Aug 3, 2011 at 7:32 AM, Chris Warburton <[email protected]> wrote: > On Tuesday 02 August 2011 00:43:57 BGB wrote: >> On 8/1/2011 3:24 PM, Simon Forman wrote: >> > On 7/27/11, Chris Warburton<[email protected]> wrote: >> <snip> >> (maybe relevant but no really to comment). >> >> >> Another reason I would argue against something like types based on >> >> Physics is that Physics tries to work out the inconceivable ways that >> >> the Universe actually behaves by systematically throwing away all of our >> >> intuitions that turn out to be wrong. With a computer system, we want >> >> the opposite; we want a system that requires as little study as >> >> possible, and for which our intuitions are accurate. >> > >> > I respectfully disagree. >> > >> > Jef Raskin pointed out that humans have no innate intuition regarding >> > computer systems, only familiarity. The word "intuitive" in reference >> > to computer languages and UIs is incorrect. >> > >> > We want a computer system that allows us to specify our guesses >> > (intuitions) about the world concretely and communicate them and test >> > them, but that does so without unduly getting in our way. >> > >> > I think that creating computer systems that support naive or unfounded >> > "intuitions" (whether about how computers work or about the world >> > outside the computer system) actually does a disservice. >> >> yep, "intuitive" is itself often ill-defined. >> >> >> usually, it is used in reference to one of several ideas: >> >> it is conventional, so it is "intuitive" in that most of its aspects are >> common with other similar systems (like, say, a language looks about >> like C++ or Java, so people have a good idea what it will do without >> really knowing the language in particular); >> >> it follows conventions from somewhere else, usually related to the >> domain in which it is being applied (it is "intuitive" in that it is >> similar to what the users are likely to expect in their domain); >> >> it strives for being "intuitive" in the sense of "intuitively >> understood", which generally boils down to striving for minimalism and >> high level of orthogonality (this is sometimes used to argue the merit >> of languages like Forth and Factor). >> >> sometimes things are "intuitive" but in unusual ways ("out in left >> field"), usually more when "intuitive" is used more in the sense of >> "being creative", or having a distinctive "flare" or "style". >> >> >> in some sense, these are relevant goals, but none are "intuitive" >> per-se, and could often just as easily be defined as "well, it is >> similar to these other things in these particular ways, and differs from >> them in these other ways". >> >> but, then for whatever reason there is a cultural bias against admitting >> that ones' "original works" are actually just created more like a jigsaw >> puzzle of bits and pieces of ideas from other works. >> >> but, sometimes, it is not about how original the pieces themselves are, >> but if they can be put together in interesting ways to deliver a product >> which is both "unique" and "original", but also matches reasonably well >> with peoples' expectations as to what the product should be (all of the >> parts should fit together into a cohesive whole, appearing neither as a >> mishmash or as something strange and alien, ...). >> >> >> or such... > > I agree with the point that humans cannot be assumed to have a hard-wired > intuition, based on Physics or otherwise. I suppose my intended meaning would > be better expressed as "consistent", ie. intuition gained from using feature A > will be a reasonable approach to using feature B.
Yes, we want our systems to be free of unnecessary surprises. I figured that was what you meant (using my intuition, *wink*.) But beyond that I think it's a good (and difficult) idea to build systems that, as much as possible, don't obscure their underlying mechanisms, and also enable us to explore and test the real-world systems around us. As you point out below, multithreaded programming is a perfect (horrible) example of an abstraction that "covers up" the underlying mechanics in a generally unhelpful way. On the other hand, there's a story (I believe it's in one of the VPRI documents but I couldn't locate it just now) about children using their machines to take pictures of a falling object and then analyzing the pictures and deducing for themselves the constant-acceleration rule for gravity. That's a wonderful example of what I meant about making systems that help us to construct true (or at least accurate) "intuitions" about the world. Cheers, ~Simon > A simple example where this is the case is iterable objects, eg. in Python > "for a in b:". Experience of basic objects such as lists and strings carries > over quite straightforwardly to, for example, XML parsing. > > An example where this isn't the case is multithreaded programming (eg. in > Python, Java, etc.). The language looks and feels like it does when non- > threaded code is being written, but under the hood all sorts of assumptions > are being violated in an incredibly non-obvious way. > > Regards, > Chris > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
