Great question. My simplest counter-example would be any GUI system that syntactically assumes a containment relationship is the most powerful way to express complex user interfaces. In my experience, such containment relationships only make sense for applications where you can "place every pixel", such as Outlook.
The Scannerless Generalized LR Parsing OOPSLA paper from I think 2004 is a good example of how people argue incorrectly that smaller size equals less complexity. The moment you have requirements with complex interactions that violate the semantic constraints the syntax is imposing, you no longer have a "high slope" language. To see what a huge semantic deal this is, please read Microsoft architect Mike Hillberg's blog post http://blogs.msdn.com/mikehillberg/archive/2008/05/23/Of-logical-and-visual-trees-in-WPF.aspxwhere he half correctly characterizes a problem as essentially unsolvable due to how WPF encourages encoding visual solutions in terms of the static production rules of the WPF renderer. He comes to the wrong conclusion, though, in my humble opinion. Trustworthiness is a separate matter, and includes issues such as hardware-software compatibility verification and validation. It is not some "Microsoft marketing initiative" (or however somebody described it earlier). On Tue, Mar 2, 2010 at 4:18 PM, Andrey Fedorov <[email protected]> wrote: > John Zabroski wrote: > > the three stumbling blocks are size, complexity and trustworthiness > > > How are these different? > > A small program is a simple program by definition, assuming it's expressed > in an intuitively comprehensible way. And a simple program is a program I > can trust to do what I think it does. Conversely, the only reason I wouldn't > trust a program (assuming I trust the compilers/interpreters) is because it > would be too complicated to understand. That's what I meant when I quoted > SPJ earlier: > > "Tony Hoare has this wonderful turn of phrase in which he says your code >> should obviously have no bugs rather than having no obvious bugs. So for me >> I suppose beautiful code is code that is obviously right. It's kind of >> limpidly transparent." -Simon Peyton Jones, from Peter Seibel's "Coders At >> Work" > > > Cheers, > Andrey > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
