|
January 2007 Anything You Can Do, I Can Do MetaContinued from page 5 By Scott Rosenberg
Levels of Abstraction Wysiwyg is an example of a layer of abstraction--a higher-level tool that allows computer users to ignore some lower-level complexity. Programmers use abstractions all the time. The text code written in a programming language is an abstraction of the machine code that a computer actually understands. A Web domain name is an abstraction of a server's numerical Internet Protocol address. But most of the layers of abstraction in computer systems are less visible and more arcane than Wysiwyg. Ever since programmers stopped memorizing the opcodes that Simonyi used in his youth, they have been layering new abstractions upon older abstractions. Every generation of programmers uses its era's programming languages and tools to build the programs of the next generation. Layers of abstraction have accumulated like geological strata. Messages are constantly racing up from the binary bedrock of your machine and back down again, making it possible for a mouse-click to accomplish its function. Your mouse-click triggers some code in the operating system, which sends a message to the word processing program, which instructs the operating system to save your file to a hard drive. But that apparently simple process is possible only because of many, many layers of abstraction. The history of software is the history of these layers, each of them lifting programmers farther from the binary, leaving them better able to coax computers into performing useful tasks. Steadily, programmers gained more power. But they were also tackling ever more ambitious problems. Programs ballooned in size, and programmers started getting lost in tangles of what they called "spaghetti code," which proved impossible to unravel and repair. Thus, large software projects became epics of frustration and delay. Program managers faced business problems like, How do you realistically schedule a project? How do you improve individual productivity? How do you coördinate complex work across a large team? Each of these questions proved surprisingly difficult to answer. The difficulty of coördinating a team's work inspired software engineering's most famous dictum, known as Brooks's Law: "Adding manpower to a late software project makes it later." Frederick P. Brooks Jr. reached this gloomy conclusion after leading IBM's troubled effort to write software for its 360 mainframes in the 1960s. In his 1975 book, The Mythical Man-Month , Brooks observed that work proceeds slower on bigger teams because of "coördination costs"--the time programmers lose keeping one another apprised of their work. This was the backdrop for Simonyi's 1977 dissertation, "Meta-Programming: A Software Production Method." Simonyi proposed a new approach to "optimizing productivity," in which one lead programmer, or "meta-programmer," designed a product and defined all its terms, then handed off a blueprint to "technicians," worker-bee programmers who would do the implementation. Simonyi aimed to escape Brooks's Law by forbidding the technicians to talk with one another: all communication had to pass through the meta-programmer. For his dissertation, he tested the idea using two groups on two projects, A and B. His despotic approach to programming never caught on, but that hardly troubled him. Simonyi's chief goal in researching his dissertation wasn't to prove the value of his ideas but to get Bravo, the new Wysiwyg word processor, written faster. He couldn't persuade the PARC brass to hire additional programmers, so he used his dissertation as a subterfuge to bring in some help. Bravo itself was project B. |
Audio »
Share »
Digg this
Add to del.icio.us
Add to Reddit
Add to Facebook
Slashdot It!
Stumble It!
Add to Newsvine
Add to Connotea
Add to CiteUlike
Add to Furl
Googlize this
Add to Rojo
Add to MyWeb
Favorite
Print
E-mail
IBM's Symphony for the Office Worker
09/28/2007
Comments
rajuch on 02/07/2007 at 11:38 AM
1
How does it solve the software updates problem? What would happen, if they need to change some features six month from the installation? Can we put the bench back in the machine to refine the bench, or do we need to start over and pay for full new bench? Many online applications are being updated every other month.
If one needs to build a computer table or wooden cabinet, can he use that bench-making machine? Or does he need to build a new machine for each kind of products? I am not joking. You would agree, if you read the following.
We already invented such machines for building online-GUI-applications. Greatly appreciate your feedback, what you think about our online GUI application making machine. Please review brief overview to our application machine:
http://cbsdf.com/technologies/software-irony.htm
Each ‘Component Factory’ in the left side of the Figure#1 acts as a knob, to refine each part (i.e. a loosely coupled component/AC) in the application (shown right side). Please review the following WebPages, which show that this process builds perfect ‘application machine’ with simple to operate knobs to refine each part. Please review summary at the end to understand why it cost only a fraction to refine the application:
http://cbsdf.com/ps_blog/Minimum-couplings.htm
http://cbsdf.com/ps_blog/super-distribution.htm
P.S: Of course, one must use our highly-flexible online-GUI-API to build the online GUI components. You may see interactive GUI Components, which are built using SVG. We will be building the GUI Classes for XAML/Vista in the future.
http://cbsdf.com/technologies/demo-links/Demo-SVGS/misc-charts.html
More sample links at: http://cbsdf.com/technologies/demo-links/demo-links.htm
One may build his own custom GUI Classes, for example, to build multi-player online games or near real-time modeling of Air-traffic, as explained at:
http://cbsdf.com/Newbies/Flight-main.htm
http://cbsdf.com/misc_docs/online-apps-rock.htm
Best Regards,
Raju
sriramv.iyer on 02/13/2007 at 4:59 AM
1
But this article did rekindle my interest in DSLs. (I use python and not lisp, though)
rubs74 on 02/22/2007 at 5:27 PM
1
Model Driven Architecture also adds a new level of abstracction to software development and I guess that takes the base idea of Intentional Programming as well. There are already tools that work on production. Here there's a tool based on MDA that really allows you to think more about the bussiness logic and less about the complexities of building it, just take a look http://www.care-t.com/
JEfromCanada on 03/09/2007 at 3:10 PM
1
bushka on 03/14/2007 at 5:55 PM
1
oscarbhaskar on 06/13/2007 at 10:11 AM
1
The question now is how do we implement the concept? How do we capture the "Intention"?
I think we are about to see a new dimension in the way software is developed.
enterprise on 06/30/2007 at 2:45 PM
1
By Christmas.
We will make sure the writers of this excellent article know in good time.
In the meantime, if you want to be involved with the fun, get in touch on gedymail@gmail.com
GD
Corbier on 12/25/2007 at 2:02 PM
4
For a quick glance at what a language definition file might look like, check out:
www.ucalc.com/lisp.txt (Lisp)
www.ucalc.com/forth.txt (Forth)
The download includes more files like this, which you can load up into the generic interpreter, at which point it becomes an interpreter for the language you just loaded. (The supplied interpreter demonstrates just one possible kind of interface. You can create your own fancy interface to interpret such code).
uCalc LB is no longer in the idea stage. An actual fully working beta implementation can be downloaded.
I am the author of uCalc Language Builder (as well as uCalc Fast Math Parser), and I am looking for early adopters of the uCalc LB technology. An interactive tutorial that comes with the download can walk you trough the various concepts. Other forms of documentation are also included, as well as an interactive interpreter.
--
Daniel Corbier
www.ucalc.com