Guis widget server is a Gtk2 widget server. It listens on pipes for widget requests (in the Python or Ruby (or Slang, etc.) scripting languages), and emit replies or events in textual lines (e.g. Lispy, XML or plain token syntax). It is useful for programs (in particular setuid programs) and scripts that don't or can't link the Gtk2 libraries and need to delegate the user interface to another process.
GCC-MELT is a high-level domain specific language that eases the development of plugin-like extensions for GCC, the Gnu Compiler Collection. These extensions can analyze or modify GCC internal representations, and can be used for static source code analysis, refactoring, specific warnings, optimizations, etc. The MELT language provides high-level features. Notably, MELT code is translated to C or C++, and can even contain C or C++ code. It includes powerful pattern matching facilities and can manipulate dynamically typed values and raw GCC structures. It enables functional/applicative, object-oriented, reflective programming styles and has a familiar Lisp-like syntax.
Re: Programming is not about algorithms
Trying to replace programmers with a machine again?
But the goal of partly automating programming tasks has been sucessfully pursued since about 50 years. In 1960s, compilers like FOR[mula] TRAN[slation] had exactly this goal (avoiding human assembler programming, and having the assembler code generated by a program, which is now called a compiler, and today human coders don't code in assembler anymore...). Likewise, a compiler made in France in 1959 was called Programmation Automatique des Formules (automatic formula programming), because its translated a Basic-like language into machine code (on a drum computer, the CAB500).
So my point is that software engineering, and programming language design, and compiler implementations is all about somehow automate or assist the task of programming computers (remember, computers only understand machine code).
Some knowledge based systems may help in this task. There are lots of code generators today, and many areas have domain specific higher-level languages.
Overall, I believe we agree. I don't claim that any fully automatic software will do all the human work in a foreseab le future. But the half-century trend is in assisting human programmers in working faster and better, and I do feel that some progress has been made since the 1950s (we human programmers are not working the same way and with the same tools as 50 years ago).
BTW, the PAF language was designed and implemented by my late father in 1959 (the year I was born), and I know for sure that I am not programming the same way as my father did. He coded in machine code, mostly with a pencil and paper; I'm coding in Ocaml or C, mosty with Emacs (on a PC/Linux computer costing 50 times less, and running 100 000 times faster, with 1 000 times more memory than in 1958).
So we both agree. We might have a disagrement on what is called the strong A.I. hypothesis, but this is not very relevant here.
Re: A fine example of what not to do
See also the Speaking about oneself (.doc) (http://www-poleia.lip6.fr/~pitrat/Speaking_about_oneself.doc) Pitrat's paper, and Implementation of a Reflexive System (http://www.sciencedirect.com/science?_ob=IssueURL&_tockey=%23TOC%235638%231996%23999879997%23101983%23FLP%23&_auth=y&view=c&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=145756973eb7da12f5d48c2858b30968) paper (not freely online, Future Generation Computer Systems 12, pp. 235-242, 1996) both by J.Pitrat