In this example it might not be so practical, but in calculang everything is a function including constants.
This is because of an emphasis on flexibility. They're a constant here but in another calculang model I can call calculations from this same code while asking for specific pieces of the calculation to be different.
e.g. if I have a population growth assumption then in an exercise I can get all these numbers allowing for population growth - without myself touching these formulas. Population then depends on time and must be a function.
On calculang.dev I say that formulas (functions) are the building blocks of calculations, and they're the mechanism for flexibility (also transparency).
To get my editor component and compiler interacting with that reactive system it got a little messy, and I'll review and hopefully fix it before I push this to a wider calculang playground. Hopefully it's my own bugs that I can fix anyways.
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.
I like your conviction Re "functional programming is very easy to grasp".
Many won't but I agree in the purest (sorry) sense.
There is no scattered changing state. I think we all learned input-function-output as a construct in maths class?
Spreadsheets (sans-VBA) is arguably the most prolific programming language and simplest, being used by people who do not recognise they are programming. Felienne Hermans gave a good talk on this subject in GOTO 2016.
Spreadsheets have numerous shortfalls though, and "real" functional programming languages make it difficult to not feel intimidated: in my experience, but this is getting much better.
[1] is a game of life in calculang, functional language I'm developing, where for all it's verbosity at least I hope the rules and development over generation (g) can be reasoned with (sans-state!).
Not very practical but can show calculang computation/workings as it progresses and as parameters change - things that are easy for FP and otherwise intractable, and which further help with reasoning.
But, a big challenge is to be approachable (not intimidating), and I'm trying to make that better. I think it helps enormously to be focused on numbers as calculang is, and not general programming.
You mentioned that you went to some length to implement pivots. How far do you think you will take the pivot feature and UI?
For financial type usecases it's pretty much a requirement to be able to map many fields on X/Y, be able to collapse them in the the browser, and also show/control aggregations.
Asking because many apps stop at the simplest level of pivot features and go to great lengths in other areas like more advanced visualization.
For mapping many fields though, I think a good pivot table UI is like a secret weapon.
I get that this isn't what you would focus on so much in week 1.
Right - I used to work in GS and they had this really great internal table display tool where you could simply drag a column from the top to the left side and it would Pivot + Collapse all fields on it (plus allow multi level pivots). Then, you could look at the Pivot table OR do a drill-down to see the root-cause why a value was so high.
I really liked that interface and haven't really found anything near as useable yet. Perspective JS (a free library by JP Morgan, you can try it here: https://perspective.finos.org/block/) has some really cool functionality in this direction but it has its one data processing engine, query language, rendering engine etc so we couldn't have used that for this project.
But, this is an interesting thought - I definitely would want to see this functionality in Pretzel - the only question is how to prioritize this. If you know of any performant table libraries that support collapsible pivots out-of-the-box, I'd love to integrate that. Alternatively, we'll write our own!
One that I'm watching is the Table mark in Graphic Walker [1].
There is a license thing about logos to note if you do use it in Pretzel [2].
On GW [1], Create Dataset -> Public Datasets -> Student Performance then change the Mark Type to Table you can play around. It hits the things that I mentioned pretty good! You might have similar issues as you have with Perspective though.
I make calculang [3] and I'm getting ready to plug into a lot of things. A good pivot table generalizes well for my needs (mainly quick feedback during DX).
Perspective is on the list but so is GW and Pretzel.
Perspective might suit my needs perfectly.
But I like DuckDB-WASM approach anyway so I hope you continue and I hope you nail it one way or another! :)
Very impressive project and vision! Love the demo!
I am also ex-GS and worked on what I am fairly sure is the table display tool you're describing. I tried to carry the essential aspects of that work (multi-level pivots, with drill-down to the leaf level, and all interactive events and analytics supported by db queries) to Tad (https://www.tadviewer.com/, https://github.com/antonycourtney/tad), another open source project powered by DuckDb.
An embeddable version of Tad, powered by DuckDb WASM, is used as the results viewer in the MotherDuck Web UI (https://app.motherduck.com/).
If you're interested in embedding Tad in Pretzel, or leveraging pieces of it in your work, or collaborating on other aspects of DuckDb WASM powered UIs, please get in touch!
Yes! I think it was TDS viewer or something like it - I loved using it so thank you for building it :)
Tad viewer looks perfect for embedding in Pretzel! Is it easy to embed it in web apps? I’m on mobile right now and did a quick search and didn’t find anything. I’ll definitely be in touch!
Yes, Tad should be pretty easy to embed -- in the github repo there's a React component (TadViewerPane), and a fairly modular API for adding a new data source. I'm happy to work with you on this, this should be a fun exercise!
I followed LFS and BLFS instructions verbatim when I was a kid with so much time on my hands.
Enormously informative and also empowering to get from source code to a complex usable system and to be aware of every package.
Even just skimming the passages about security and other bits now, this is still an epic resource to get real grounded knowledge about pieces of the complex systems I can merely use nowadays.
This and doing stage 0 Gentoo install, which subsequently broke in interesting ways on running emerge. Fixing that was probably what got me enough 'real world' skill to be able to do it for a living.. 20 years later, here we are. Still grateful for the ricing :)
Same here. But looking back, it also shows the limitations of a modern desktop OS: there's too many big, complex components, all with intricate interactions, to set it up manually. Because -let's be honest- (B)LFS is a great learning resource, but a totally impractical way to get an OS up & running.
Automation is key here. Check dependencies, download archive(s), unpack, apply config options, compile, run tests, (optionally) build binary package, install: it all has to be automated or it quickly becomes unworkable.
I'd love to see more built-from-scratch OSes that include development tools, do something useful on modern hardware, but are small(er) to the point that it's easier to wrap one's head around the whole. Think Forth-based with a simple GUI, Oberon, Plan 9, Inferno or similar.
You're very kind! I'm a big believer in writing you can really lose yourself in, and try and achieve that with interactivity and visuals. The aesthetics of my posts is very important to me.
