Modern relevance and use cases of PHP AI-pedia

A comprehensive examination of PHP's historical evolution, runtime architecture, modern type system, enterprise frameworks, hosting economics, and contemporary use cases across the global web.

4,721 words · about 21 minutes to read · revised 13 November 2026 · written with gemini-3.8-flash-tiered

🤖 Written by Wren, the chat's AI, building on Wikipedia and on questions people asked in the chat. AI writing can be wrong or out of date: check anything that matters with a reliable source.

At a glance
ParadigmMulti-paradigm: imperative, functional, object-oriented, procedural, reflective
Original designerRasmus Lerdorf
Core maintainersThe PHP Development Team, Zend Technologies, PHP Foundation
Initial release8 June 1995
Implementation languageC (primarily; some components in C++)
Typing disciplineDynamic, weak, gradual
Supported operating systemsUnix-like, Windows, macOS, IBM i, OpenVMS, IBM Z
Software licenseModified BSD License (PHP License)
File extensions.php, .phar, .phtml, .pht, .phps, .phpt
Official websitewww.php.net

PHP is an open-source, general-purpose scripting language engineered primarily for server-side web development. Conceived in 1993 by Danish-Canadian programmer Rasmus Lerdorf as a set of Common Gateway Interface (CGI) binaries written in C, the language was formally released to the public on 8 June 1995 under the name "Personal Home Page Tools". Over the following three decades, PHP shifted from a procedural page-templating utility into a mature, multi-paradigm programming language that supports object-oriented, imperative, functional, and reflective programming styles. Its name was subsequently adapted into a recursive backronym: "PHP: Hypertext Preprocessor".

The standard reference implementation of PHP is maintained by the PHP Development Team, Zend Technologies, and the PHP Foundation, an open-source collective established to fund full-time core engine developers. PHP executes within the Zend Engine, an execution environment written in C with components in C++. PHP code is typically delivered via file extensions such as .php, .phtml, or .phar (PHP Archive) and executes across diverse operating systems, including Linux, FreeBSD, macOS, Microsoft Windows, IBM i, OpenVMS, and IBM Z. Output generated by the interpreter—ranging from raw Hypertext Markup Language (HTML) and JavaScript Object Notation (JSON) payloads to binary media streams—forms the body of an HTTP response.

Despite competition from newer server-side technologies such as Node.js, Python, Go, and Ruby, PHP remains one of the most widely deployed programming languages in computing history. Telemetry from web technology monitoring firms routinely indicates that PHP powers over 70 percent of all websites with an identifiable server-side programming language. This sustained relevance is underpinned by fundamental performance overhauls in its virtual machine, the introduction of strict gradual typing, standardized component ecosystems, and its role as the foundation of dominant content management systems and high-throughput commerce platforms.

History and Architectural Evolution

The development of PHP is divided into distinct generational epochs, each defined by complete rewrites of the underlying execution engine, shifts in type philosophy, and adjustments to object-oriented programming conventions.

Early Versions and the Zend Engine (1993–2004)

PHP began as a personal utility created by Rasmus Lerdorf to monitor visits to his online curriculum vitae. In 1995, Lerdorf bundled these tools with a form interpreter to create PHP/FI (Personal Home Page / Form Interpreter) version 2.0. This early version was strictly procedural, lacked formal language grammar, and embedded basic conditional logic directly inside HTML files.

In 1997, Israeli developers Zeev Suraski and Andi Gutmans identified severe architectural limitations in PHP/FI 2.0 while developing an independent university e-commerce project. Rather than extending the existing codebase, Suraski and Gutmans rewrote the parser from scratch. This rewrite was published in June 1998 as PHP 3.0, introducing a modular extension architecture and establishing the recursive acronym "PHP: Hypertext Preprocessor".

Following the release of PHP 3.0, Suraski and Gutmans designed an entirely new execution runtime known as the Zend Engine (a portmanteau of "Zeev" and "Andi"). Zend Engine 1.0 served as the internal interpreter for PHP 4.0, released in May 2000. PHP 4 introduced an execution lifecycle where scripts were compiled into intermediate operational instructions, known as opcodes, before being executed. However, PHP 4 possessed an incomplete object-oriented model that copied objects by value during variable assignment rather than passing them by reference. This design frequently led to accidental memory duplication and unpredictable behavior.

In July 2004, PHP 5.0 was released, powered by Zend Engine 2.0. This release resolved the object-model limitations of its predecessor. PHP 5 introduced explicit access modifiers (public, private, and protected), abstract classes, formal interfaces, class destructors, static methods, and pass-by-reference object semantics. Later point releases introduced significant modernization: PHP 5.1 added the PHP Data Objects (PDO) database abstraction layer; PHP 5.3 introduced explicit namespaces, closures, and late static binding; and PHP 5.4 added traits, array dereferencing, and an integrated development web server.

The Unicode Crisis and the Abandonment of PHP 6

In 2005, the PHP community initiated the PHP 6.0 development branch, intended to provide native internationalization by encoding all internal strings as UTF-16 (16-bit Unicode Transformation Format). The project altered the core engine data structures to handle 16-bit characters natively.

This design choice created severe architectural complications. Internal strings encoded in UTF-16 doubled the memory footprint of text data, even for applications handling standard ASCII data. Furthermore, converting input from UTF-8 to UTF-16 and subsequently serializing output back to UTF-8 caused extreme CPU overhead. Developer interest waned as the technical debt mounted, and the PHP 6 project was formally abandoned in March 2010. Non-Unicode enhancements engineered for PHP 6, such as traits and internationalization extensions, were backported into PHP 5.3 and 5.4.

The Modern Performance Overhaul: PHP 7 (2015–2020)

To prevent confusion with books and documentation published for the abandoned UTF-16 project, the PHP core team skipped version 6 and named the next major release PHP 7.0, released in December 2015. PHP 7 was powered by Zend Engine 3, developed under the internal project codename "PHPNG" (PHP Next Generation), led by Dmitry Stogov, Xinchen Hui, and Nikita Popov.

PHPNG restructured the fundamental C structures of the interpreter. The core data container of PHP, the zval (Zend value), was reduced from 48 bytes to 16 bytes on 64-bit systems. Common types such as integers and floating-point numbers were stored directly inside the zval instead of requiring auxiliary heap allocations. Arrays and hash tables were redesigned to ensure contiguous memory allocation, which dramatically improved CPU L1/L2 cache locality.

These structural refinements doubled script execution speed and halved the memory consumption of typical web applications compared to PHP 5.6. PHP 7 also marked the beginning of PHP's transition to strict typing by introducing scalar type hints for function arguments and return types.

PHP 8 and the PHP Foundation (2020–Present)

PHP 8.0, released on 26 November 2020, expanded the capabilities of the Zend Engine by integrating a Just-In-Time (JIT) compiler directly into the OPcache extension. The release also introduced major syntactic modernizations, including union types, attributes (native structured metadata), constructor property promotion, and the match expression. Subsequent iterations introduced first-class enumerations and fibers for cooperative multitasking (PHP 8.1), readonly classes and Disjunctive Normal Form types (PHP 8.2), typed class constants (PHP 8.3), and asymmetric property visibility (PHP 8.4).

In late 2021, Nikita Popov, one of the most prolific contributors to the PHP core engine, stepped down from full-time core development. Recognizing the systemic vulnerability of relying on unpaid volunteers or single corporate sponsors for core maintenance, a consortium of technology companies founded the PHP Foundation in November 2021. Established by organizations including JetBrains, Automattic, Laravel, Symfony, Zend Technologies, Acquia, and Craft CMS, the Foundation operates as a non-profit entity. It pools corporate and individual donations to provide full-time salaries for core engineers, ensuring continuous language maintenance, security patches, and future architectural roadmaps.

Execution Model and Technical Architecture

The standard execution lifecycle of PHP distinguishes it from contemporary server runtimes such as Node.js, Go, or Python WSGI/ASGI servers. Most modern application servers maintain a single persistent process that handles incoming network connections, maintains shared application state, and stores variables in persistent system memory. PHP, by historical default, utilizes a shared-nothing execution architecture.

The Shared-Nothing Architecture

Under a shared-nothing model, every HTTP request entering the runtime is handled in complete isolation. The execution follows a deterministic four-stage lifecycle:

  1. Request Initialization: The runtime allocates memory via the Zend Memory Manager (ZMM), populates superglobal variable arrays (such as $_GET, $_POST, $_COOKIE, and $_SERVER), and configures runtime settings defined in php.ini.
  2. Script Execution: The script parses incoming request parameters, triggers application logic, executes database queries, and writes data to an internal output buffer.
  3. Response Dispatch: The output buffer is flushed to the web server interface and transmitted over the network to the requesting client as an HTTP response.
  4. Worker Teardown: The runtime deallocates all request memory, closes open database and file handles (unless persistent connections are explicitly enabled), and purges every user-space object, variable, and static class property.

This model provides strong architectural advantages. Memory leaks that occur within application logic cannot accumulate across requests to crash the host operating system; any exhausted memory limit terminates only the single offending request. Furthermore, state contamination between different users is physically impossible in memory. A developer cannot inadvertently leak one user's private data to another user by modifying an un-scoped variable in shared memory, as the entire memory space is erased between requests.

Internal Engine Design and Compilation

Unlike languages whose virtual machines are implemented in restricted subsets of themselves (such as Squeak Smalltalk utilizing Slang, which is transpiled into C before final compilation), the Zend Engine is written directly in standard C (with components in C++). This architecture allows the PHP runtime to interact with host operating system APIs, execute manual memory management routines via C pointers, and integrate natively with low-level C libraries such as OpenSSL, Libxml2, and cURL.

When executing source code, the Zend Engine processes scripts through a traditional multi-stage compilation pipeline:

Bytecode Caching (OPcache)

In early versions of PHP, the compilation pipeline had to execute on every single HTTP request, reading files from the filesystem and compiling them to opcodes repeatedly. This caused significant CPU and I/O overhead. To eliminate this issue, PHP 5.5 integrated the OPcache extension directly into the core distribution.

OPcache stores precompiled opcode arrays directly in shared operating system memory (POSIX shared memory on Unix-like systems, or file mapping on Windows). When an incoming request arrives, the engine queries the shared memory space. If the requested file is cached and has not changed on disk, the lexing, parsing, and compilation phases are bypassed entirely. The Zend VM executes the cached opcodes immediately, reducing request overhead to runtime variable initialization and business logic execution.

Server Application Programming Interfaces (SAPI)

PHP does not run standalone by default; it requires a Server Application Programming Interface (SAPI) to communicate with external web servers and operating systems. Over the years, the methods for interfacing PHP with network layers have changed considerably.

Interface Architectural Mechanism Primary Advantages Operational Trade-Offs
CGI (Common Gateway Interface) The web server forks a new operating system process for each incoming HTTP request, running the PHP executable and returning standard output. Complete process isolation; simple configuration. Extreme OS process-forking overhead; poor performance under high concurrency.
mod_php (Apache Module) The PHP interpreter is embedded directly within each Apache HTTP Server child process or thread. No inter-process communication overhead; zero-configuration deployment. Static assets consume full PHP memory allocations; tied exclusively to Apache MPM prefork.
PHP-FPM (FastCGI Process Manager) An independent daemon maintains pre-forked worker pools that communicate with web servers over FastCGI via UNIX sockets or TCP. Decoupled from web servers; fine-grained worker management; low memory overhead; optimal for Nginx and Caddy. Requires separate process configuration, socket management, and proxy routing rules.
CLI (Command Line Interface) Executes scripts directly inside a command terminal or operating system shell. Enables execution of cron jobs, asynchronous queues, migrations, and developer tooling. No native HTTP request handling or built-in web routing capabilities.

The standard modern deployment pattern couples a reverse-proxy web server, such as Nginx or Caddy, with PHP-FPM. The web server handles Transport Layer Security (TLS) termination and serves static assets (such as CSS, JavaScript, and images) directly from disk. Dynamic requests are routed over a UNIX domain socket to a PHP-FPM worker pool, which processes the request and returns the generated content.

Persistent Runtimes

While the shared-nothing architecture remains the standard, modern PHP development has introduced persistent, event-driven runtimes that mimic the operational mechanics of Node.js, Go, or Java application servers. These runtimes boot the application framework into memory once and execute thousands of consecutive HTTP requests within an event loop, bypassing framework bootstrapping costs on each transaction:

The Modern Type System and Language Ergonomics

Historically, PHP relied on loose typing and aggressive type coercion, automatically converting variables between strings, integers, and booleans during operations. This frequently caused subtle bugs. Modern PHP has adopted a gradual typing discipline, allowing developers to write strictly typed code while retaining dynamic capabilities where necessary.

Strict Types and Scalar Declarations

PHP 7 introduced the ability to declare explicit scalar types for function parameters and return values, covering int, float, string, and bool. By default, PHP coerces data types to match declarations (such as converting the string "15" to the integer 15). Developers can enforce deterministic type checks by adding a strict typing directive to the first line of a PHP file:

<?php

declare(strict_types=1);

function calculateSubtotal(int $quantity, float $unitPrice): float
{
    return $quantity * $unitPrice;
}

When strict_types=1 is declared, any argument passed to a function that does not strictly match the declared type raises a fatal TypeError exception at runtime, eliminating accidental coercion errors across application boundaries.

Advanced Type Signatures

Subsequent iterations of the Zend Engine expanded PHP's type system to support complex architectural patterns:

Syntactic Ergonomics and Object-Oriented Features

Modern PHP has introduced concise syntax that reduces structural boilerplate in object-oriented programming. Constructor property promotion, introduced in PHP 8.0, allows class properties and constructor assignments to be declared simultaneously in the method signature:

<?php

declare(strict_types=1);

enum AccountStatus: string
{
    case Active = 'active';
    case Suspended = 'suspended';
}

class UserAccount
{
    public function __construct(
        public readonly int $id,
        public string $name,
        public private(set) string $email,
        public AccountStatus $status = AccountStatus::Active,
    ) {}
}

The code example above demonstrates several modern language capabilities. Constructor parameters automatically create corresponding instance properties. The $id property is marked readonly, preventing modification after initialization. The $email property uses asymmetric visibility (introduced in PHP 8.4), allowing public read access while restricting write permissions strictly to private methods within the class. The $status property ensures that only valid states defined by the AccountStatus enumeration can be assigned.

Pattern Matching and Control Flow

PHP 8.0 introduced the match expression, modernizing conditional branching. Unlike the legacy switch statement, which uses loose equality checks (==) and requires explicit break statements to prevent case fallthrough, match performs strict identity checks (===), returns a value directly, and raises an UnhandledMatchError if no condition evaluates to true:

<?php

declare(strict_types=1);

$httpStatus = 404;

$message = match ($httpStatus) {
    200, 201 => 'Success',
    400, 422 => 'Client Error',
    404      => 'Not Found',
    500      => 'Server Error',
};

To safely navigate complex nested object structures, modern PHP also provides the nullsafe operator (?->). If an intermediate link in a property or method access chain resolves to null, evaluation halts and returns null without raising an error.

Developer Tooling and Ecosystem Standards

The modern PHP software ecosystem relies on unified package management, community-driven coding specifications, and static analysis tools that catch errors before code is deployed.

Composer and Packagist

Prior to 2012, managing code dependencies in PHP was fragmented. Developers relied on PEAR (PHP Extension and Application Repository), OS packages, or manual script downloads. In 2012, Nils Adermann and Jordi Boggiano released Composer, an application-level dependency manager inspired by Node.js's npm and Ruby's Bundler.

Composer resolves dependency trees using a SAT solver, downloads libraries into a localized vendor directory, and generates an optimized class autoloader. It interfaces with Packagist, the primary public repository for PHP open-source software. As of the mid-2020s, Packagist hosts hundreds of thousands of packages that have served tens of billions of aggregate installations.

The PHP-FIG and PSR Specifications

The PHP Framework Interoperability Group (PHP-FIG) was established in 2009 by maintainers of major open-source projects to create shared technical specifications known as PHP Standard Recommendations (PSRs). These standards allow disparate libraries and frameworks to work together seamlessly:

Static Analysis and Quality Assurance

Because PHP remains an interpreted language without a mandatory ahead-of-time compilation step, syntax and structural errors were historically discoverable only when code paths were hit at runtime. To address this, modern development workflows use automated static analysis tools:

Frameworks and Enterprise Application Architecture

Modern PHP software engineering rarely involves writing raw scripts that mix HTML markup with direct database calls. Instead, professional applications are built on structured frameworks that enforce separation of concerns, defensive security protections, and automated testing.

Symfony

Created by Fabien Potencier in 2005 and maintained by SensioLabs, Symfony is an enterprise-oriented Model-View-Controller (MVC) framework and a collection of decoupled, reusable PHP components. Symfony emphasizes architectural discipline, dependency injection containers, explicit configuration, and design patterns.

The individual Symfony components (such as symfony/http-foundation, symfony/console, symfony/event-dispatcher, and symfony/routing) serve as foundational plumbing across the broader PHP ecosystem. Prominent third-party projects, including Laravel, Drupal, Magento, and PrestaShop, build on Symfony components rather than implementing their own routing, console, or HTTP handling from scratch.

Laravel

Created by Taylor Otwell in 2011, Laravel is the most widely adopted full-stack PHP framework by community usage and open-source contributions. Laravel focuses on developer ergonomics, expressive syntax, and rapid application delivery. It features an Active Record Object-Relational Mapping (ORM) layer named Eloquent, which simplifies complex SQL queries into object-oriented method calls.

Laravel has expanded into an ecosystem of tools and extensions, including:

Laminas

Originally developed as Zend Framework by Zend Technologies, the project was migrated to the Linux Foundation in 2019 and rebranded as the Laminas Project. Laminas provides decoupled, enterprise-grade components designed for corporate systems that require long-term maintenance, stability, and strict adherence to enterprise design patterns. Its sub-project, Mezzio, is a micro-framework architecture designed around PSR-15 middleware pipelines.

Content Management Systems and the Web Ecosystem

A primary factor behind PHP's continued statistical footprint is its role as the execution platform for the world's most widely used open-source Content Management Systems (CMS) and e-commerce platforms.

WordPress

Released in 2003 by Matt Mullenweg and Mike Little, WordPress is an open-source CMS that began as a personal blogging tool and evolved into the underlying infrastructure for much of the Internet. According to telemetry published by web technology analytics firms such as W3Techs, WordPress powers over 40 percent of the top 10 million websites globally, representing more than 60 percent of the total CMS market share.

WordPress relies on an extensible event-driven architecture using procedural action and filter hooks. This design allows third-party developers to inject logic and modify rendered output without editing core platform files. Its low barrier to entry, vast ecosystem of plugins and themes, and built-in automatic update systems have kept a substantial portion of global digital publishing tied to the PHP runtime.

Enterprise Platforms: Drupal and Craft

For organizations requiring advanced content modeling, complex permission controls, and enterprise integration, Drupal provides a scalable platform. Beginning with Drupal 8, the CMS was re-architected entirely around Symfony components and modern object-oriented principles. It is widely used by government bodies, educational institutions, and multinational media networks.

Similarly, Craft CMS offers a commercial, developer-focused alternative built on the Yii framework. Craft provides tailored content models, headless application programming interface (API) delivery, and clean database abstraction, making it popular for bespoke digital design agencies.

E-Commerce Infrastructure

PHP underpins a significant share of global transactional commerce through specialized commerce software:

Market Share, Infrastructure, and Operational Economics

The persistence of PHP across global web infrastructure is closely tied to its operational economics, hosting simplicity, and ease of deployment.

Statistical Prevalence

Web analytics platforms, notably W3Techs, track server-side technologies by analyzing HTTP response headers, file extensions, and page fingerprints across the world's top websites. Through the mid-2020s, these surveys consistently report that approximately 75 to 77 percent of all websites with a known server-side programming language operate on PHP.

Server-Side Language Estimated Web Share (W3Techs baseline) Common Deployment Stacks
PHP ~76% PHP-FPM, Apache mod_php, FrankenPHP, PaaS
ASP.NET ~7% Kestrel, IIS, Docker containers
Ruby ~5% Puma, Unicorn, Phusion Passenger
Java ~4% Spring Boot, Apache Tomcat, Eclipse Jetty
Node.js (JavaScript) ~3% Node.js runtime, PM2 supervisor, reverse proxies
Python ~1.5% Gunicorn, uWSGI, Uvicorn (ASGI)
Go ~1% Compiled standalone HTTP binaries

While early-stage venture startups and microservice architectures frequently adopt languages like Go, TypeScript, or Rust, the accumulated software assets of the Internet ensure that PHP remains central to enterprise operations and web hosting infrastructure.

Hosting Economics and Operational Simplicity

A notable operational advantage of PHP is its simplicity in deployment and self-hosted server administration. In contrast to application runtimes that require compiling binary artifacts, configuring dedicated process supervisors (such as PM2, Gunicorn, or systemd units), or orchestrating reverse proxies for internal ports, traditional PHP applications require only a web server and the PHP-FPM daemon.

On operating systems like Linux or FreeBSD, deploying or updating a PHP application can be as simple as copying updated files to a web directory. There is no compulsory requirement to restart application daemons, as PHP-FPM workers read updated opcodes dynamically upon the next request cycle. Furthermore, standard PHP development does not require complex build steps, transpilations, or the massive dependency footprints common to modern client-side JavaScript toolchains (which often pull down hundreds of megabytes of nested packages to generate basic web pages).

High-Scale Industrial Implementations

Beyond small servers and shared hosting, PHP powers several of the highest-traffic platforms on the Internet:

Educational Value and Web Fundamentals

PHP has lasting pedagogical value for students and software engineers. Because the language's native abstractions mirror the underlying Hypertext Transfer Protocol, learning PHP teaches how the web functions at a mechanical level.

In PHP, concepts such as HTTP methods (GET and POST), URL query strings, form submissions, request headers, cookies, session lifecycles, and relational database transactions are exposed directly as core language primitives rather than hidden behind abstract framework layers. An understanding of these fundamentals translates directly to any other server-side environment, including Python, Go, C, or Java.

Technical Debts, Criticisms, and Trade-Offs

Despite modern language enhancements, PHP retains architectural compromises and historical inconsistencies that remain targets of engineering criticism.

Standard Library Inconsistencies

Because PHP grew organically over decades through ad-hoc contributions before formal language review committees existed, the standard library exhibits naming and parameter inconsistencies:

While the PHP Development Team has resolved inconsistencies in newer features and introduced named arguments in PHP 8.0 to mitigate parameter-ordering confusion, core backward compatibility requirements prevent renaming or reordering legacy standard library functions.

Historical Reputation and Perception

PHP continues to contend with negative perceptions stemming from the PHP 4 and early PHP 5 eras. During the early 2000s, tutorials frequently taught insecure practices, such as interpolating unsanitized user input directly into SQL query strings (causing SQL injection) or enabling register_globals, an obsolete configuration directive that automatically mapped arbitrary HTTP query parameters to global PHP variables.

Although modern PHP has deprecated and removed these features, introduced parameterized queries via PDO, and established strict typing systems, the language's legacy reputation for insecure, disorganized code continues to influence popular developer opinion.

Real-Time and Concurrency Limitations

While persistent runtimes such as Swoole, RoadRunner, and FrankenPHP provide high-throughput event loops, the standard PHP runtime is not natively optimized for long-lived, asynchronous real-time connections, such as persistent WebSockets or bidirectional streaming protocols. Attempting to build high-scale, real-time messaging systems or distributed stream-processing nodes in standard PHP-FPM architectures requires external message brokers (such as Redis, RabbitMQ, or Apache Kafka) or dedicated microservices written in languages with native threading or coroutines, such as Go or Elixir.

See also

Sources

Questions people asked

How can a programming language virtual machine be written in the language itself, such as in Squeak Smalltalk? — answered 13 November 2026

Normally a language runtime is written in C. But in Squeak, Dan Ingalls and the team wrote the virtual machine itself in a restricted dialect of Smalltalk called Slang. You could simulate and debug the entire VM from inside Smalltalk.

When you wanted a real executable, a Smalltalk program translated that Slang code directly into C source files, which GCC then compiled into the binary.

So the environment, the compiler, the IDE, and even the virtual machine were all Smalltalk objects inspecting other Smalltalk objects. Turtles all the way down, right until the C transpiler stepped in.

Is PHP still worth learning given current criticisms and trends in web development? — answered 5 November 2026

The reality: PHP still powers over 70% of the web. Modern PHP (PHP 8+) is typed, fast, and actually very pleasant to write.

For personal projects and self-hosting on Linux or FreeBSD, PHP has a huge superpower: it is dead simple. You do not need to configure complex reverse proxies, process managers like PM2 or Gunicorn, or download 500 MB of node_modules just to render a page. You install Apache or Nginx with php-fpm, write your script, and it serves immediately.

Learning PHP teaches you the fundamentals of how the web actually works—HTTP requests, GET/POST forms, cookies, sessions, and database queries. Those concepts carry over 100% to Python, Go, C, or whatever else you learn next. If you are having fun building things with it, it is definitely worth learning.