Even the most sophisticated parametric CAD systems are, fundamentally, glorified electronic drafting boards. In a traditional CAD system, the CAD model is the central thing, and any automation, intelligence, or programming are bolted on after the fact. The core definition of the drawing, shape, or entity is the internal CAD model.
In a KBE system, a language-based definition forms the core of your model. This language-based definition, embedded in a dynamic, general-purpose programming language, provides far more flexibility and control than a CAD vendor-specific internal CAD model ever could.
The ramp-up time to establish an initial model may be a bit longer than sketching something interactively in a CAD system. But that investment will pay back dividends over the long term while your model and application continue to evolve and grow. Your model definition will also exist in a plain-text format, impervious to changes in computing platforms and complex CAD systems over the years, compilable by a free, open-source system.
First of all, the commonly spouted characteristics of Lisp, and Common Lisp in particular, are largely inaccurate.
And most of all, the homoiconicity inherent in Lisp makes it the natural choice for creating a dynamic, declarative definition languages (essentially an attribute grammar) which is the de-facto standard means of representing the "Knowledge" in a KBE system.
Most of the complaints about Lisp have to do with its historically high learning curve, both for the language and the Development Environments used to work in it (e.g. Gnu Emacs). Genworks works constantly to lower this learning curve and eliminate the need to become an expert in all the esoteric corners of Lisp programming in order to capitalize on its unmatched power. Even the creator of another KBE system based on a non-Lisp language admits that "Lisp is a nice(r) language."
The distinction is essentially one of licensing terms.
Gendl refers to the AGPL-licensed open-source project hosted here, and any distributions based on this codebase not otherwise licensed with an AGPL Exception. By downloading and using any version of Gendl (in source code form or prebuilt), you implicitly agree to follow the terms of the AGPL, which generally means that if you distribute your application, you are bound to distribute your own application source code under a license compatible with AGPL. The simplest way to achieve this is to distribute your application source code (to the same distributees) under the AGPL itself.
Genworks GDL refers to any commercially, proprietarily licensed distribution of the Genworks software, which can consist of the Gendl codebase by itself, or the Gendl codebase combined with other components and services. Such distributions include some sort of exception to the AGPL restrictions, allowing proprietary (i.e. closed-source) usage and distribution. The full commercial Genworks GDL suite inherently includes such an exception and allows proprietary (closed-source) distribution of your applications in exchange for a fee or royalty arrangement. Typically, a full Genworks GDL package includes other add-on components and services as well, including:
Genworks Technical Support. Support is typically unlimited, and paid via an annual support fee.
Exception to AGPL License. This Exception allows you to distribute and/or host your application without divulging your application source code (as is normally required by AGPL).
Access to turnkey distribution with prebuilt Genworks GDL executable image and Gnu Emacs-based Integrated Development Environment.
In summary, the distinction between Gendl and Genworks GDL is inherently one of licensing level rather than any technical differences in software.
A few reasons:
By using a "copyleft" license which requires users of the free system to distribute their application source code, we hope to foster a growing ecosystem of Gendl demonstration applications and add-on tools and high- and low-level primitives.
We want to encourage and retain a vibrant Common Lisp based KBE kernel, and avoid uncontrolled fragmentation into proprietary/commercial forks translated into different languages (such as Java or Python), as has happened with several prominent Lisp applications over the years. If you have a desire to make a deep study of Gendl, then implement a similar capability in a different language platform without complying fully with the AGPL, then please do contact us and we will be happy to discuss working out an arrangement.
While we heartily encourage free use of AGPL Gendl, and we understand the Gnu principle of Copyleft, we also realize that a large subset of potential users have no option to release their application source code, or to put themselves at risk of being coerced to release it. Since the 1980's, many Fortune 500 manufacuring companies have encoded their "corporate jewels" of knowledge into KBE systems such as ICAD and Genworks GDL, and this is by its very nature proprietary and very much trade-secret information.
We certainly do not want such entities to have to eliminate Gendl from consideration for their use because of AGPL license requirements. So this is one of the big reasons we make AGPL exceptions readily available, in the form of Genworks GDL.
Furthermore, the Gendl codebase is an asset which represents work and development by Genworks over the past 20 years. We want to retain the ability to sell and earn money from AGPL exceptions (usually as an inherent part of commercial Genworks GDL) in order to help continue funding full-time development on Gendl, eventually making Gendl (and applications of Gendl) into Common Lisp's definitive "killer application."