From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jeff Wilkinson Newsgroups: gmane.lisp.guile.user Subject: Re: request: libguile to wrap getsid(2) Date: Mon, 28 Dec 2009 19:08:18 -0600 Message-ID: <30b775c20912281708t5a9c8adcs519c042bcfc69ed0@mail.gmail.com> References: <87ws09y3g3.fsf@ambire.localdomain> <87pr601t5c.fsf@ossau.uklinux.net> <877hs8xbwi.fsf@ambire.localdomain> <3ae3aa420912271533u2294c7e7j7b794d21dbe67ff@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd6aa884f6d28047bd3a8bb X-Trace: ger.gmane.org 1262054937 24221 80.91.229.12 (29 Dec 2009 02:48:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2009 02:48:57 +0000 (UTC) Cc: guile-user@gnu.org, Thien-Thi Nguyen To: linasvepstas@gmail.com Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Dec 29 03:48:50 2009 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NPS8g-0006ef-0G for guile-user@m.gmane.org; Tue, 29 Dec 2009 03:48:50 +0100 Original-Received: from localhost ([127.0.0.1]:36658 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPS8g-0006K7-7s for guile-user@m.gmane.org; Mon, 28 Dec 2009 21:48:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPQZU-0008Mq-Oo for guile-user@gnu.org; Mon, 28 Dec 2009 20:08:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPQZQ-0008MO-Q0 for guile-user@gnu.org; Mon, 28 Dec 2009 20:08:24 -0500 Original-Received: from [199.232.76.173] (port=51930 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPQZQ-0008ML-La for guile-user@gnu.org; Mon, 28 Dec 2009 20:08:20 -0500 Original-Received: from mail-yw0-f177.google.com ([209.85.211.177]:56647) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NPQZQ-0004PQ-1z for guile-user@gnu.org; Mon, 28 Dec 2009 20:08:20 -0500 Original-Received: by ywh7 with SMTP id 7so1033872ywh.24 for ; Mon, 28 Dec 2009 17:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=C4tZUI/QGGRme5heu9xZwSNW0t9YJT6jsXfGyjjEMzk=; b=iaPbmXft36vM+DOCg/BAg8M3XdK+cgqQG0iWqGDJTh3J8i0qBaYPNbpzkBmW9XnXQa G54tNX+Lx/NEJaHajKpTUYVHXQuHR8t055Kz2iN1Eb9HA2KJFCnPWYj+hN0pThOiXyqR ElFnqSw8eVhq2o9VP7GpXPKczLoq6M6S0b1XE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rQCwaNCvDUeqZXo/jbjeMcwmjM9mRtZBo43AQ2jx4gt6LdL626o2l5oziYbgybVpcC 3YUAPBtj0w49Rn6f3wdp4JLoaX/zrs5V4Gawr2lbfZpMIoJOLngjBuHZR52qCuoLk2mA wL+0+1IZMzFMTgzkv7x7td7QR9molYG/3HL1s= Original-Received: by 10.150.246.10 with SMTP id t10mr23687000ybh.226.1262048898929; Mon, 28 Dec 2009 17:08:18 -0800 (PST) In-Reply-To: <3ae3aa420912271533u2294c7e7j7b794d21dbe67ff@mail.gmail.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Mon, 28 Dec 2009 21:47:59 -0500 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:7589 Archived-At: --000e0cd6aa884f6d28047bd3a8bb Content-Type: text/plain; charset=ISO-8859-1 Hey, good to hear from you. Yes, this is my bailiwick. For the past few years I've been writing code transformation tools. The semantic "essence" you mention is usually in what the industry calls an AST (abstract syntax tree), and in other data (symbol tables, at a minimum). This is very analogous to what optimizing compilers do. And in our case we're often dealing with larger patterns. Like isolating presentation layer, business rules, and data access layer stuff, and translating them differently. The OMG's "Patterns Group" is even trying to standardize this AST data. (Although that effort sounds only marginally useful to me.) There is also the Eclipse Metadata Framework, which I haven't had much chance to look at, but sounds promising from what I've read. For us, the "old code" comes in a wide variety of forms. It seems the industry has phases where there are more and then less programming languages to choose from. (It looks to me like we're transitioning into a "more languages" phase right now.) Most of our clients want to modernize code from the previous "more languages" phase (prior to the popularity of C). My own work is entirely in the automation, but overall, the percent that is automated varies wildly from project to project. Sometimes the automation is only used to obtain statistics or spot problematic patterns, but our large projects are all about creating maintainable and modern versions of large legacy systems. So, uh, that's my answer. What was the question? -Jeff On Sun, Dec 27, 2009 at 5:33 PM, Linas Vepstas wrote: > 2009/12/27 Thien-Thi Nguyen : > > > As years go by, i have come to venerate old code per se less and > > less. > > Heh. As the years go by, I have come to venerate any code, > old or new, less and less. It's always broken, and never actually > does what you want, anyways. > > > I think it would be cool to write tools to distill the > > essence of old code, recasting into new code. That is what > > compilers do, after all... Dreaming, i'd like to see compilers > > that go beyond: > > > > compilation > > source ---------------------> "executable" representation > > > > to > > > > grok-db -----+<-------+ > > v | > > compilation | > > source ---------------+----> "executable" representation > > > > where grok-db contains the analysis results of (this and other) > > source, both present and past. > > Well, taking away two lessons from the recent past: > -- "optimizing" compilers try to "grok" some small portion of the > code, and re-arrange it in such a way that its more efficient. > The challange is to "grok" ever-larger pieces. > > -- There are companies that specialize in taking :"legacy" code, > written in strange old language dialects, and automatically > modernizing/re-writing them to run on modern h/w. I don't really > understand what the "old code" is, or exactly how much of the > re-write process is automated, but its apparently a big business > (i.e. big businesses that have lots of old code buy these things) > I have a friend who works in this area, Jeff Wilkinson, perhaps > he can comment. > > --linas > --000e0cd6aa884f6d28047bd3a8bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey, good to hear from you.

Yes, this is my bailiwick. For the past= few years I've been writing code transformation tools. The semantic &q= uot;essence" you mention is usually in what the industry calls an AST = (abstract syntax tree), and in other data (symbol tables, at a minimum). Th= is is very analogous to what optimizing compilers do.

And in our case we're often dealing with larger patterns. Like isol= ating presentation layer, business rules, and data access layer stuff, and = translating them differently.

The OMG's "Patterns Group&qu= ot; is even trying to standardize this AST data. (Although that effort soun= ds only marginally useful to me.) There is also the Eclipse Metadata Framew= ork, which I haven't had much chance to look at, but sounds promising f= rom what I've read.

For us, the "old code" comes in a wide variety of forms. It s= eems the industry has phases where there are more and then less programming= languages to choose from. (It looks to me like we're transitioning int= o a "more languages" phase right now.) Most of our clients want t= o modernize code from the previous "more languages" phase (prior = to the popularity of C).

My own work is entirely in the automation, but overall, the percent tha= t is automated varies wildly from project to project. Sometimes the automat= ion is only used to obtain statistics or spot problematic patterns, but our= large projects are all about creating maintainable and modern versions of = large legacy systems.

So, uh, that's my answer. What was the question?

=A0 -Jeff =

On Sun, Dec 27, 2009 at 5:33 PM, Linas V= epstas <lina= svepstas@gmail.com> wrote:
2009/12/27 Thien-= Thi Nguyen <ttn@gnuvola.org>:<= br>
> As years go by, i have come to venerate old code per se less and
> less.

Heh. As the years go by, I have come to venerate any code,
old or new, less and less. =A0It's always broken, and never actually does what you want, anyways.

> =A0I think it would be cool to write tools to distill the
> essence of old code, recasting into new code. =A0That is what
> compilers do, after all... =A0Dreaming, i'd like to see compilers<= br> > that go beyond:
>
> =A0 =A0 =A0 =A0 =A0 =A0compilation
> =A0source ---------------------> "executable" representat= ion
>
> to
>
> =A0grok-db -----+<-------+
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 v =A0 =A0 =A0 =A0|
> =A0 =A0 =A0 =A0 =A0 =A0compilation |
> =A0source ---------------+----> "executable" representati= on
>
> where grok-db contains the analysis results of (this and other)
> source, both present and past.

Well, taking away two lessons from the recent past:
-- "optimizing" compilers try to "grok" some small port= ion of the
code, and re-arrange it in such a way that its more efficient.
The challange is to "grok" ever-larger pieces.

-- There are companies that specialize in taking :"legacy" code,<= br> written in strange old language dialects, and automatically
modernizing/re-writing them to run on modern h/w. =A0I don't really
understand what the "old code" is, or exactly how much of the
re-write process is automated, but its apparently a big business
(i.e. big businesses that have lots of old code buy these things)
=A0I have a friend who works in this area, Jeff Wilkinson, perhaps
he can comment.

--linas

--000e0cd6aa884f6d28047bd3a8bb--