This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Language design (was Re: sort a foreach on a stat value?)


On Mon, 2006-01-16 at 16:48 -0500, Frank Ch. Eigler wrote:
> hunt wrote:
> 
> > [...] Is is too late to try to make the language small, easy to use,
> > efficient [...]
> Like apple pie and fatherhood, everyone wants those things.  

Apparently not. I haven't seen any discussion on the issue, just
discussion on how to implement yet another feature in foreach.
I see too much emphasis on new features and not enough on efficiency and
ease-of-use.

> They help
> contrast individual proposals, but that's what we've been doing.  If
> you have other ideas, that's great, bring them on.  Even better if
> they consider broader system issues rather than just language syntax.

That is exactly what I would like to see. More thought to improving the
whole systemtap experience. 

> > If you really want really fancy post-processing, instead of beefing
> > up our language, a far better solution would be to pipe the through
> > a different interpreter, like perl.
> 
> While that opinion is embodied by dtrace, I suspect you will find not
> everyone is quite so enthused about the requirement to write
> nontrivial analysis scripts in *two* languages.  

How do you know? Have we done a survey? Do you think the systemtap
language should be:
A. Very small, simple, fast and allow you to do post-processing in your
favorite scripting language, like perl, python, tcl, etc. Available RSN.
B. Large, complex, slow and include everything you could possible need
including a builtin email client. Available 2008.

or maybe we start with A and expand the language only if users tell us
there are clear advantages to doing so.

> You will also find
> that there is no obligation to use the foreach/if/for control
> constructs to richly process one's data.  For those wishing to do it
> like dtrace, what obstacles do you believe we interpose?

Of course in a complex language, features can be ignored. But consider
how many months of development time went into the foreach statement and
how it continues to mutate. Each new feature added pushes the release
date for 1.0 back and adds complexity to the language, making it less
desireable to those who just want to use systemtap without learning
another large complex language. 

Martin



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]