On Tue, Jul 25, 2000 at 10:23:24AM -0400, Dan Sugalski wrote: > This is due soon, so before I forget: > > The Internals Design job description > ==================================== > > The whole point of this position is to be responsible for, though not > necessarily design (as we have lots of clever people), the internal > interfaces perl presents. The primary target is for programs that embed > perl, extensions that perl embeds, and (to a lesser extent) embedded > systems. The design of the internal data structures and code flow is a > secondary responsibility, but it's more an advisory position there, as the > internals will tend to flow naturally from the language design and > interfacing requirements. In the event that perl gets partitioned (into > lexer/parser, optmizer, and execution engine, say) this position's > responsible for the interfaces between those partitions as well. > > In other words, my job is to make sure perl talks nicely and easily with > the rest of the world, and to itself. The code behind the conversation is > someone else's responsibility. Probably a nit-pick... that sounds more like "Internals *API* Design" rather than "Internals Design" to me. Somewhat related to that... I'm a little concerned that you have "internal data structures and code flow" as a "secondary responsibility". While I see your point, to some extent, I'd rather they were considered together. I don't see any value in making a primary/secondary distinction here. Tim.Thread Previous | Thread Next