Declarative Programming winning examples Udi h Bauman, CloudLock 

Declarative Programming winning examples Udi h Bauman, CloudLock We’re hiring, check us out! 

Declarative Programming is a form of high-level programming: 

Declarative Programming is a form of high-level programming: telling your software what to do, instead of how to do it 

Some real-life patterns 1. “what”-metadata driven 2. high-level “what”-code 3. “how”-code abstracted away 

1. “what”-metadata driven ● problem: you have many behaviours that only differ in parameters or small variants of behaviour 

1. “what”-metadata driven ● problem: you have many behaviours that only differ in parameters or small variants of behaviour ● solution: write metadata & code that derives behaviour from metadata 

1. “what”-metadata driven ● problem: you have many behaviours that only differ in parameters or small variants of behaviour ● solution: write metadata & code that derives behaviour from metadata ● benefit: adding new behaviours now means just adding metadata, & in rare cases also overriding classes/functions 

Example: rollups aggregation 

Example: rollups aggregation 

2. high-level “what”-code ● problem: you have many behaviours that only differ in the “edges” 

2. high-level “what”-code ● problem: you have many behaviours that only differ in the “edges” ● old solution: using inheritance tricks such as template method &c 

2. high-level “what”-code ● problem: you have many behaviours that only differ in the “edges” ● newer solution: abstract the algorithm to declarative high-level code & “chain” the overriding behaviour 

2. high-level “what”-code ● problem: you have many behaviours that only differ in the “edges” ● newer solution: abstract the algorithm to declarative high-level code & “chain” the overriding behaviour ● benefit: see the big picture & just the relevant details 

Example: d3: data-driven documents 

Example: d3: data-driven documents 

3. “how”-code abstracted away ● problem: if some code addresses requirements that are obvious & not specific to your app, why should it be there? 

3. “how”-code abstracted away ● problem: if some code addresses requirements that are obvious & not specific to your app, why should it be there? ● solution: abstract that code in an underlying framework, either yours or someone’s else 

3. “how”-code abstracted away ● problem: if some code addresses requirements that are obvious & not specific to your app, why should it be there? ● solution: abstract that code in an underlying framework, either yours or someone’s else ● benefit: simple, small code just for the requirements specific to your app 

Example 1: 

Example 2: Meteor ● if a user is looking at a list of records, obviously when a new record is added, the user should see it ● & if he changes a record, obviously other users looking at it should see the modification ● so why should you implement this? 

Example 2: Meteor ● So what's declarative here? ○ You are left with just declarations: ■ What data the server publishes ■ What data the client subscribes to ■ What data is shown in the UI ● See this list of 8 open-source apps written in Meteor: http://meteorapps.co ○ Except for one they are all well written & worth learning from.. 

Thanks for listening. @dibau_naum_h