Slashdot Mirror

Those 3 horizontal lines ("hamburger" menu?) date back to the 80's, if not earlier. You can find them on screenshots of Windows 1.0 and even going going all the way back to Xerox.

Given the icon's 40-year provenance, you may have been introduced to the symbol, but that symbol was not just introduced. And if it was good enough for Xerox PARC, it's good enough for me.

dom

Charles Simonyi, one of the creators of Microsoft Word, went on a crusade to enable "intentional programming", which is to programming what the WYSIWYG word processor was to LaTeX. You can see what he does here. This is a VERY hard problem to solve. Simonyi is a good programmer, has tons of money, yet this is not a battle that he has clearly won yet.

I once received a phone call at work from a Forbes journalist, saying that Simonyi had described my own pet project, XL (http://xlr.sf.net), and the associated "Concept Programming" ideas as one of the only competitors to Intentional Programming. That was interesting, because it shows that Simonyi had "groked" what I wanted to do, despite the total lack of polish of this little project. (As an aside, if you are curious, you can see XL in action in Taodyne's software to create interactive 3D documents)

But what Simonyi saw (I believe) is that the general questioning was similar. How do we transform ideas into code. For Simonyi, this can be done with graphical tools. For XL, this can be done with simple transformations on text (more precisely, on a Lisp-like parse tree generated from the text). For example, with XL, you can implement the "if-then-else" concept using the "->" (transforms into) operator as follows:

if true then X else Y -> X
if false then X else Y -> Y

With this approach, it is possible to use nice notations for arbitrary concepts. In Taodyne's products, for example, a slide is described by something like:

slide "Hello world",
        * "This is a bullet point"
        * "This is another one"

This pseudo-markup language is then rewritten recursively until we reach "primitive" operations, e.g. 3D graphics rendering or basic computations.

XL is based on text because a) it's easier to do than Simonyi's approach, and b) I think it is generally easier to read and write "globally". If you have a "picture" in a document, of course showing the picture tells you more than just its name. But knowing that there is a picture in a document is easy with something like image "Woman.jpg" or (in HTML) a img tag.

As the experience with HTML or Postscript demonstrated, text or graphical does not matter much anyway. It's possible to have a text-based representation of the code that most people manipulate graphically and never need to be aware of. You can generate your HTML with Word, never need to know anything about it. It's likely the same thing is slowly happening with code as well: IDEs tend to give you more and more meta-data which is "behind" the text and helps you navigate it or code faster.

Oslo and M appear to be taking a page out of the research Charles Simonyi has been doing at Microsoft, before leading to develop and advanced form of the technology at his own company Intentional Software.

The basic idea here is that any bigger project can be made more maintainable and flexible at the same time, if the deveopers create a domain specific model for the given task, and let the end-users (for example accountants, drug store chemists, biologists, business owners) model the concrete behaviour of the application by manipulating that simplified and specialized language, often visually, the way an UML diagram or a spreadsheet works.

Unfortunately the linked article offers a little more than the usual "LOL, Microsoft sucks!" rant, which is somewhat expected from a blog where the iMac keyboard and iPhone are used as "design elements".

Anyway, I'd say this should be watched as it can mean model languages will finally enter mainstream, something that's been years in the making.

Related articles:

http://blogs.msdn.com/wenlong/archive/2008/09/07/net-4-0-wf-wcf-and-oslo.aspx

"By mentioning model-driven programming, you will see a general modeling platform to be unveiled at PDC: Oslo. As Doug said, Oslo contains three simple things: a visual tool helps building models, a new textual DSL language helps defining models, and a relational repository that stores models. XAML represented workflows and services are special models in this domain. Check for more details in the postings from Doug and Don."

http://blogs.zdnet.com/microsoft/?p=1430

"'Schemas in the repository can be defined using this language, but they dont have to be,' Chappell said. Developers can still use any other tools with which theyd be comfortable to create schemas instead. Because the new language will generate SQL, and the repository can be accessed using standard SQL, no special languages will be required."

The winner is...
I think DSLs are going to radically change the way that people code. DSLs potentially provide the meta-prgramming ccapabilities of LISP with the transparency and idiot-proofing of a language like Java. We may even see a hierarchy of software engineeringh develop, with one type of hihg-level coder deveoping DSLs and others able to use these languages easily within their own areas of expertise. For more, check the following links:

http://www.jetbrains.com/mps//
http://www.martinfowler.com/articles/languageWorkb ench.html
http://intentsoft.com/

For another take on post-textual programming, check out Intentional Programming. A little-known screencast demo is at http://www.cse.unsw.edu.au/~cs3141/ip.asf/. Unfortunately all their work is shrouded in mystery and non-disclosure agreements. The most complete account I have found is in Generative Programming

I believe that in the not-to-distant future the practice of programming in ASCII text will seem as antiquated as punched-cards

If anybody else goes to Simonyi's company and still can't figure out what they're talking about (mostly because it's vapourware at the moment, I believe), may I direct you to this Wiki. It turns out that he thinks source transformation tools will change the world.

I'm told that my university is one of the leading source transformation research centres in the world, but the only interesting things they're producing right now are for understanding legacy systems. So yes, there's probably a lot of money in source transformation, but it's also boring as hell.

These veterans shared a starting-point assumption that the rest of the world is only slowly beginning to understand: While computer hardware seems to advance according to the exponential upward curve known as Moore's Law (doubling in speed -- or halving in cost -- every year or two), software, when it advances at all, seems to move at a more leisurely linear pace.

As Lanier said, "Software inefficiency can always outpace Moore's Law. Moore's Law isn't a match for our bad coding."

The impact of this differential is not simply a matter of which industry gets to collect more profits. It sets a maddening limit on how much good we can expect information technology to achieve. If computers are, as it has often been put, "amplifiers for our brains," then software's limitations cap the volume way too low. Or, in Simonyi's words, "Software as we know it is the bottleneck on the digital horn of plenty."

Most successful programmers are at heart can-do engineers who are optimistic that every problem has a solution. So it was only natural that, even in this relatively small gathering of software pioneers, there were multiple, and conflicting, ideas about how we should proceed in order to break that bottleneck.

Simonyi believes the answer is to unshackle the design of software from the details of implementation in code. "There are two meanings to software design," he explained on Tuesday. "One is, designing the artifact we're trying to implement. The other is the sheer software engineering to make that artifact come into being. I believe these are two separate roles -- the subject matter expert and the software engineer."

Giving the former group tools to shape software will transform the landscape, according to Simonyi. Otherwise, you're stuck in the unsatisfactory present, where the people who know the most about what the software is supposed to accomplish can't directly shape the software itself: All they can do is "make a humble request to the programmer." Simonyi left Microsoft in 2002 to start a new company, Intentional Software, aimed at turning this vision into something concrete.

Jef Raskin jumped in. "And what do they put on top of it? Another Windows!"

"What are they thinking?" Lanier continued. "Why is the idealism just about how the code is shared -- what about idealism about the code itself?"

At this point, Andy Hertzfeld, who has devoted himself in recent years to open-source projects like Eazel and Chandler, spoke up for the maligned legions of Linux-heads. "It's because they want people to use the stuff!"

His comment underscored something that's frequently misunderstood about the open-source approach, which is often wrongly stereotyped as loopily communal and out-of-touch with business reality. There's an essential pragmatism to the notion that programmers work best when they can share, and learn from, one another's work. After all, every other field of human endeavor works that way.

Bricklin sent waves of laughter through the auditorium by reading a passage from Lammers' interview with Bill Gates in which the young Microsoft founder explained that his work on different versions of Microsoft's BASIC compiler was shaped by looking at how other programmers had gone about the same task. Gates went on to say that young programmers don't need computer science degrees: "The best way to prepare is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating systems."

Bricklin finished reading Gates' words and announced, with an impish smile, "This is where Gates and [Richard]

More Intentional Programming Links

IntentSoft