译者序
不论是初次接触GeneXus，还是使用GeneXus很长时间，我们大家常常有一些疑问：在由欧美国家占绝对主导地位的软件领域，一个来自南美的小国-乌拉圭，竟然出了一个世界知名的软件公司？30多年几乎跨越软件发展史一半的时间，有多少公司来了又走了，又出现了多少种新的技术，可一家超过30年的软件公司却能够永葆青春，一直站立在软件行业的前沿。是什么能够让它做到这一点？它的产品为什么会是这样的？这与其它软件工具到底有哪些不同？相信我们能够通过本文获得答案。
另外，我这里也简单介绍乌拉圭这个南美小国的一些基本情况：
-
乌拉圭是一个夹在巴西与阿根廷两个南美大国之间的小国，是在两国互相争斗过程中产生的；
-
乌拉圭90%以上是由欧洲移民组成的，其中大部分为意大利人和德国人！这也使得乌拉圭人继承了意大利人创造能力及德国人的严谨风格，因此从另外一个角度看，乌拉圭更像一个欧洲国家；
-
乌拉圭是一个牛肉出口大国；
｜正文｜
1984 年，巴西的一家大公司委托我们对其 IT 进行全面重新设计。客户希望开发与公司中央数据库交互的所有系统。
挑战很大：当时大家都在谈论系统和企业数据库，但现实却大相径庭，所有企业都在继续使用多个“主题数据库”。每个主题数据库都用于支持一个小型应用程序系列。每个主题数据库的更新完全独立于其他主题数据库。因此，数据一致性是不可能的，没有合并来自不同主题数据库的数据。
简而言之：有一个在某些限制条件下运行的操作计算系统，但没有企业计算。
客户向我们提出了一个巨大的挑战：用一个单一的集中式数据库来满足他的所有需求。客户希望可以在任何时候都可以从该公司数据库中获取任何必要的信息。对必要资源似乎没有任何限制，但需要一年内完成所有的工作。
这项任务考验了我们的信念、我们的经验、我们的方法，并给我们带来了一系列额外的问题。当然啦，最后我们还是克服了所有障碍，项目顺利结束。
面对如此多的困难，让我们学到了很多东西，并鼓励我们继续前进。问题来了：我们是做更多类似的项目，还是构建属于自己的方法论和支持它的工具？
我们参与了不同公司的多个项目，同时我们也继续研究这个工具，最终在 1989 年推出了我们的第一个 GeneXus。直到今天，GeneXus已经推出了36年，随着时代发展，我们需要与时俱进对技术和业务发展等进行了一系列反思。
我们是一支非常优秀的团队，尽管世界各地有很多人谈论或撰写了很多关于企业计算的文章，但在该领域没有或至少很少取得成功的成就.
我们对目前行业所面临一系列问题的原因做了总结：
-
数据库
假设我们将获得该问题的适当解决方案，我们对所需数据库的初步估计表明需要 500 多个表。实际上我们的咨询工作达到了 750 个，我们想知道我们的方法是否能解决这么大的问题。为此，我们需要为许多重要问题找到答案，即：
-
开拓解决方案，我们的客户渴望他们的管理职位和/或他们的助手能够随时（在大多数情况下）解决他们的问题，而无需计算机专家的帮助。要应用的语言将是 SQL，其中对于大多数查询，关于应该从哪个表数据获取以及这些表应该如何相互组合的指令变得必要。
-
构建解决方案，如此庞大的数据库，我们该如何设计呢？我们是专家，我们对自己在该领域的丰富知识充满信心。在这方面，我们还为来自石油、金融、工业、政府和商业领域的许多大型巴西实体企业提供顾问服务。然而，他们都没有渴望大型企业数据库，也没有需要大量事务活动的高度复杂的数据库。他们都有几个主题数据库，每个数据库都有助于解决一小部分问题。
-
数据模型大小，在设计阶段，我们应该如何用超过 500 个表的数据模型进行推理？我们可以将它标准化，还是应该放弃这个想法？我们肯定会遇到许多人为错误，因此拥有工具来帮助我们将非常有益，但现实中不存在这样的工具！
-
知识来源
在获得或构建所需工具的情况下，我们还需要原材料来使它们工作。我们的原材料在各个层面上都非常严格地了解用户的现实情况（用户视图、业务规则等）。
但是，为了构建我们针对的 ER（实体关系）模型，我们在客户公司内有哪些人对来自不同对象的各种对象有必要的了解？实体以及它们之间的关系？
谁拥有客观性并能够提供所需的细节？......根本没有人。拥有帮助我们解决这些问题的工具将非常有益，但现实中不存在这样的工具！
-
系统维护
考虑到解决方案的规模，假设它是严格按照适当的开发方法构建的，那么一旦顾问的工作结束，会发生什么？是否会继续严格遵守该方法论？在诉诸文件时，获得的数据是否可靠、准确和最新？
用于构建解决方案的方法，随着时间的推移持续而精确地应用几乎是不可能的。除非该解决方案由作为指南的开发工具支持，以确保严格遵守相应规则。
解决方案准确而严谨的描述， 解决问题的答案随着时间的推移仍然有效，这要求我们以绝对准确和严谨的方式描述客户的现实。
知识来源，我们得出的结论是，知识的基本来源是在可靠的参考框架内表达的用户数据的视图，该框架也必须简单。
GeneXus 推断数据模型、数据库模式和应用程序。
-
人工智能
手动解决方案无法解决这样的问题，所以我们决定求助于人工智能。
我们对当时使用最广泛的两种人工智能语言进行了分析。对 LISP 和 PROLOG 的考虑导致了两种不同的立场：使用 LISP 是因为有多种语言处理器可供它使用，它也是使用最广泛和最古老的语言，而 PROLOG 是一种具有更高期望但使用不那么广泛并且可用的语言处理器很少的新语言。我们选择了 PROLOG， 随着时间的推移证明这确实是一个很好的决定。
人工智能作为一项非常有前途的技术出现。在许多公司，尤其是美国的公司当时都致力于利用AI技术开发专家系统，尤其是用于诊断目的专家系统。他们在开发这些系统的时候并不成功。在诊断中，例如 95% 到 97% 的可靠性平均值算是极好的值（在非常优秀的人类专家的情况下，该百分比较低）。然而，在构建大数据模型和系统时，这些数字都是灾难性的。
还有一件事：我们是具有扎实数学背景的计算机系统工程师，但我们对人工智能一无所知。
新世界，我们的问题把我们带到了一个全新的世界，一个纯知识的世界！
边做边学，当时我们似乎无法解决问题，但我们继续研究它并最终找到解决方案，我们实际上在边做边学中取得了更多的成就。这是跟上最新技术并立即应用新技术的方式，具有非常显著的好处。
准确性，我们所有人（在某种程度上参与了 GeneXus 概念和构建的研究人员）都需要对我们的活动应用非常高度的准确化，以便于严谨地表达每个纯数学和逻辑问题。
我们定义的每个规范都必须完全准确，并基于清晰可靠的参考框架：
-
表示所涉及的每个不同元素的含义，以便能够自动对其进行操作，采用一个基本规则——鉴于现实是一致的，那么我们对现实的所有表示也必须是一致的，并实现自动地使用功能强大的运算方法。
-
那么我们的用户呢？——开发人员。期望让他们持续工作是不现实的。我们必须隐藏工作的复杂性，允许开发人员以直接的方式工作，并尽可能简单地使用低抽象的特定元素。
-
纯知识
假设纯知识作为基线意味着避免诉诸任何可能会发生变化的物理或技术元素（随着时间的流逝，这将不可避免地发生）。必要的物理和/或技术元素被自动包含，并且仅在代码生成时包含。这种行为实现了高度抽象，完全独立于随机变量元素。
-
面向未来/用不落后的技术（Futureproofing）
知识存储在具有强大推理能力的知识库上以供操作。
GeneXus 推断数据模型、数据库模式和应用程序最重要的结果之一是，由于这些知识独立于所应用的技术，我们可能总是使用另一种技术设置自动生成一个应用系统。对于每种情况，我们必须简单地使用为所选技术配置提供支持的 GeneXus 版本。
也就是说，Future proofing 之所以起作用，是因为有了 GeneXus，系统可以在技术不断变化的发展引起的可能变化方面受到保护，无需手动重新编程！
-
自动维护和进化
另一个不太引人注目但同样重要的结果是系统的自动维护。GeneXus 的推理能力最初支持自动生成系统（数据库和程序），并且在发生变化时，它也会自动传播它们。
开发者只需要对发生变化的描述元素进行概念更新。GeneXus 将提供有关此类更改影响的报告，并且对于这些更改获得确认的情况下会自动传播它们。
-
系统集成
如今，无论规模和业务领域如何，世界上没有一家公司可以在自给自足的基础上运营。借助第三方的发现、经验和产品作为补充，变得越来越必要。
建议：促进与其他产品的最大集成，以最全面、最快速、最经济的方式解决影响客户的实际问题，避免开发需要购买的产品，考虑到所包含解决方案的质量，方案变得可用所需要时间，以及机会成本。
GeneXus 的集成能力在其最新版本中得到了显著增强。
总结与未来
我们将知识管理与技术管理分开。关于我们的技术，特别是关于自动使用纯知识的所有内容都可以总结为以下声明：
“我们使非常好的业务系统知识自动管理成为可能”。
但随着世界的发展，现在这种业务系统的极限在哪里？如今，最初处理许多不同活动的公司已决定作为软件公司工作并专注于所有这些领域。GeneXus 以严格和永久的方式表示知识，使其能够自动操作知识。什么样的知识？任何知识！我们必须努力工作，但没有限制！
这为发展提供了一扇敞开的大门：我们的客户将需要它，因为新类型应用程序的不断增加,使计算机系统变得越来越复杂。不断发展我们的智能开发平台来做到这一点需要一些时间和巨大的努力。
GeneXus 坚实的科学和技术基础将使我们能够逐步地继续构建任何必要的东西。
