Difference between revisions of "STATOR:Establishing code-base"
Jump to navigation
Jump to search
Marek Trtik (talk | contribs) |
Marek Trtik (talk | contribs) |
||
| Line 11: | Line 11: | ||
* <b>cons</b> | * <b>cons</b> | ||
| − | ** | + | ** May slow down implementation of program analyses, symbolic manipulations of data structures may require more programming effort then in languages like OCaml or F#. |
=== F# === | === F# === | ||
| Line 18: | Line 18: | ||
** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...) | ** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...) | ||
** We can move to Windows and thus develop STATOR in Visual Studio. | ** We can move to Windows and thus develop STATOR in Visual Studio. | ||
| + | ** It is a modern language built on top of huge and established .NET platform. | ||
* <b>cons</b> | * <b>cons</b> | ||
** Not many people knows it, but the situation improves. | ** Not many people knows it, but the situation improves. | ||
** Development in Mono can be less comfortable. Also support of F# in Mono known to us yet. Similarly, state of standard library is not know. | ** Development in Mono can be less comfortable. Also support of F# in Mono known to us yet. Similarly, state of standard library is not know. | ||
| + | ** Portability mostly depends on qualities of Mono. | ||
=== OCaml === | === OCaml === | ||
| Line 27: | Line 29: | ||
* <b>pros</b> | * <b>pros</b> | ||
** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...) | ** May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...) | ||
| + | ** OCaml development environments are still immature and primitive | ||
* <b>cons</b> | * <b>cons</b> | ||
| Line 32: | Line 35: | ||
=== C++ === | === C++ === | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
* <b>pros</b> | * <b>pros</b> | ||
Revision as of 17:15, 25 July 2014
Here we list pros and cons of all our approaches towards establishing STATOR's code-base. All pros/cons are listed in the order from the most important to the least one. We further assign for all listed pros/cons a global "importance level", which is a number in [1,...,10].
Contents
Main implementation language
Java
- pros
- Many students know it
- Huge standard library
- There is of lot of program analyses related code written in Java. E.g. CPAchecker and Stanse already have established interfaces to CFG representations of programs.
- cons
- May slow down implementation of program analyses, symbolic manipulations of data structures may require more programming effort then in languages like OCaml or F#.
F#
- pros
- May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...)
- We can move to Windows and thus develop STATOR in Visual Studio.
- It is a modern language built on top of huge and established .NET platform.
- cons
- Not many people knows it, but the situation improves.
- Development in Mono can be less comfortable. Also support of F# in Mono known to us yet. Similarly, state of standard library is not know.
- Portability mostly depends on qualities of Mono.
OCaml
- pros
- May provide faster implementation of program analyses, because symbolic manipulations of particular data structures (like syntax trees, expressions, BDD,...)
- OCaml development environments are still immature and primitive
- cons
- Not many people knows it, but the situation improves.
C++
- pros
- a
- cons
- a
