GeneXus

GeneXus is a commercial, knowledge-based, declarative development tool created in Uruguay in 1988 by Breogán Gonda and Nicolás Jodal at Artech Consultores. Unlike a conventional programming language, GeneXus is best understood as a language plus a code generator: the developer describes business objects, attributes, rules, and transactions in a high-level declarative form, and the tool derives the database schema and generates source code in a target language — historically COBOL, later Visual Basic, C, Java, .NET, Ruby on Rails, JavaScript/Node.js, and native mobile platforms.

GeneXus has had a long and unusually consistent commercial life for a development tool of its era. The same conceptual model that Gonda and Jodal designed in the late 1980s — a knowledge base of business-object definitions from which the database and the application code are mechanically derived — is still the central idea of the modern product line.

History & Origins

GeneXus was created by Artech Consultores, a Uruguayan software firm founded in 1988 in Montevideo by Breogán Gonda and Nicolás Jodal. The first version of the tool generated COBOL applications and DB2 database schemas, targeting the mainframe and minicomputer enterprise environments that dominated business computing at the time.

The founding idea was that the database schema should not be designed by hand. Instead, the developer would describe the business in terms of objects (entities such as Customer, Invoice, Product) and attributes, and the tool would analyze those definitions, infer normalized relational tables, and generate the SQL DDL needed to create or reorganize the database. This separation between the declarative business description (the knowledge base) and the generated implementation (the database and the application code) is the defining feature of GeneXus and the source of its longevity: when a new target platform becomes important, the same knowledge base can be regenerated for that platform without re-describing the business.

Through the 1990s and 2000s, Artech extended GeneXus with generators for new platforms — Visual Basic and client/server architectures in the 1990s, Java and .NET in the early 2000s, mobile platforms in the 2010s — while keeping the declarative front end of the product largely stable.

In 2022, Globant, a publicly listed Latin American software company, announced the acquisition of GeneXus, bringing the long-running Uruguayan tool into a larger international software business while continuing the product line.

Design Philosophy

Several principles distinguish GeneXus from conventional programming languages:

• Declarative, not procedural at the top level. The primary unit of work in GeneXus is not a function or a class but a business object (a Transaction, a Procedure, a Data Provider, a Web Panel, and so on), each described declaratively.
• The knowledge base is the source of truth. The database schema, indexes, foreign-key constraints, and even the navigation between screens are derived from the knowledge base, not authored separately. When the developer changes an attribute’s type or adds a new entity, GeneXus computes the corresponding database reorganization.
• Generators decouple specification from platform. The same knowledge base can be generated as a Java application, a .NET application, or a mobile application. This is a deliberate hedge against platform change, motivated by the long lifetimes of enterprise business applications.
• A small procedural sub-language for rules and procedures. Inside the declarative shell, GeneXus exposes a procedural language with control flow, variables, and embedded SQL-like data access (for each, new, delete) that the developer uses to express business rules, validations, and batch logic.
• Automatic database reorganization. When the model changes, the tool generates the scripts needed to alter the existing database in place, attempting to preserve data — a non-trivial feature in a long-running enterprise application.

Language Overview

A GeneXus knowledge base is typically authored in the GeneXus IDE rather than as plain text files, but the procedural sub-language that lives inside Procedure and Transaction objects has a recognizable textual form.

A simple Procedure that lists customers might be written as:

For each Customer
    where CustomerStatus = 'A'
    order CustomerName
    print CustomerLine
EndFor

For each iterates over a logical entity from the knowledge base — not a hand-written SQL cursor. GeneXus’s specifier analyses the attributes referenced inside the loop (CustomerName, CustomerStatus) and generates the appropriate SELECT against the underlying tables, including joins inferred from the attribute relationships in the knowledge base.

A Transaction describes a business entity declaratively, with structure (attributes, subordinated levels), rules, and events. The developer writes rules such as:

Error('Invalid status') if CustomerStatus <> 'A' and CustomerStatus <> 'I';
Default(CustomerCreatedOn, &Today);

GeneXus uses these rules, together with the entity’s structure, to generate the screens, the database actions (insert/update/delete), and the integrity checks for the transaction.

The procedural sub-language inside Procedures and event handlers supports the familiar set of constructs — If/Else, Do While, For, variable declarations (&variable), and calls to other objects — but the data-access statements (For each, new, delete) are bound to the knowledge base rather than to literal SQL.

Generators and Targets

A defining feature of GeneXus is its generator architecture. Across the product’s history, target platforms have included (at various times and in various releases):

• COBOL — the original target on mainframe and minicomputer systems.
• C and Visual Basic — added during the 1990s for desktop and client/server applications.
• Java and .NET (C#) — added in the early 2000s, became the dominant targets for server-side applications in the 2010s.
• Ruby on Rails — supported during the late 2000s and early 2010s as a web target.
• Native mobile — generators for iOS (Swift/Objective-C) and Android, used to produce native mobile clients from the same knowledge base used for web back-ends.
• JavaScript / Node.js and modern web stacks — added in more recent releases to align with contemporary front-end and back-end development.

For any specific release, the authoritative source for which generators are available and which target versions they support is the GeneXus product documentation; this list is intended to convey the breadth of targets across the product’s history rather than the precise capabilities of any one version.

Architecture

A typical GeneXus development workflow has three phases:

1. Specification. The developer authors objects (Transactions, Procedures, Web Panels, Data Providers, etc.) in the IDE. The result is a knowledge base — a structured definition of the business model.
2. Specification analysis (“specify”). The tool analyzes the knowledge base for consistency and derives the implications of the model: which tables exist, which indexes are needed, which data-access patterns each object requires.
3. Generation and build. The tool generates source code in the target language and SQL DDL for the target database, compiles or packages the generated code, and applies any needed database reorganization.

This cycle is repeated each time the model changes. The promise of the tool is that the developer maintains the specification rather than the generated code; the generated source is treated as build output that is regenerated when the model changes.

Evolution

Across more than three decades of releases, GeneXus has evolved along several axes while preserving its core knowledge-base model:

• Target platforms have moved from COBOL on mainframes through Visual Basic and client/server architectures, to Java and .NET on web servers, to native mobile, to modern JavaScript stacks.
• User interface metaphors have shifted from character-mode forms to Windows GUI, to web pages, to responsive web and native mobile apps — each transition driven by changes to generators and runtime libraries rather than changes to the language.
• Database support has expanded from DB2 to a wide range of relational databases (Oracle, SQL Server, PostgreSQL, MySQL, and others) and, in more recent releases, to additional storage backends.
• Integration has added Web Services (SOAP and later REST), API generation, and integration with cloud services.
• AI-assisted development has appeared in recent releases, with the vendor positioning GeneXus as an environment that can incorporate model-driven and AI-assisted generation.

Through these changes, GeneXus has emphasized that existing knowledge bases continue to be usable across generator changes, a property valued by customers with decades of accumulated specification.

Current Relevance

GeneXus is a niche but commercially active product. Its strongest concentration of users has long been in Latin America — Uruguay, Argentina, Brazil, Mexico — where the tool was developed and where its vendor and partner network are densest. Beyond that region it is used by enterprise customers and ISVs around the world, though it does not have the mind-share among software engineers that general-purpose languages and frameworks do.

The acquisition by Globant in 2022 placed GeneXus inside a much larger international software services company, with the explicit aim of continuing the product line and expanding its reach.

Outside its installed base, GeneXus is not commonly chosen for greenfield projects by teams that prefer hand-written code in general-purpose languages backed by ORMs. Its niche is exactly the one it has occupied for more than thirty years: organizations that prefer to describe their business and let a tool generate and regenerate the implementation as platforms change.

Why It Matters

GeneXus is one of the longest-lived examples of knowledge-based, generator-driven development still in continuous commercial use. Where most code-generation and CASE tools of the late 1980s and 1990s — IEF, Texas Instruments’ Composer, various 4GL ecosystems — either disappeared or were absorbed into other product lines, GeneXus survived by treating generator output as a moving target: as platforms changed, the generators changed, but the knowledge base the customer authored did not.

The tool is also a useful case study in the trade-offs of model-driven development. The promise — describe the business once, generate the implementation for any platform — comes with real costs: a learning curve in the declarative model, opacity in the generated code, and a strong commitment to a single vendor’s toolchain. For organizations that accept those trade-offs, the payoff has been the ability to keep substantial business applications alive across multiple generations of database, operating system, and front-end technology, from 1988-era mainframe COBOL to modern mobile and web stacks, without re-describing the business each time.