[Haskell-cafe] An idea to document inter department dependencies in Haskell
My dear Haskell folks, I work in a software company where I develop components that go into a really complex system that's built of several components developed by different teams that are geographically distributed. The components themselves run in a distributed manner across client and several servers. All our design documents are in wiki's (fashionably so). As a result of the above situation and the fact that our code base is not in Haskell, we are almost always dealing with "Oh I did not know this would effect that" and "Oh I have no clue what all this change will impact". I've been wondering if it would be a good idea to try and create a spec for the system in Haskell, such that would could get a better handle on the dependencies. Perhaps an EDSL, that would allow Product Managers to introduce new requirements - compilation failures would indicate the areas that would need to be touched. How is it different from having a spec in a diagram - well, in that case, we are requiring humans to look at the diagram to detect dependencies instead of the compiler telling me about the dependencies. I am about to start off with some implementation to capture my idea - I can articulate it better then. However, I just wanted to throw it out there to check if anyone's had some thought in this direction or if there is some prior art here. Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An idea to document inter department dependencies in Haskell
Hi, Just thinking aloud : A way to start is to define concrete workflows for concrete events. "What It is necessary to do if". This may make things more explicit and to clarify the problems. .Later, .maybe. these concrete workflows can be abstracted away from procedural/imperative to declarative and from concrete events to categories of events and tasks.. The declarative abstract description then could create concrete workflows. The best way to express the abstract description, and the way to transform the description in a concrete set of instructions depend on what is needed (The workflows produced can be just informative, in the form of a textual description of activities). Thus, the power users should handle the abstract descriptions, and the ordinary users could run the engine, perhaps they should answer some questions to obtain the concrete workflows for their intended tasks Not very informative, but better than nothing ;) Alberto 2012/3/13 C K Kashyap > My dear Haskell folks, > > I work in a software company where I develop components that go into a > really complex system that's built of several components developed by > different teams that are geographically distributed. The components > themselves run in a distributed manner across client and several servers. > All our design documents are in wiki's (fashionably so). As a result of the > above situation and the fact that our code base is not in Haskell, we are > almost always dealing with "Oh I did not know this would effect that" and > "Oh I have no clue what all this change will impact". > > I've been wondering if it would be a good idea to try and create a spec > for the system in Haskell, such that would could get a better handle on the > dependencies. Perhaps an EDSL, that would allow Product Managers to > introduce new requirements - compilation failures would indicate the areas > that would need to be touched. How is it different from having a spec in a > diagram - well, in that case, we are requiring humans to look at the > diagram to detect dependencies instead of the compiler telling me about the > dependencies. I am about to start off with some implementation to capture > my idea - I can articulate it better then. However, I just wanted to throw > it out there to check if anyone's had some thought in this direction or if > there is some prior art here. > > Regards, > Kashyap > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An idea to document inter department dependencies in Haskell
Thanks a lot Alberto, Actual code generation is not really my immediate goal ... What my immediate requirement is to validate the consistency of design changes. So essentially, this EDSL would not generate any target code - it's successful compilation would be the desired result and perhaps "more friendly" compilation error messages that can guide the non Haskell user to make corrections. Regards, Kashyap On Wed, Mar 14, 2012 at 5:31 AM, Alberto G. Corona wrote: > Hi, > > Just thinking aloud : > > A way to start is to define concrete workflows for concrete events. "What > It is necessary to do if". This may make things more explicit and to > clarify the problems. .Later, .maybe. these concrete workflows can be > abstracted away from procedural/imperative to declarative and from concrete > events to categories of events and tasks.. > > The declarative abstract description then could create concrete > workflows. The best way to express the abstract description, and the way to > transform the description in a concrete set of instructions depend on what > is needed (The workflows produced can be just informative, in the form of > a textual description of activities). > > Thus, the power users should handle the abstract descriptions, and the > ordinary users could run the engine, perhaps they should answer some > questions to obtain the concrete workflows for their intended tasks > > Not very informative, but better than nothing ;) > > Alberto > > 2012/3/13 C K Kashyap > >> My dear Haskell folks, >> >> I work in a software company where I develop components that go into a >> really complex system that's built of several components developed by >> different teams that are geographically distributed. The components >> themselves run in a distributed manner across client and several servers. >> All our design documents are in wiki's (fashionably so). As a result of the >> above situation and the fact that our code base is not in Haskell, we are >> almost always dealing with "Oh I did not know this would effect that" and >> "Oh I have no clue what all this change will impact". >> >> I've been wondering if it would be a good idea to try and create a spec >> for the system in Haskell, such that would could get a better handle on the >> dependencies. Perhaps an EDSL, that would allow Product Managers to >> introduce new requirements - compilation failures would indicate the areas >> that would need to be touched. How is it different from having a spec in a >> diagram - well, in that case, we are requiring humans to look at the >> diagram to detect dependencies instead of the compiler telling me about the >> dependencies. I am about to start off with some implementation to capture >> my idea - I can articulate it better then. However, I just wanted to throw >> it out there to check if anyone's had some thought in this direction or if >> there is some prior art here. >> >> Regards, >> Kashyap >> >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
