CDM Code Generators - do you use them?

[chrisisla]

Members of the CDM Technology Architecture Working Group (TAWG) are currently in the process of migrating the CDM build process from codefresh to github actions. As part of the process we are reviewing the actions currently performed with a view to making improvements to the workflow in the future.

As part of the build the code generators are executed. There are 10 code generators whose artefacts are then deployed as part of each build. The generators are for:

1. Daml
2. Scala
3. CSharp8
4. CSharp9
5. Typescript
6. Go
7. Kotlin
8. Python
9. Excel
10. JSON Schema

The TAWG would like some feedback on the following aspects of the currently supported code generators:

• Which of these generators are you using the generated code from?
• In what capacity is the code being used e.g. for proof of concept, UAT, benchmarking?
• Is the functionality of the code generators sufficient? For example, the Python generator does not support Functions, does this prevent you using the generator?

Please add any comment that you may have to this discussion. If you are able to then please provide as much detail on the content and coverage of the code generators as you can

Please provide feedback by EOD Friday June 7th.

[minesh-s-patel]

Sorry for the late response to this @chrisisla.

There are 3 categories of code generators:

1. Fully functional Languages (including types, enums and functions)
2. Partially functional Languages (Just types and enums)
3. Data Modelling/Textual languages

Splitting the list up:

• Fully functional Languages
  • Java
  • Python
• Partially functional Languages
  • Daml
  • Scala
  • CSharp8
  • CSharp9
  • Typescript
  • Go
  • Kotlin
• Data Modelling/Textual languages
• Excel
• JSON Schema

To me - it makes sense to keep the Fully functional and Data Modelling/Textual languages in the CDM. The Partially functional languages support can be dropped - assuming they are not used.

The possible exception is the Typescript distribution which is useful for UI development.

[chrisisla]

At the TAWG meeting on 13 June, it was agreed that support for the following code generators was required:

• Java
• Python
• Daml
• Typescript
• Kotlin
• Excel
• JSON Schema

Scala may also be required by an ISDA member, which needs to confirm.

The next step will be for participants who actively use the artefacts built by these code generators to commit to providing assistance and support for the code generators to the rest of the community. If volunteers for a particular generator are not found then that generator will also be deprecated.

I will email the CDM lists and point to this discussion.

If you are willing to commit to assist the community by supporting a code generator then please add a comment to this discussion stating the generator you would like to support.

[eelramy]

On SG side we will need the CSharp9 code generator.

[chrisisla]

The following table shows the Code Generators along with who will be the first line of support for them going forward. Please note that going forward it will be the collective responsibility of the community to support the generators.

Language	Fully functional	Partially functional	Modelling/Textual	Assignee
CSharp9		Y		SocGen
Daml		Y		ISLA
Excel			Y	ISDA
Java	Y			REGnosys
JSON Schema			Y	ISLA
Kotlin		Y		ISDA
Python	Y			FTAdvisory / TradeHeader
Typescript		Y		ISDA

No support has been offered for the following code generators and so they will be deprecated:

• CSharp8
• Go
• Scala

Note

Deprecating a code generator just means that it will no longer be run as part
of the CDM build process. Should support for a deprecated language be required
at a later date then it can be reinstated.

If you have any questions or concerns about the details presented here than please add a comment. Alternatively you can attend the Technology Architecture Working Group and raise them.

If there are no objections raised then the proposed changes listed above will be implemented.