Thanks for checking it out and for the comment! This surprised me, but you are right.
The only thing I can point to referring to this example only is that there is a lot of Javascript in the page, but the calculations are (effectively Javascript also but:) described separately, and this is still useful I'll argue -
Separation of concerns means we can easily first of all point to calculation logic, connect it to numbers where they are used, give some structure to it, build tools to generally interact with that structure (much simpler than with Javascript). calculang code is pure and has no side-effects (*supposed to), which means tools can safely re-run code and expect predictable output. I use a tool taking advantage of some of this in [1] a video exploring a calculang model for a raycasting algorithm in order to understand it and fix a thing. So, I said a lot of buzzwords but I do use these properties to experiment with different DX that is far more challenging to develop for Javascript or a programming language generally.
The calculations in How much is 13 Bn euros are almost trivial - I normally don't put in these types of hardcodes for example - and it does happen to be valid Javascript here. An example to see some technical properties of calculang itself is this (also simple) one: https://new-layout-2--finding-calculang-foc.netlify.app/shop
There are a few tabs in the top left. The first (default) tab is showing calculang code: a few formulas and a few inputs (inputs are denoted by a convention). All are implemented like functions, and there are a lot of function calls - but those brackets have nothing in them. This is because calculang tracks how inputs are used and populates brackets for you - something I call input inference (or input threading). In the second tab you'll see the calculang output.
So it looks like calculang helps you to write pure-functional calculation code in a concise way; by threading inputs through all the function calls automatically.
calculang also supports modularity and effectively lets you re-use one calculation and "overriding" some component calculation/s. In other words: calculang formulas are flexible. And this is the real motivation for calculang taking care of all that input threading: flexibility means it should be done differently in different contexts (even sensible within the same model - for example - "I want this calc with this change, I want the same calc but with this other change or no change, and I want the difference between the two").
The compiler takes care of input threading through some pretty simple graph logic - everything related to compilation is <1k lines in total. Effective modularity, flexibility, and re-use of course is useful for maintainability.
A recycling logo in the calculang.dev examples [2] indicates models which use modularity in some form.
Sorry for the long post. That really is about all the technical details I can mention - but I think separation of concerns takes it very far also - in terms of its goals (that are stated on top of calculang.dev).
With all due respect, if you are making calculang with the goal of creating a tool for others to use, you need to work on a concise and clear description of what calculang is and why it exists. I'm sorry but I still have no idea what it even fits into in the broadest categories of language, library, or conceptual framework. No disrespect intended, just sharing feedback if you're hoping to grow this product.
The only thing I can point to referring to this example only is that there is a lot of Javascript in the page, but the calculations are (effectively Javascript also but:) described separately, and this is still useful I'll argue -
Separation of concerns means we can easily first of all point to calculation logic, connect it to numbers where they are used, give some structure to it, build tools to generally interact with that structure (much simpler than with Javascript). calculang code is pure and has no side-effects (*supposed to), which means tools can safely re-run code and expect predictable output. I use a tool taking advantage of some of this in [1] a video exploring a calculang model for a raycasting algorithm in order to understand it and fix a thing. So, I said a lot of buzzwords but I do use these properties to experiment with different DX that is far more challenging to develop for Javascript or a programming language generally.
The calculations in How much is 13 Bn euros are almost trivial - I normally don't put in these types of hardcodes for example - and it does happen to be valid Javascript here. An example to see some technical properties of calculang itself is this (also simple) one: https://new-layout-2--finding-calculang-foc.netlify.app/shop
There are a few tabs in the top left. The first (default) tab is showing calculang code: a few formulas and a few inputs (inputs are denoted by a convention). All are implemented like functions, and there are a lot of function calls - but those brackets have nothing in them. This is because calculang tracks how inputs are used and populates brackets for you - something I call input inference (or input threading). In the second tab you'll see the calculang output.
So it looks like calculang helps you to write pure-functional calculation code in a concise way; by threading inputs through all the function calls automatically.
calculang also supports modularity and effectively lets you re-use one calculation and "overriding" some component calculation/s. In other words: calculang formulas are flexible. And this is the real motivation for calculang taking care of all that input threading: flexibility means it should be done differently in different contexts (even sensible within the same model - for example - "I want this calc with this change, I want the same calc but with this other change or no change, and I want the difference between the two").
The compiler takes care of input threading through some pretty simple graph logic - everything related to compilation is <1k lines in total. Effective modularity, flexibility, and re-use of course is useful for maintainability.
A recycling logo in the calculang.dev examples [2] indicates models which use modularity in some form.
Sorry for the long post. That really is about all the technical details I can mention - but I think separation of concerns takes it very far also - in terms of its goals (that are stated on top of calculang.dev).
[1] https://www.youtube.com/watch?v=hKVXRACCnqU
[2] https://calculang.dev/#examples