PWCT: Programming Without Coding Technology
- Programming Without Coding Technology (PWCT) is a general-purpose visual programming language that eliminates manual text coding by using organized visual steps and reusable components.
- Its three-layer architecture—comprising a visual abstraction layer, middleware for code generation, and a system layer—integrates with standard programming toolchains.
- PWCT demonstrates high productivity and scalability in diverse applications from IoT to business systems, leading to the enhanced, cross-platform PWCT2 version.
Programming Without Coding Technology (PWCT) is a general-purpose visual programming language and development environment in which software is constructed without writing textual source code directly. In the PWCT literature, programming is performed by organizing visual “steps” in a hierarchical structure, selecting reusable components, and supplying parameters through interaction pages, while middleware generates source code in conventional languages and delegates compilation or interpretation to standard toolchains (Fayed et al., 2017). PWCT is presented not as an educational toy but as a general-purpose system intended for full-scale applications, including business information systems, IoT and cloud applications, and the implementation of other programming languages such as Supernova and Ring (Fayed, 2017).
1. Historical emergence and scope
PWCT was introduced against the background of a comparative study of ten visual programming languages—Scratch, Alice, Prograph, LabVIEW, Forms/3, VIPR, Limnor, Tersus, Envision, and Lava—evaluated using fifteen metrics and ninety-two subcriteria. That study distinguished domain-specific systems from general-purpose ones and emphasized requirements such as scalability, compatibility with textual ecosystems, multiple paradigms, compact representation, readability, portability, extension mechanisms, documentation, and support. PWCT was proposed as the system intended to satisfy those requirements while remaining open source and usable for large applications rather than only small scripts or educational exercises (Fayed, 2017).
A central historical claim in the PWCT literature is that many successful visual languages are domain-specific, whereas PWCT was designed as a general-purpose visual programming language. This positioning recurs in later work: the 2017 IoT and cloud paper describes PWCT as a visual programming tool for developing IoT, data computing, and cloud computing applications and systems without writing textual code directly, while the 2025 PWCT2 thesis frames PWCT as part of the relatively small class of general-purpose visual programming languages (Fayed et al., 2017, Fayed, 24 Sep 2025).
A nearby conceptual lineage is provided by “MyProLang - My Programming Language: A Template-Driven Automatic Natural Programming Language” (Bassil et al., 2012). That system does not use the acronym PWCT, but it combines GUI templates, an NLG engine, a source-to-source compiler, and an IDE to replace manual code writing with guided specification. This suggests that PWCT belongs to a broader family of systems that relocate programming away from manual syntax production and toward structured visual or natural-language interaction (Bassil et al., 2012).
2. Representation model and architectural organization
PWCT is described as a three-layer architecture. The VPL Abstract Layer contains the user-facing tools: the Goal/Module Designer, Components Browser, Interaction Pages, and Form Designer. The Middleware Layer interprets user actions, builds the internal representation, performs code matching and code masking, and emits textual source code. The System Layer hands the generated source to conventional compilers or interpreters and uses their standard runtimes (Fayed et al., 2017).
The core representation is the Steps Tree. In the 2017 IoT and cloud description, steps are instances of visual components with parameters and optional child steps, organized hierarchically to encode sequence, nesting, and modular structure; conceptually, the Steps Tree functions as the abstract syntax tree of the visual program (Fayed et al., 2017). In the later PWCT2 account, this tree-based representation is contrasted with node-and-wire visual notations: PWCT represents programs as a TreeView rather than a canvas of interconnected blocks, a choice motivated by the tendency of large graph-based programs to become “spaghetti” or a “maze of wires” (Fayed, 24 Sep 2025).
The basic editing unit is the component. Components are reusable, parameterized building blocks that correspond to declarations, control structures, GUI elements, database operations, networking actions, and other program behaviors. A programmer selects a component from the Components Browser, supplies its parameters through one or more Interaction Pages, and the environment then creates or updates the corresponding steps in the Steps Tree. In GUI-centric applications, the Form Designer complements this process by allowing windows and controls to be designed visually and then linked to event logic through components (Fayed et al., 2017).
PWCT’s earlier thesis formalizes this interaction pattern through Graphical Code Replacement (GCR). The idea is that what would normally be a textual instruction is re-expressed as a step label plus associated parameters. The visual source is therefore neither free-form text nor a graph of interlocked blocks, but a compact tree of semantically typed actions whose details are supplied through forms (Fayed, 2017).
3. Construction workflow, middleware, and code generation
The standard PWCT workflow proceeds in four stages. First, a goal or module is defined in the Goal/Module Designer. Second, components are chosen from the Components Browser. Third, each selected component is configured through Interaction Pages. Fourth, the middleware updates the Steps Tree and generates textual source code in the chosen target language (Fayed et al., 2017).
The Middleware Layer centers on the Step Generator and a database of Library Files. The Step Generator maintains the Steps Tree and traverses it to produce source code. For each step, the system consults templates and metadata stored in the library files, performs code matching and code masking, substitutes user-specified parameters, and writes the resulting source files. The 2017 PWCT paper reports target languages including C, C#, Harbour, and Python, while the thesis describes code generation for Harbour, C#, Java, and Python; taken together, these reports show that PWCT was designed around multi-backend generation rather than a single textual language (Fayed et al., 2017, Fayed, 2017).
At a lower implementation level, the thesis describes GCR through transporter files and tables such as InteractionPageTable, CodeMaskTable, and CodeMatchTable. Interaction-page values are loaded into temporary structures, matched to variables in the code mask, and then interpreted by a small directive language. Reported directives include <RPWI:TEST>, <RPWI:VALUE>, <RPWI:POSITIVE>, <RPWI:NEWSTEP>, <RPWI:INFORMATION>, <RPWI:PUTMARK>, <RPWI:SETMARK>, <RPWI:IGNORELAST>, <RPWI:NEWVAR>, <RPWI:SETVARVALUE>, <RPWI:SELECTVAR>, and <RPWI:REPLACEVARSWITHVALUES>. This mechanism generates both the visual step representation and the textual code associated with it (Fayed, 2017).
Execution is delegated to standard language ecosystems. For compiled targets such as C and C#, PWCT relies on the corresponding compiler and linker toolchains; for Python, execution proceeds through the usual interpreter and runtime model. PWCT therefore acts as a visual front-end and code generator rather than as a standalone runtime with a proprietary execution model (Fayed et al., 2017).
4. Expressive range, case studies, and reported productivity
The PWCT literature emphasizes applications intended to demonstrate that the system is general-purpose rather than narrowly pedagogical. Reported business case studies include a Projects Management Application for Riyadh Valley Company, a Production Follow-up Application for Al-Jabreen Leather Factory, a Courses Management Application for Izdehar Training Center, and a Multi-User Car Rental Management Application developed by a user in the Netherlands. These systems are described as multi-form, multi-user, client-server, and database-driven, with tested database backends including MS Access, SQL Server, and MySQL (Fayed, 2017).
Other cited applications broaden the scope. The thesis reports multimedia applications such as a movie player and audio player, networked applications such as a TCP/IP chat application and an SMS gateway interface using serial communication, and an algorithmic application for critical node detection in mobile ad hoc and sensor networks (Fayed, 2017). The IoT and cloud paper adds that PWCT has been used for IoT-related research tools, cloud and data computing applications, business systems, and even “Entire programming languages and their virtual machines (Supernova, Ring)” (Fayed et al., 2017).
The strongest expressiveness claim is the use of PWCT to implement programming languages themselves. The thesis documents PWCT-based implementations of Supernova and Ring, including screenshots of Ring VM and data-structure modules. The later PWCT2 work quantifies one such effort: the visual implementation of the Ring compiler and virtual machine in PWCT is reported as 43 visual source files, 18,945 components, 33,314 total steps (27,617 visible), generating 24,743 lines of ANSI C organized into modules such as scanner, parser, code generation, VM, and built-in functions (Fayed, 2017, Fayed, 24 Sep 2025).
Reported productivity and efficiency figures are a recurring part of the PWCT argument:
| Study | Reported PWCT figure | Comparison |
|---|---|---|
| 20 simple to intermediate applications | 106.66 s development time | 115.66 s for Visual Studio; PWCT reported as 8.5% less |
| 20 simple to intermediate applications | 4.52 MB memory usage | 12.124 MB for Tersus; 58.144 MB for Visual Studio |
| Large business application | 20,477 LOC, 96 source files, 26 forms, 7,616 steps | Visual Studio version: 20,606 LOC, 102 files, 32 forms |
| Large business application | ~2.94 hours interaction time | Visual Studio version: ~11.85 hours |
The 2017 experiment in the IoT and cloud paper involved five professional programmers, each expert in a different tool, who developed 20 simple to intermediate applications. PWCT was reported as the fastest environment in that comparison and the one with the lowest memory usage during development (Fayed et al., 2017). The thesis then reported a large-application comparison in which PWCT required approximately one quarter of the interaction time reported for the Visual Studio implementation of the Riyadh Valley Company application (Fayed, 2017).
Adoption evidence is also reported, although in different forms across sources. The IoT and cloud paper states that PWCT was ranked 3rd in the science and engineering category among approximately 300,000 projects on SourceForge, with more than 70,000 weekly downloads and a SourceForge satisfaction split of 93% “like” and 7% “unlike” (Fayed et al., 2017). The thesis reports more than 230,000 downloads for the language and more than 19,500,000 downloads for samples, tutorials, and movies, again with 93% positive user satisfaction (Fayed, 2017).
5. Conceptual position within visual, no-code, and low-code research
The low-code survey “Low-Code Programming Models” (Hirzel, 2022) defines low-code programming as programming that minimizes the use of textual programming languages and replaces them with techniques such as visual abstractions, demonstrations, or natural language. This suggests that PWCT occupies the visual programming language branch of the broader low-code landscape: the user does not manipulate a textual DSL directly, but the system still constructs a program behind the scenes (Hirzel, 2022).
Within that landscape, PWCT differs from several neighboring approaches. Educational block languages such as Scratch and Alice are discussed in the PWCT thesis chiefly as small-program or educational systems rather than as environments for large applications (Fayed, 2017). Domain-specific systems follow a different path. The ROS-compatible Blockly environment for Evarobot, for example, exposes ROS topics, publishers, subscribers, message fields, CMD_VEL, TELEOP, WANDER, and SET [PID](https://www.emergentmind.com/topics/geometric-partial-information-decomposition-pid) PARAMETERS as visual blocks, but it is explicitly oriented to mobile robot education and applications rather than general-purpose software development (Karaca et al., 2020). “Vanlearning: A Machine Learning SaaS Application for People Without Programming Backgrounds” (Wu, 2018) removes coding from a narrow family of tabular machine-learning workflows—upload, train, predict, download—through a click-based web interface, but it is not a general-purpose language. “Design of a visual environment for programming by direct data manipulation” (Adam et al., 4 Jun 2025) presents AlgoTouch as a Turing-complete visual environment that generates Python, C, C++, and Java from direct manipulation of variables and arrays; its emphasis, however, is algorithm learning through direct data manipulation rather than the component-and-steps model characteristic of PWCT.
A common misconception is that PWCT eliminates programming concepts altogether. The literature does not support that view. PWCT removes direct engagement with textual syntax, but the developer still works with modules, steps, variables, control structures, events, forms, and component hierarchies (Fayed et al., 2017). In this respect, PWCT is closer to high-level guided programming than to fully domain-specific no-code builders that hide almost all computational structure.
6. Limitations, redesign, and the transition to PWCT2
The PWCT2 thesis is explicit that sustained use of PWCT exposed several limitations. PWCT’s first generation was implemented in Visual FoxPro, making it Windows-only, 32-bit, and dependent on a no-longer-maintained platform. Visual files were large, disk writes were frequent, large source files could have long load and code-generation times, modified textual code could not be imported back into the visual environment, and the system was not self-hosting: improving PWCT itself required traditional textual programming outside PWCT (Fayed, 24 Sep 2025).
These issues motivated PWCT2, described as a dual-language (Arabic/English), general-purpose, self-hosting visual programming language built using the Ring textual language. PWCT2 is reported as cross-platform, Ring-centric, and able to convert Ring code into visual code through Ring2PWCT, thereby enabling a self-hosting workflow in which the visual system can be developed using itself. The environment contains approximately 92,000 lines of Ring code and 394 visual components (Fayed, 24 Sep 2025).
The reported quantitative improvements are substantial. PWCT2 provides approximately 36 times faster code generation and requires 20 times less storage for visual source files. The thesis gives the underlying ratios more precisely as about 36.7 times faster code generation per step and about 20.9 times less storage per step than PWCT (Fayed, 24 Sep 2025). The redesign also adds features such as a single main window with dockable panels, multiple visual source files in tabs, drag-and-drop within the Steps Tree, full find/replace, rich comments including HTML comments and images, a Time Machine with optional Auto-Run, and an enhanced MVC-based Form Designer (Fayed, 24 Sep 2025).
The same thesis also reports early usage data for PWCT2 on Steam. Since March 2023 it recorded approximately 1.72 million impressions, approximately 159,000 page visits, 20,623 owners, 1772 users who launched the software, an average usage time of 9 h 40 min, and more than 17,000 hours of total recorded usage. Among 31 analyzed user reviews, approximately 90% were positive, with 28 recommendations and 3 non-recommendations (Fayed, 24 Sep 2025).
PWCT2 does not remove all constraints. The thesis notes that PWCT2 currently supports only Ring, is not backward compatible with PWCT at the visual-file or component level, and still has open questions involving startup footprint, web deployment, integration with LLM-based workflows, and the learning curve for newcomers (Fayed, 24 Sep 2025). Even so, the evolution from PWCT to PWCT2 clarifies the long-term significance of the project: PWCT began as an effort to make general-purpose programming genuinely visual, and PWCT2 extends that effort toward self-hosting, dual-language support, cross-platform deployment, and bidirectional movement between visual and textual representations (Fayed, 24 Sep 2025).