[plt-scheme] Jane Street Summer Project 2009

From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Mon Feb 2 11:33:49 EST 2009

On Mon, Feb 02, 2009 at 09:29:07AM -0700, Matthew Flatt wrote:
> At Mon, 2 Feb 2009 15:49:47 +0000, Noel Welsh wrote:
> > On Mon, Feb 2, 2009 at 12:31 AM, Grant Rettke <grettke at acm.org> wrote:
> > > A typical IDE set up might include the notion of a project, a file
> > > browser, a module browser, a class browser.
> > 
> > Of these I think the notion of a project is the most important. It
> > should include:
> > 
> >  - standard directory layout, prepopulated with standard stuff
> >  - one-click testing, building, build for planet, planet dev. link
> 
> For my part, I've tried to avoid introducing the notion of a "project"
> into PLT Scheme tools.
> 
> It isn't because I'm unused to the project concept. My first real
> programming experiences were using CodeWarrior on the Mac. I still
> (have to) use projects with VisualStudio. And I'm forced to use XCode
> sometimes.
> 
> Personal taste aside, the technical problem with projects --- as
> usually implemented --- is that they are outside the programming
> language. If your project tools are missing some functionality, then
> you're either stuck doing things manually or you learn the project
> system's ad hoc extension API.
> 
> I've instead pushed the idea that everything should be code organized
> into modules. If you want a new programming language, you don't tell
> the project manager that it should run some command-line tool on files
> that end in ".xqz". Instead, you import the "xqx" language into your
> module (perhaps via "#lang xqz"). I'm convinced that this approach is
> more systematically extensible and composable.
> 
> That approach is potentially compatible with a notion of projects. I
> can imagine a project description that starts "#lang project" and that
> does great things. But if there are some "project description" files
> sitting around that aren't code, or if doing something with a project
> (other than editing it) requires looking at the source of the
> description (in some fixed syntax) instead of "running" the project
> description, then it will seem to me like the wrong approach.

So if there are to be anything like project files, they should be 
executable PLT Scheme code, just like everything else?

On the other hand, separating code into "projects" is useful for 
revision-management systems and organizing "releases" -- identifying 
particular subsets of the code as being a particular version of a 
particular subsystem.  Monotone is a system of that sort that I 
appreciate.  It conceptually separates "development", which yields a lot 
of nonworking code, from "certifying" the code that actually works.  
This to the extent that you're even encouraged to check in rough drafts 
of new code so it's available for discussion.  But the concept of 
"project" is within the monotone distributed database, not in the code 
baing edited on your machine.

- hendrik


Posted on the users mailing list.