Lambda the Ultimate

I didn't provide a link on a purpose - the rationale was that I was mostly interested in POV of a user who already suffered from various warts of the subject.
Also, the documentation is not what I call condensed, and some features can be understood only by looking at the source code - so I certainly do not expect people to learn Seam just to keep this discussion.

The reason I asked in the first place was that after a few attempts of using Seam I noticed limiting myself to a subset of features, used in a quite idiomatic way. In a way, one may call this a backward Sapir–Whorf hypothesis experiment - whether people with different background carve different sublanguages from an underconstrained set of features.

I reviewed Seam once after I projected a similar, declarative / annotation based framework in C# having in- and outgoing connections. The idea was to provide goal oriented programming style. Other than Qt's signals and slots where a signal triggers a method invocation, I wanted backward chaining: if a component required a property for being initialized properly a request had to be sent. A broker seeked for a component provisioning an outgoing ( "outjected" ) property accordingly and triggered it first ( the component could be a modal dialog or a little session communicating with an external device. It had provisioned its own execute() method ). What was dropped in this model was a workflow in which components had to register themselves explicitely. Instead attribute reflection was used to establish connections.

When I encountered Seam I was surprised about additional flexibility and complexity. While I was heading towards statically checked connections as a possible future support built into the compiler and considered resolving ambiguities as the biggest obstacle ( what if many components provide the same properties? ) it was hard to see what Seem was going for. So I might, however very indirectly, confirm your subset approach.

Amusingly, I turned my attention to Seam after discontinuing an internal project that was also inspired by Qt (but in Java, and for Web). For record, it was very difficult to switch to Seam's memes, despite, or maybe because, it was so superficially similar (at least, as marketed).

When I came back more than a year later, I suddenly found that I can use Seam much better, probably because I forgot "wrong" memes. It seems that additional knowledge can be harmful.

Returning to the less subjective branch of my questions - can we see Seam as a PL? Then what is Java for this PL? Or is Java+Seam a PL? What kernel features of this combined language are there? Can we factor them out into a calculus, and grow a new PL from it, which hopefully will be more concise, simple, and usable?

Are there some classic analogs to Seam (like, I don't know, Qt for Lisp or Scheme)? I do not mean AOP here - while heavily using AOP(-like) facilities, Seam by itself provides quite different features.

While I am more interested in meta-properties, discussion of specific (mis)features is also welcome (I hope this will be still on topic for LtU). E.g., I was quite disappointed by lack of declarative dataflow-driven evaluation (I guess it's what Kay calls backward chaining) - one has to make do with manually triggered events, factories, and managers.

Welcome to the club :-)
Or maybe you should welcome me - I started designing DSL targeting Seam just about 10 days ago.
And yes, I am going to forbid excessive and uncontrolled freedom - kind of static checking is already in place.

One thing that strikes me at the moment (besides already mentioned on this thread) is limited semi-flat mechanizm of scoping - for some use cases I want to have trees of contexts, with branches indexed by domain-controlled keys. Uh, I might end up designing target VM as well :-)

Well, you can have a stack of contexts (nested conversations), but I doubt you want to go down that route. Creating an intuitive app using flat conversations can be hard already, and the supporting mechanisms are all a bit shaky IMO.

A stack is a very special kind of a tree. And yes, I agree that the supporting mechanisms are quite shaky and flaky.
That makes me wonder sometimes, whether the Java platform in a broad sense (all the specs and products) is coming to a crisis. Sometimes it looks like having too many pieces and indirections. Well, I am not proposing to routinely build HTTP server as a part of every business project, but... Sometimes it feels that 90% of specs are discussing indirection and binding, and mapping - sounds like a need for a change in PL for me... End of rant...

Do you have some papers public, in which you describe
how your seam and hibernate DSLs looks like?
I'm doing a master thesis right now, and am planing on
modeling a seam application for some prototypic usage.
I have found the DSL of Eelco Visser, and would really
like to have a look at yours.

greetings
barfoos

..., as I was doing this with my SE hat on, not CS one.

My posts in this thread might have been misleading - initially, I discussed Seam and Hibernate as DSLs in their original form.

Later, I mentioned my own "kinda DSL" - a set of idioms I tried to use when building Seam applications. This set is not formalised anywhere, but basically can be described as generalized Petri net - where places correspond to Seam context variables and events, and transitions - to methods annotated with @Observer. If implemented accurately, this model has SE merits - places form contract between components, thus providing loose coupling. Sometimes this is too loose, suffering from absence of any sequencing information (not to mention scoping in usual sense as opposed to Servlets/Seam sense), thus opening doors to deadlocks and race conditions. Anyway, after playing with this model I understood benefits of declarative concurrency even better than before (hint: Google for CTM or PVR) :)

I'm a master student of Eelco Visser, and we've been working along the same lines. I'm currently working on my thesis, and I'll post a link here when it is finished. Main difference between Eelco's approach and mine is, that his DSL is monolithic (i.e. all concerns implemented in single language by a single compiler). I explicitly tried to create a prototype in which the different aspects are decoupled into smaller languages (i.e. I have a language on top of Hibernate, and a language for modelling pages/pageflow/dataflow on top of Seam). This way, flexible composition of (for example) my existing DSL on top of Hibernate with another DSL is feasible. I implemented this by means of interface files. The interaction between these DSLs is one of the topics discussed in my thesis.

Reading the paper of Eelco Visser, I actually wondered why he used Seam
as his Platform and did not make more use of conversation scoped stateful session beans and also of the @DataModel and @DataModelSelection feature. I just wondered if it really is a good idea to use such a top level framework as seam and then fall back to "primitive" things like simple page navigation with parameter passing.

Don't get my wrong. I realy like the work of Eelco. And I appreciate
pretty much, that his DSL already works whereas mine is pretty lame
and at the moment can't cope with anything more complex than simple presentation of data in tables.

I'm quite new to both Seam and MDSD. In a similar approach as you I am trying to seperate concerns as much as possible an try to find multiple DSLs with which it will be possible to model web sales applications on a seam platform.

Have you found DSLs with which you can make use of the conversation-, datamodel-, and datamodelsection- feature of seam?

What do you mean by a DSL on top of Hibernate? Do you model application data and hibernate in different DSLs?

greetings
barfoos

Actually, the explicit parameter passing is somewhat my idea, since it seems like a natural concept to model data-flow through web-applications for me. Whether you implement as we did (by passing id's) or whether you devise a more sophisticated scheme (e.g. in/outject them using conversation scope) is a second question to me. And one that can be easily changed once you have the basic notation and model elements, by changing the generator/compiler/backend (however you want to call it). Also, I added abstractions for using session scoped data, though things already get rough when mixing the two in every aspect. And why Seam: well, it just works. It's just a tool to get the job done (that is making a webapp), really. And yes, I use @DataModel, conversational java beans etc. But probably not as good as an expert Seam user would. (Actually, I know someone is also working on an Echo2 backend for Eelco's DSL)

As for my Hibernate language, it looks something like this:

concept BlogEntry {

  title    :: String    (name, required)
  abstract :: String
  contents :: String
  date     :: Date      (required)
  tags     -> [Tag]
  replies  <> [Reply]
  category :: {"Technical" : TECH, "Other" : NONTECH}
  user     -> User 
  
}

Which maps to a 240+ LOC (!) entity class, with correct annotations and relations to other classes (which are generated from other concept defs) etc. The definition of this data stuff is in a different DSL (I call it DomainModel DSL) than the presentational stuff (which is what I call my WebLayer DSL). WebLayer can import and use DomainModel definitions. Both have a distinct compiler though, so DomainModel can also be used in composition with other (currently non-existant :) ) DSLs.

I'm not going to detail every construct of my languages now (thesis will contain it all) but I think you catch the drift. Let me know how you progress, I think this stuff is very interesting!

Thanks for the details. I can see, where you are heading. Very interesting indeed.

As for my progress: I've also got a DomainModel DSL from which,
EntityBeans and EntityHomes are generated. I've got one DSL that describes DataProviders. From this DSL SessionBeans will be generated the will biject Objects to and from the JSF View. I've got an Eventhandling DSL. For the view I don't use models but plain JSF
in an attempt to combine hand written code with generated code.
My goal is to seperate concerns as much as possible and generate each DSL into its own code and provide some means for semiautomatic glue code generation.
Everything is still a great mess, so I can't give more details because
I don't have them ;-)

greetings
barfoos