The Machine's Language
Simonyi was born in Budapest in 1948. The son of a physics professor, he fell in love at 15 with his first computer--a mammoth Russian Ural II in Hungary's Central Statistical Office. By the 1960s, the Ural, which received its instructions through cash-register-style keys and had a roomful of vacuum tubes to perform calculations, would already have been a relic anywhere else in the world. But Hungary's Communist leaders were trying to use the Soviet castoff to optimize rail and trucking schedules. The Ural wasn't up to the task: there was no way to input real-time data on shipments. "It was completely hopeless," Simonyi recalls. "It could have been done very easily by supply and demand. Unfortunately, that was politically incorrect."
But Simonyi didn't care. "I loved that computer," he says, "even though it was useless." As a child he had built an Erector Set car with a four-speed transmission--not so much because he wanted to play with it as simply to understand how it worked. A former student of his father's found Simonyi a job as the Ural's night nurse. Because the machine blew out a tube each time it was turned off and on, the Statistics Office preferred to allow it to run all night. Thus, from dusk to dawn, the mainframe was all Simonyi's; he had a personal computer before such things existed. He learned to program it by writing clever but useless routines to generate "magic squares"--numerical arrays in which the sums of the rows, columns, and diagonals all match.
Programmers elsewhere in the world had already invented a Babel of programming languages--Fortran, Cobol, Lisp (a fabled language: see "Ancient Text," p. 20), and so on--to ease their work, which then as now consisted of painstakingly writing elaborate sets of instructions for computers to execute. In those languages, the instructions took the form of lines of text that were entered on keyboards and frequently stored on punch cards. This "source code" was then "compiled," or translated into "machine code"--the 1 s and 0 s that a digital computer could understand. The method remains largely unchanged today, even if most programmers now use programming tools running on ordinary PCs. But on the Ural, Simonyi learned to program at a more primitive level, laboriously punching in the "opcodes" of machine language, specifying, instruction by instruction, the sequences of memory fetches, additions, memory stores, and jumps that the computer's processor had to follow to execute even the most trivial operation. It was (as Simonyi told author Steve Lohr in the 2001 book Go To ) "Stone Age programming." Simonyi still remembers the codes. "Twenty-two is JUMP," he says today. "It's burned into my ROM."
Hungary in the 1960s, still flinching from the Soviet suppression of its 1956 revolt, was not a place for an ambitious young man with a taste for problem-solving. At 17, Simonyi landed an internship with a Danish computer company by showing some of its programmers samples of his hand-coded Ural programs. The Hungarian authorities expected Simonyi to return; he'd already won a coveted university spot. Instead, with his father's encouragement, he fled to the United States.
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