- J
--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.
Visit this group at http://groups.google.com/group/augmented-programming.
For more options, visit https://groups.google.com/groups/opt_out.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-programming+unsub...@googlegroups.com.
> The best approach for programming in the large is to focus on composition before all else, even before correctness. I mean composition in a formal sense.
Composition is easy if you're willing to sacrifice correctness :).
we're never going to find a fixed set of compositional operators that works (even "well enough") for all projects
Programming-in-the-large should be about choosing or building a framework of abstractions that allows the kinds of composition that are appropriate for the problem domain.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
DSLs can be useful, but more of a good thing isn't always better. DSLs can become translation barriers between subsystems, requiring widespread interpreters, hindering reuse, integration, and metaprogramming. Productivity and scale can be hurt.
Somewhere between domain specific and general purpose we can find sweet spot languages that are good for common "classes" of problems. Examples include relational calculus, linear algebra, constraint models, tuple spaces. We should find these.
But I think there aren't so many of them that making DSLs easier to build will necessarily pay for itself. Especially not if the result, in practice, is a bunch of poorly designed DSLs.
It's true that DSL's can be a hindrance but I believe that is due to two factors: they are expensive to make and they are difficult to make well. But it is my hypothesis that neither of these issues necessarily needs to be true
at each increase in the level of abstraction we have seen dramatic improvements in scale and productivity
The lower the level of abstraction a programmer has to deal with the more time consuming it is.
In modern programming the highest level of abstraction really available to you is a class (or component or something similar) and to express a design pattern you, a lot of times need many classes. When you then go to change or add to the application it can be quite time consuming to understand all of the classes needed to implement the pattern and even more time consuming to know what not to do.
No matter how terse your language is, no matter whether you like curly brackets or not, if you don't have the ability to add syntactic abstractions in your language you are not fundamentally that much more awesomer than all of the other general purpose languages that came before you.
Pattern matching seems to be the glue that will bind it all together.
This is a grammar file [..] The interesting thing about it is that it has "inheritance" [..] to parse statements and expressions for free you can simply inherit from LangParser and modify its grammar rules as you see fit.
Additionally you can add metadata to your rules and use that metadata to generate language services for tools for almost free:
there are still new ideas in the world of dsl's and new avenues to experiment with, please don't disregard it just yet.
I humbly and respectfully, completely disagree with you :)
It's true that DSL's can be a hindrance but I believe that is due to two factors: they are expensive to make and they are difficult to makewell. But it is my hypothesis that neither of these issues necessarily needs to be true and if both of these limitations were removed it would usher in a new age of software development.
the host also interferes by imposing its own metamodel on the DSL
In a general purpose programming language I don't think you have sufficient flexibility in adding levels of meta for this. In general you have a metametamodel defined by the compiler, your metamodel defined by the types, and lastly the runtime model.
I imagine something like model-binding (as used in angularjs and such frameworks), but across many more models in various directions [..] a live system in which you can execute something like DDL-scripts to transform and extend models and model derivations. Only much more flexible in what kinds of models can be expressed.
Indeed. I really hope we aren’t programming in ASCII text files in the year 2100.
On Nov 2, 2013, at 6:10 PM, John Nilsson <jo...@milsson.nu> wrote:
> Yeah, I should have been more clear about that. I do agree fully that there has to be interference from the host language. I'm just saying that the host language should be especially designed to be a host language, and be very picky about exactly what semantics it choose to impose on it's hosted models. Most importantly it should allow for adding and composing such semantics into sub-hosts.
>
> Also I think many languages fight to much with problems relating to limitations of their representation as streams of text as primary interface to be a fertile ground for innovation in this area. Instead it would be interesting to handle even the editing interface as pluggable metamodels.
>
>
> On Sun, Nov 3, 2013 at 1:47 AM, David Barbour <dmba...@gmail.com> wrote:
> On Sat, Nov 2, 2013 at 4:50 PM, John Nilsson <jo...@milsson.nu> wrote:
> the host also interferes by imposing its own metamodel on the DSL
>
> Interference can be a good thing, when it takes the form of "guidance" rather than "obstacles". DSL developers wish to focus on their own domain, and don't want to think about interop. I believe guidance from the host language - i.e. to force developers to address interop concerns (composition, extension, update, concurrency) - will be essential if we are ever to adequately support DSLs. But we also need to find better metamodels than procedural abstraction.
>
>
> In a general purpose programming language I don't think you have sufficient flexibility in adding levels of meta for this. In general you have a metametamodel defined by the compiler, your metamodel defined by the types, and lastly the runtime model.
>
> General purpose programming languages can be very flexible, much more so than Java and Haskell.
>
> Historically, we sacrificed a lot of flexibility in the name of reasoning: e.g. structured programming, lexical scope. These days, we have the tools to reason about code without losing flexibility: e.g. dependent types, substructural types, first-class continuations instead of gotos.
>
> I find concatenative languages (Forth, Factor, PostScript, etc.) especially fascinating due to their ability to absorb so many paradigms and metamodels while keeping such a simple syntax and base semantics.
>
> Best,
>
> Dave
>
>
> --
> You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to augmented-programming+unsub...@googlegroups.com.
> To post to this group, send email to augmented-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/augmented-programming.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to augmented-programming+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-programming+unsub...@googlegroups.com.
To post to this group, send email to augmented-programming@googlegroups.com.