Hi,
I am Robert. I have been working on and with (formal) methods since 1991. I see languages as a tool to capture the decisions in a (development) process. That is why I am interested in this community.
Developing software is currently a more repetitive task than many developers believe. The trick is to see software development not as the realization of system technology, but as the integration of people’s knowledge. Reuse must focus on the value of important decisions, instead of treating (source) code as the main business asset. I am currently working on my Phd research on a multi domain specification method, where we specify a system in terms of multiple domain models (or DSLs). It includes the specification of domain models, making other models with domain models, and integrate those. Integration includes composition, transformation, and correspondence between specifications.
In my daily work, I fulfill several roles: consultant for architecture issues, teaching architecture, requirements, and domain modeling, and be a personal coach for architects. Besides that, I am helping organizations with developing and maintaining software systems in a faster, more predictable way, by automating development activities. This can be approached bottom-up, starting with the developer, and top-down from the business goals and architecture, and from the development process. So, MDD in all its forms.
Great to have your input here. Also looking to read about using multiple languages and integrating them. The largest I’m aware of has 24 different languages for different type of users (developers, hw, safety, testing, feature planning etc). Let me know if there is something to read.
welcome to the group. In my own project, i realized that effectively my language was a collection of domain specific languages: one for asset management, one for describing extended arithmetic, one for page layout, one for drawing, one for event management, one for finite state machines, and one for regular expressions. So every graphical interactive product built relies one these same DSL’s, and in most older languages the author builds their own DSL with their low level layer.
The goal of my research was to find a modeling language specific enough that the specification could be executed and thus merging the specification and implementation process into one step. A lot of the UML modeling systems that have been used lack specificity in regards to layout and appearance, and with the huge variety of screen sizes being used, there is now more effort taken to specify appearance than the underlying logic. I would venture to estimate that layout + drawing is now 70% of the work of building a product, and that the computation part is actually easier because it has no visual representation to fuss over.
Thanks
If layout is your major domain, then I guess that should be the central DSL where other DSLs are connecting to. Or, the other domains are not normalized/abstracted enough to generate the layout.
I mean, it would be weird that the layout of a UI is determined directly, i.e., there is no abstraction in between, by the information that is displayed and controlled via the UI.
If would say whether 70% of the work is layout totally depends on the type of product.
@CodingFiend
Thanks. O i see, you are the same same Beadslang guy. I did not recognize your user name here. Yeah i had already visited your site and was also present in the last community presentation of yours. It’s quite interesting. I may join your language community too some day sooner.
Glad to meet you. Most of my current work is on how to mange the reuse of things that have been written. Mostly this applies to source code but also applies to other text items.
HI Pinetreejoe
I am trying to establish a method that focuses on reusing decisions, instead of artefacts like source code. I think current practices focuses too much on reusing artefacts, especially source code, while the effort/cost is in the decisions that led to the artefacts. Main issues that source code is the result of many decision, and in many cases 90% of the decisions are reusable. But those decisions are extractable from a piece of source code, which makes that source code not-reusable in such a case. The link to domain specific is that decisions are more easy to make if you can make them in your own language and you are not forced to make them in combination with all kinds of other decisions. )I know this might seem a bit too philosophical, but it is not that difficult to come up with concrete examples).