- 30 Jun 2016 10:22:48 pm
- Last edited by shkaboinka on 01 Jul 2016 09:47:35 am; edited 1 time in total
well, to sum it up, I'm talking about using regular old programming abstractions in place of language abstractions to generate an output program. This frees one from rigid language barriers.
Based on what you said, perhaps LLVM does similarly; but I'm guessing it's still about writing a grammar for which some source code must be specified (confined) within.
I argued that plain programming abstractions form a grammar of their own, but in an organic way (e.g. the very act of programming results in a custom grammar relevant to the task at hand, with words like "account" and "sendPayment"). This kind of "grammar" is not something separate from the code, so they take whatever form is meaningful as needed.
It's my assumption that a DSL does not quite provide the same utility, because you still have to specify a grammar separately from the code that code must adhere to. But perhaps if there is a more dynamic link between the two (e.g. your code can specify ad-hoc grammar rules directly amidst the code that uses them), then maybe that achieves the same thing I am after. Still though, I figure that if you have to say that XYZ(foo) translates into code ABC(bar,baz), then you may as well just write a function that takes arguments (foo) and returns the thing to generate (the AST node for ABC(bar,baz)).
I did start this thread in a different place than i ended up, and perhaps that needs to be reconciled:
There are lots of layers of building / generating / testing / etc. even on the "outside" of the actual code for the software product, and it all may as well be replaced with one program to do it all (because, arguably, that's what it all is). WiX (Windows Installer Xml) is a great example where a library would have been better than a language, especially since it's so incongruent to what actually gets generated by it. ... then I took this idea even further to say that even the source code for the actual product is just another layer within the grand specification of what to generate and what to do with the generated artifacts, so why not just one program to do it all?
Part of the utility comes in being able to specify parameters in one common code that affects how everything else (your the code, the databases, the service contracts, etc.) should jointly be affected (e.g. putting an $Environment token in each code, buy instead of running some build script to "replace" on everything, this token is a resolvable variable within one giant common program).
One other thing to reiterate is that I'm not so concerned with providing a grammar / DSL over TOP of an otherwise unchanging base layer (e.g. a program that gets translated to Java, still has the same limitations as Java), but moreso about replacing that hard-wired base (language) with a flexible layer of composable programming abstractions that you build up / customize as part of the source code (yours or via library). I still want to use the generating patterns and abstractions provided by languages, but in an ad-hoc manner. Sort of like COLA, though that does it via grammars (but as stated, maybe that's ok if it's dynamic/ad-hoc enough).
Based on what you said, perhaps LLVM does similarly; but I'm guessing it's still about writing a grammar for which some source code must be specified (confined) within.
I argued that plain programming abstractions form a grammar of their own, but in an organic way (e.g. the very act of programming results in a custom grammar relevant to the task at hand, with words like "account" and "sendPayment"). This kind of "grammar" is not something separate from the code, so they take whatever form is meaningful as needed.
It's my assumption that a DSL does not quite provide the same utility, because you still have to specify a grammar separately from the code that code must adhere to. But perhaps if there is a more dynamic link between the two (e.g. your code can specify ad-hoc grammar rules directly amidst the code that uses them), then maybe that achieves the same thing I am after. Still though, I figure that if you have to say that XYZ(foo) translates into code ABC(bar,baz), then you may as well just write a function that takes arguments (foo) and returns the thing to generate (the AST node for ABC(bar,baz)).
I did start this thread in a different place than i ended up, and perhaps that needs to be reconciled:
There are lots of layers of building / generating / testing / etc. even on the "outside" of the actual code for the software product, and it all may as well be replaced with one program to do it all (because, arguably, that's what it all is). WiX (Windows Installer Xml) is a great example where a library would have been better than a language, especially since it's so incongruent to what actually gets generated by it. ... then I took this idea even further to say that even the source code for the actual product is just another layer within the grand specification of what to generate and what to do with the generated artifacts, so why not just one program to do it all?
Part of the utility comes in being able to specify parameters in one common code that affects how everything else (your the code, the databases, the service contracts, etc.) should jointly be affected (e.g. putting an $Environment token in each code, buy instead of running some build script to "replace" on everything, this token is a resolvable variable within one giant common program).
One other thing to reiterate is that I'm not so concerned with providing a grammar / DSL over TOP of an otherwise unchanging base layer (e.g. a program that gets translated to Java, still has the same limitations as Java), but moreso about replacing that hard-wired base (language) with a flexible layer of composable programming abstractions that you build up / customize as part of the source code (yours or via library). I still want to use the generating patterns and abstractions provided by languages, but in an ad-hoc manner. Sort of like COLA, though that does it via grammars (but as stated, maybe that's ok if it's dynamic/ad-hoc enough).