Why APF

Posted on by

Why APF?

Existing attempts in Automatic Programming field have been through Code Generators, Domain Specific Languages (DSL), and Language Workbenches.

  • Problem with Code Generators :

    You have to use ‘a different’ code generator for every domain. This makes automation very limited. Soon when using a Code Generator, you realize that you must write rest of the code by yourself. So for example if you are auto coding a video game software using some popular game code generator, you easily saved lots of time. But now you wanted this video game to do some serious database handling, but this video game code generator isn’t as powerful as a separate code generator which specializes in code generation for database management. Even if you use a database management code generator, you cannot fuse the code generated by these 2 generators together. Hence the limited automation

  • Drawbacks of DSL :

    Like Code Generators, DSLs have similar problem. Two DSLs developed by 2 different organizations may not automatically integrate together. Though DSLs are better than Code Generators as you don’t have to learn a generic programming language (such as C++, or .NET) to make your game. Rather the reserved keywords of DSL are named in such an easy manner that if you know the domain (say ‘game programming concepts’ such as collision detection), you will find the Domain Specific Language familiar – and easy to grasp. But thats still not as simple as APF which lets you type requirements of your software in plain english (with sentences and punctuation) & build your software

  • Drawbacks of Language Workbenches :
    Language Workbenches produce Domain Specific Languages. Learning curve is significant if you want to create new DSL. Learning curve is also involved in using a DSL because each DSL has a fresh new naming of reserved keywords. You cannot build software by typing simple to understand English sentences. Also, DSL programming is done typically for larger domains (such as voice synthesis, database management) than for niche domains (such as ‘windows registry manipulation’ or ‘common calculations in dentistry’ or ‘common functions in internet marketing’) because creating a dedicated programming language rich with reserved keywords may not make sense for a domain is small & requires only half a dozen functions. Vacuum of lots of such niche domains results in a limited automation, with reasonable chances that you will need to code rest portion of your code on your own by using generic programming language

How is APF different :

  1. Less Learning curve for programmers: learning curve may be less for programmers because a brief page explains them how their code can become auto integrateable.
  2. Less Learning curve for power users: no need to learn reserved keywords to program your software. Describe your software in plain English like in a demonstration here and auto code your software
  3. Support for niche domains: Because converting even a slightest snippet of code into auto integrateable code is easy, and APF accepts contribution from anyone and everyone in its central repository (with loose moderation but tight ratings), hence APF has more chances to auto code niche functions such as ‘windows registry manipulations, or common dentistry functions, or any other function which are rare in domain specific languages or code generator packages