DEV Community: The Practical Developer

NGINX Explained: The Server in Front of Your Server

The Practical Developer — Sun, 01 Nov 2026 12:51:09 +0000

Most web apps do not face the internet alone. In front of them sits a server whose job is to serve files fast, hand requests to the right app, and spread load across machines. NGINX, written by Igor Sysoev and first released in 2004, is that server for a large share of the busiest sites: one process, thousands of connections, and a configuration file that reads like a set of routing rules.

Static files, reverse proxies, and load balancing

NGINX rests on a few distinctive ideas:

An event-driven design: a small number of worker processes handle many connections at once, instead of one thread per visitor, which keeps memory low under heavy traffic.
Static files, served directly: images, stylesheets, and scripts come straight from disk, so the app server never wastes time on work the front server can do.
Reverse proxying: requests for dynamic pages are passed to an app running on another port or machine, while the visitor only ever sees NGINX.
Load balancing built in: list several app servers and NGINX spreads requests across them, retrying a healthy one when another stops responding.

A tiny example shows the shape, a server block that serves static files itself and passes everything else to an app on port 3000:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }

    location /static/ {
        root /var/www/html;
    }
}

listen 80 takes ordinary web traffic, proxy_pass forwards a request to the app listening on the same machine at port 3000, and root inside the static location serves files from disk. A request for /static/logo.png is answered from /var/www/html/static/logo.png, while a request for /dashboard goes to the app. Test the file with nginx -t before reloading, so a typo never takes the site down.

The honest trade

NGINX trades application logic for speed at the edge: it is not where business rules live, its configuration syntax rewards careful reading, and debugging a proxy problem means checking two servers instead of one. When to reach for it: when an app needs static serving, secure termination, or traffic spread across servers; a plain app server alone when the project is small and none of those are needed yet.

In front, quietly working

NGINX is the server in front of your server: static files from disk, dynamic requests forwarded, load shared across machines, all from a short configuration file. It trades one more moving part for a front door that stays fast under pressure, and for sites that grow, that front door earns its place.

Originally published at https://practicaldevblog.blogspot.com/2026/11/nginx-explained-server-in-front-of-your.html

PyTorch Explained: Machine Learning You Can Watch Learn

The Practical Developer — Sun, 01 Nov 2026 12:50:17 +0000

TensorFlow showed one way to train a model, with layers stacked and compiled. PyTorch, released by Meta's AI research lab in 2016, takes a more hands-on approach: you write ordinary Python, tensors track their own gradients, and the training loop is a loop you can read, print from, and change. That openness made it the favourite of researchers, and it is now just as common in production, from image models to language models.

Tensors, autograd, and the training loop

PyTorch rests on a few distinctive ideas:

Tensors that feel like arrays: a tensor is a multi-dimensional array, like a NumPy array, with the added ability to run on a graphics card for speed.
Autograd: operations on tensors remember how they were built, so calling backward fills in every gradient automatically instead of asking you to derive them by hand.
Modules, composed freely: a model is a module, layers are modules inside it, and you assemble them with plain Python control flow, including loops and conditions.
A training loop you own: zero the gradients, run the model, measure the loss, step the optimiser, and repeat, with every step visible in your own code.

A tiny example shows the shape, a model that learns the line y = 2x + 1 from four examples:

import torch
import torch.nn as nn

xs = torch.tensor([[0.0], [1.0], [2.0], [3.0]])
ys = torch.tensor([[1.0], [3.0], [5.0], [7.0]])

model = nn.Linear(1, 1)
optimizer = torch.optim.SGD(model.parameters(), lr=0.01)
loss_fn = nn.MSELoss()

for _ in range(200):
    optimizer.zero_grad()
    loss = loss_fn(model(xs), ys)
    loss.backward()
    optimizer.step()

print(model(torch.tensor([[4.0]])))

nn.Linear(1, 1) creates one input neuron connected to one output, zero_grad clears the previous step's gradients so they do not pile up, loss.backward computes fresh gradients, and step nudges the weights a little in the direction that lowers the loss. After 200 passes, predicting for 4.0 lands near 9.0, not exactly, because training improves gradually rather than solving the equation outright.

The honest trade

PyTorch trades hand-holding for control: the training loop is yours to write, which means yours to debug, and moving a model into production takes extra tooling compared with a more packaged framework. When to reach for it: when you want to understand, customise, or research a neural network; a higher-level library when the model is standard and speed of setup matters more than control.

Tensors, trained in the open

PyTorch is machine learning you can watch learn: tensors, automatic gradients, and a training loop written out in plain Python. It trades convenience for control over every step, and for anyone who wants to see how a model actually improves, that openness is the point.

Originally published at https://practicaldevblog.blogspot.com/2026/11/pytorch-explained-machine-learning-you.html

Pandas Explained: Tables in Python, Without the Spreadsheet

The Practical Developer — Sun, 01 Nov 2026 12:49:22 +0000

A spreadsheet is fine until the data grows: a million rows, ten files to combine, or the same cleanup repeated every week. Pandas, a Python library created by Wes McKinney and first released in 2008, gives you spreadsheet-style tables inside code, so the cleanup is written once and runs the same way every time. It is the default first step for data work in Python, from a quick sales summary to the data preparation behind a machine learning model.

DataFrames, filtering, and grouping

Pandas rests on a few distinctive ideas:

DataFrames and Series: a DataFrame is a table with named columns, a Series is a single column, and both carry labels, so rows and columns can be picked by name instead of position.
Reading real files: one call loads a CSV, a spreadsheet, or a database query into a table, with missing values handled rather than silently dropped.
Filtering and selecting: conditions pick out rows, column names pick out columns, and the two combine into queries that read almost like sentences.
Grouping and joining: groupby summarises rows by category, merge joins tables on a shared key, and both replace the manual copying that spreadsheets encourage.

A tiny example shows the shape, a sales table filtered and then totalled by city:

import pandas as pd

sales = pd.DataFrame({
    "city": ["Karachi", "Lahore", "Karachi"],
    "amount": [120, 90, 80],
})

big_sales = sales[sales["amount"] >= 100]
print(big_sales)
print(sales.groupby("city")["amount"].sum())

sales["amount"] >= 100 builds a true/false mask, one value per row, and sales[mask] keeps only the rows where it is true, so the Karachi row of 120 survives and the other two do not. groupby("city")["amount"].sum() then adds the amounts per city, giving 200 for Karachi and 90 for Lahore. The original table is untouched; every step returns a new result.

The honest trade

Pandas trades memory for convenience: it loads data into memory, so very large datasets need chunking or a different tool, and its many ways to do the same thing can confuse beginners. When to reach for it: when data fits comfortably in memory and needs cleaning, exploring, or summarising in Python; a database or a distributed tool when the data is too big to hold in memory at all.

Tables, without the spreadsheet

Pandas is tables in Python, without the spreadsheet: DataFrames you can filter, group, and join, in code that reruns exactly. It trades memory for a workflow that scales past copy and paste, and for data that fits on one machine, that trade is usually worth making.

Originally published at https://practicaldevblog.blogspot.com/2026/11/pandas-explained-tables-in-python.html

TensorFlow Explained: Machine Learning, From Tensors to Training

The Practical Developer — Sat, 31 Oct 2026 20:29:10 +0000

Introduction

Machine learning sounds like magic until you see the machinery: numbers flow through operations, a model adjusts its parameters, and error goes down. TensorFlow, released by Google in 2015, is the library that packages that machinery: it represents data as tensors, multi-dimensional arrays, and gives you the tools to build, train, and ship models, from a laptop experiment to a phone app.

Tensors, Keras, and the road to production

TensorFlow rests on a few distinctive ideas:

Tensors first: data is a tensor, an array with shape and type, and every operation, from addition to a neural network layer, works on tensors.
Keras, the friendly front door: the high-level Keras API lets you stack layers into a model in a few lines, while TensorFlow underneath handles the maths.
Eager by default, graphs when needed: run operations immediately while experimenting, then compile a model into an efficient graph for training and serving.
An ecosystem around the model: TensorFlow Lite runs models on phones, TensorFlow.js runs them in the browser, and serving tools take a trained model into production.

A tiny example shows the shape, a model that learns the line y = 2x + 1 from four examples:

import numpy as np
import tensorflow as tf

xs = np.array([0.0, 1.0, 2.0, 3.0], dtype=np.float32)
ys = np.array([1.0, 3.0, 5.0, 7.0], dtype=np.float32)

model = tf.keras.Sequential([
    tf.keras.layers.Input(shape=(1,)),
    tf.keras.layers.Dense(units=1)
])
model.compile(optimizer='sgd', loss='mean_squared_error')
model.fit(xs, ys, epochs=100, verbose=0)
print(model.predict(np.array([4.0], dtype=np.float32)))

Input(shape=(1,)) says each example is one number, Dense(units=1) adds a single output neuron, compile picks the optimiser and the loss, and fit trains for 100 passes over the data. Predicting for 4.0 gives a value near 9.0, not exactly, because training improves gradually rather than solving the equation outright.

The honest trade

TensorFlow trades simplicity for scale: it is a large library with a learning curve, small models are often easier in a smaller library like scikit-learn, and debugging a training run takes patience. When to reach for it: for neural networks, especially ones headed for production or mobile; a smaller library when the model is a simple regression or classifier.

A model, not magic

TensorFlow is machine learning from tensors to training: data as arrays, models as stacked layers, and an ecosystem that carries a trained model onto phones, browsers, and servers. It trades a gentle learning curve for serious scale, and for neural networks that need to ship, that scale is the reason it endures.

Playwright Explained: Browser Tests That Act Like a Real User

The Practical Developer — Sat, 31 Oct 2026 20:27:44 +0000

Introduction

Tests that click through a browser used to be flaky: the test clicked before the page was ready, or grabbed the wrong element after a redesign. Playwright, released by Microsoft in 2020, fixes most of that by driving real Chromium, Firefox, and WebKit browsers and waiting for elements to be ready before it acts. It is now a standard choice for end-to-end tests, from a marketing page to a full checkout flow.

Real browsers, auto-waiting, and locators

Playwright rests on a few distinctive ideas:

Real browsers, three engines: one API drives Chromium, Firefox, and WebKit, so a test can prove a page works in every engine, not just one.
Auto-waiting: clicks, fills, and assertions wait for the element to be actionable, which removes most of the sleeps and retries that made older browser tests flaky.
Locators that read like intent: find elements by role, label, or text, so tests describe what the user sees instead of fragile CSS paths.
Tooling that helps debugging: code generation records your clicks into a test, traces replay failures step by step, and screenshots show exactly what the browser saw.

A tiny example shows the shape, a test that loads a page and checks its heading:

const { test, expect } = require('@playwright/test');

test('example page has a heading', async ({ page }) => {
  await page.goto('https://example.com/');
  await expect(page.getByRole('heading', { name: 'Example Domain' })).toBeVisible();
});

page.goto loads the page, getByRole('heading', ...) finds the heading the way assistive technology would, and toBeVisible waits for it automatically instead of checking instantly. If the heading appears a moment later, the test still passes.

The honest trade

Playwright trades speed and simplicity for realism: browser tests are slower than unit tests, they need browsers installed, and they can still be flaky around third-party widgets and animations. When to reach for it: for flows that must work in a real browser, like sign-up or checkout; unit tests for logic, and API tests for backends, where a browser adds nothing.

Test what the user sees

Playwright is browser tests that act like a real user: real engines, auto-waiting, and locators that describe intent, in tests that read like a visitor's journey. It trades test speed for confidence in the real thing, and for the flows that must not break, that confidence is worth the wait.

Ruby on Rails Explained: Web Apps by Convention, Not Configuration

The Practical Developer — Sat, 31 Oct 2026 20:26:02 +0000

Introduction

Most web frameworks give you pieces and ask you to wire them together. Ruby on Rails, released in 2004 by David Heinemeier Hansson from the Basecamp codebase, gives you the whole app structure up front: where models live, how URLs map to code, and how database tables become objects. That opinionated structure is the point. Follow the conventions and a small team can ship a complete web app, database, pages, forms, and email, in days rather than weeks.

Convention over configuration, MVC, and Active Record

Rails rests on a few distinctive ideas:

Convention over configuration: file names, class names, and table names follow patterns, so Rails can guess what you mean instead of asking you to spell it out.
MVC, built in: models hold data and rules, controllers handle requests, views render pages, and the three have a fixed home in every Rails app.
Active Record: a database table becomes a class, a row becomes an object, and queries read like plain Ruby instead of SQL strings.
Everything in one box: routing, database migrations, form helpers, background jobs, and mailers ship together, so a new app needs few extra decisions.

A tiny example shows the shape, an articles listing built from three small files:

# config/routes.rb
Rails.application.routes.draw do
  resources :articles, only: [:index, :show]
end

# app/models/article.rb
class Article < ApplicationRecord
  validates :title, presence: true
end

# app/controllers/articles_controller.rb
class ArticlesController < ApplicationController
  def index
    @articles = Article.all
  end
end

resources :articles creates the routes for listing and showing articles, validates :title, presence: true makes a title required, and Article.all returns every row as an object. The view then loops over @articles and renders each one. Naming does most of the work.

The honest trade

Rails trades flexibility and raw speed for speed of development: its conventions feel restrictive when an app outgrows them, its "magic" can hide what is happening until something breaks, and very high traffic apps often need careful tuning. When to reach for it: when building a database-backed web app quickly with a small team; a lighter framework or a different language when the app is unusual enough that the conventions fight you.

Conventions that ship

Ruby on Rails is web apps by convention, not configuration: MVC structure, Active Record models, and a full toolbox in one framework, in a language that reads like plain English. It trades some freedom for shipping speed, and for teams that want a working app this week, that trade is the whole appeal.

Objective-C Explained: The Language That Built the iPhone Era

The Practical Developer — Fri, 30 Oct 2026 13:18:45 +0000

Introduction: Before Swift, every iPhone app was written in Objective-C. Created in the 1980s by adding Smalltalk-style messaging to C, it became Apple's language through NeXT, macOS, and the first decade of iOS, and it still underpins much of Apple's older code. Its syntax looks strange at first, with square brackets and colons where other languages use dots, but that strangeness is its central idea: objects do not call methods, they send messages, and the runtime decides what happens next.

Messages, the runtime, and Cocoa: Message syntax: instead of object.method(argument), you write [object method:argument], and a method with several parts reads like a sentence, with each argument labelled. A dynamic runtime: messages are resolved at run time, so objects can forward messages, add methods, or respond in ways the compiler never saw, which powers much of Cocoa's flexibility. C underneath: Objective-C is a strict superset of C, so C code, pointers, and libraries work unchanged inside an Objective-C program. Cocoa frameworks: AppKit on macOS and UIKit on iOS, built on Objective-C, gave developers the windows, views, and controls that defined Apple software for decades.

#import <Foundation/Foundation.h>
@interface Greeter : NSObject
- (void)greet:(NSString *)name;
@end
@implementation Greeter
- (void)greet:(NSString *)name {
NSLog(@"Hello, %@!", name);
}
@end
int main(int argc, const char * argv[]) {
@autoreleasepool {
Greeter *greeter = [[Greeter alloc] init];
[greeter greet:@"Ayesha"];
}
return 0;
}

Explanation: @interface declares the class, @implementation defines it, NSLog prints with %@ for an object, and [greeter greet:@"Ayesha"] sends the greet message with its labelled argument. The brackets are the language.

The honest trade: Objective-C's trade is modernity and hiring: Swift is now Apple's preferred language, new projects rarely start in Objective-C, and its syntax and manual memory history (now mostly handled by ARC) feel dated to newcomers.

When to reach for it: when maintaining or extending existing Apple codebases, where it is still essential; Swift for any new Apple project, where the tooling and community have moved.

The brackets that built an era: Objective-C is the language that built the iPhone era: C with Smalltalk messaging, a dynamic runtime, and Cocoa, in syntax that reads like sentences in square brackets. It trades modern tooling for history and depth, and for the codebases it still powers, that history is unavoidable.

Lua Explained: The Tiny Language Behind Big Games

The Practical Developer — Fri, 30 Oct 2026 13:16:56 +0000

Introduction: Some languages want to be the whole program. Lua, created in Brazil in 1993, wants to be the part you script: a tiny, fast language designed to live inside a larger application, where designers and modders can change behaviour without rebuilding the host. It powers game scripting in titles like World of Warcraft and Roblox, configuration in tools like Neovim, and embedded scripting in Redis and NGINX. Lua proves that a language can be small and still run big systems.

Tables, metatables, and coroutines: Tables do everything: there is one data structure, the table, and it serves as array, record, object, and module, so the language stays tiny while programs stay expressive. Metatables for behaviour: attach a metatable to a table and you can define how it behaves for operators, indexing, and method calls, which is how Lua builds objects without classes. Coroutines: lightweight, cooperative threads that pause and resume, ideal for game logic that needs to wait without blocking the whole program. Embeddable by design: a small C API lets a host program run Lua scripts, expose its own functions to them, and keep the scripting layer separate from the engine.

-- A table acting as a simple record
local player = { name = "Ayesha", score = 0 }
function player.add_points(self, points)
  self.score = self.score + points
end
player:add_points(10)
print(player.name, player.score)  -- Ayesha, 10

Explanation: The colon in player:add_points(10) passes player as the first argument, so self is the table itself. One structure, one calling convention, and the object emerges from it.

The honest trade: Lua's trade is ecosystem and scale: it has fewer libraries than Python or JavaScript, its standard library is deliberately small, and large codebases need discipline to keep table-based designs readable.

When to reach for it: when you need a fast, embeddable scripting layer inside a game, tool, or server; a full general-purpose language when the program itself, not the scripting layer, is the job.

Small language, large stage: Lua is the tiny language behind big games: tables, metatables, coroutines, and an embeddable design, in a language that fits inside the programs it scripts. It trades a large standard library for size and speed, and for games and tools that need scripting, that trade is exactly right.

MATLAB Explained: Engineering Maths in Matrix Form

The Practical Developer — Fri, 30 Oct 2026 13:15:59 +0000

Introduction: Most programming languages treat numbers one at a time and add matrices as a library. MATLAB, released in 1984, flips that round: a matrix is the basic value, so adding, multiplying, and plotting whole arrays is the default, not the special case. It grew out of numerical linear algebra, became the standard tool in engineering courses and labs, and still powers signal processing, control systems, and data analysis where the maths, not the software, is the hard part.

Matrices first, plots in one line, and toolboxes: Everything is a matrix: even a single number is a 1 by 1 matrix, so operations that need loops in other languages apply to whole arrays at once. Vectorised maths: add a vector to a vector, multiply matrices, or solve a linear system with a single operator, and the language handles the element-by-element work. Plotting built in: a plot is one function call, not a charting library to learn, so results are visible immediately. Toolboxes: curated collections for signal processing, control, image processing, and more, each with tested functions for its domain.

% Solve A*x = b, where A and b are known
A = [1, 2; 3, 4];
b = [5; 11];
x = A \ b
% x is [1; 2], since 1 + 4 = 5 and 3 + 8 = 11
% Plot a sine wave from the same session
t = 0:0.1:2*pi;
y = sin(t);
plot(t, y);
title('Sine wave');

Explanation: A backslash b is the backslash operator for solving linear systems, 0:0.1:2*pi builds a range, and sin works on the whole vector at once. No loops, no imports, just maths.

The honest trade: MATLAB's trade is cost and generality: licences are expensive, the language is a poor fit for general-purpose software or web apps, and code written in MATLAB stays inside its ecosystem unless it is exported.

When to reach for it: when the job is numerical work, simulation, or analysis, and the toolboxes match the domain; a free language like Python with NumPy when cost or general-purpose code matters more.

Maths, made visible: MATLAB is engineering maths in matrix form: vectorised operations, one-line plots, and domain toolboxes, in a language where the matrix is the default. It trades general-purpose power and cost for numerical fluency, and for engineers, that fluency is the point.

Crystal Explained: Ruby's Syntax, Compiled Speed

The Practical Developer — Tue, 27 Oct 2026 17:56:37 +0000

Introduction

Ruby is beloved for its readable syntax and developer happiness, and criticised for its speed. Crystal, released in 2014, asks a simple question: what if you kept Ruby's syntax and compiled it to native code? The result is a statically typed, compiled language that reads almost like Ruby, runs close to C speed, and needs no virtual machine. It is still young, but it is the most elegant answer yet to the dynamic-versus-compiled trade-off.

Ruby-like syntax, static types, and native compilation

Crystal's model rests on a few distinctive ideas:

Ruby-inspired syntax: blocks, symbols, and expressive method calls, so Ruby developers feel at home immediately.
Static typing with inference: types are checked at compile time, but usually inferred, so you get safety without annotating everything.
Macros: code that writes code at compile time, replacing Ruby's metaprogramming with a safer, checked version of the same power.
Native compilation: Crystal compiles to a single binary via LLVM, with no runtime to install, so deployment is a file, not a stack.

A tiny example shows the shape: it reads like Ruby, but the compiler checks it:

# A class with inferred types, compiled to native code
class Greeter
  def initialize(@name : String)
  end
  def greet
    "Hello, #{@name}!"
  end
end
puts Greeter.new("Ayesha").greet
# Hello, Ayesha!

@name : String is a typed instance variable; #{@name} is string interpolation, exactly as in Ruby. Same joy, checked by a compiler, running natively.

The honest trade

Crystal's trade is youth: a small ecosystem, fewer libraries and jobs than Ruby or Go, and tooling that is still maturing. Windows support has historically lagged, and the community is small. Choose Crystal when you love Ruby's syntax but need compiled speed and single-binary deployment, choose Go when ecosystem and hiring dominate, and choose Ruby when the existing ecosystem matters most.

Compiled speed, Ruby syntax

Crystal is Ruby's syntax at compiled speed: inferred static types, macros, and native binaries, in code that reads like Ruby. It trades ecosystem maturity for elegance and performance, and for Rubyists who want speed without leaving home, that trade is tempting.

Originally published at https://practicaldevblog.blogspot.com/2026/10/crystal-explained-rubys-syntax-compiled.html

Clojure Explained: A Modern Lisp on the JVM

The Practical Developer — Tue, 27 Oct 2026 17:49:32 +0000

Introduction

Lisp is the second-oldest programming language still in use, and most programmers have never written it, yet its ideas (code as data, functions as values, macros) shaped everything after it. Clojure, released in 2007, is Lisp rebuilt for the modern world: it runs on the JVM, uses every Java library, and replaces Lisp's mutable lists with immutable data structures. It is the language that convinced a generation of sceptics that parentheses are not a problem: they are the point.

Immutable data, code as data, and the REPL

Clojure's model rests on a few distinctive ideas:

Immutable data by default: maps, vectors, and sets never change in place; "updating" returns a new version, so concurrent code shares data safely and old versions stay available.
Code as data: Clojure code is itself a data structure (lists), so programs can manipulate programs: macros, the feature other languages fake with code generation, are native.
The REPL: develop interactively: evaluate expressions, inspect state, and reshape a running program without restarting it. The REPL is not a toy; it is the workflow.
JVM hosted: every Java library works, so Clojure programs deploy wherever Java does, with none of the ecosystem risk of a niche runtime.

A tiny example shows the shape: a function, a map, and immutable transformation:

;; A user, and a function that "ages" them: returning a new map
(def user {:name "Ayesha" :age 25})
(defn birthday [u]
  (update u :age inc))
(birthday user)
;; => {:name "Ayesha" :age 26}
;; user itself is unchanged: still 25

No mutation, no classes, just data and functions, and the original value is still there, untouched, for any other code that needs it.

The honest trade

Clojure's trade is familiarity and hiring: parentheses and prefix notation take adjustment, startup time is JVM-slow, and the talent pool is small. Error messages, from the JVM stack, can be cryptic. Choose Clojure when immutable data and interactive development matter most, especially for data pipelines and backends, and choose a mainstream JVM language when team familiarity dominates.

Lisp, modernised

Clojure is a modern Lisp on the JVM: immutable data, code as data, and REPL-driven development, with every Java library available. It trades familiarity for simplicity that scales, and for programmers who learn it, parentheses stop looking strange and start looking honest.

Originally published at https://practicaldevblog.blogspot.com/2026/10/clojure-explained-modern-lisp-on-jvm.html

R Explained: The Language That Thinks in Data

The Practical Developer — Tue, 27 Oct 2026 17:47:33 +0000

Introduction

Python does data science well, but R was born for it: created in 1993 by statisticians at the University of Auckland, it thinks in vectors, tables, and distributions the way other languages think in loops and objects. It powers academic research, clinical trials, and data journalism, and its superpower is that the things data people do all day (summarise, filter, plot) are one-liners, not library calls. If your work is data first and software second, R speaks your language natively.

Vectors, data frames, and the tidyverse

R's model rests on a few distinctive ideas:

Vectors everywhere: the basic unit is a vector, not a single value, so operations apply to whole columns at once: add 1 to a vector and every element grows, no loop needed.
Data frames: tables with named columns are a native type, not an add-on, so datasets feel like the language's home turf.
Vectorised statistics: means, models, and distributions are built in, from mean() to linear regression in one function call.
The tidyverse: a coherent family of packages (dplyr for manipulation, ggplot2 for plots) that turned R from a statistics tool into a full data workflow, with readable pipe-based code.

A tiny example shows the shape: filter, summarise, and plot-ready, in a few lines:

# A data frame of exam scores
scores <- data.frame(
  name  = c("Ayesha", "Bilal", "Chen"),
  score = c(88, 72, 95)
)
# Mean score, and the top scorer, with no loops
mean(scores$score)              # 85
scores[scores$score > 80, ]     # Ayesha and Chen

$ reaches a column, [rows, ] filters it, and the whole dataset is one object. That is R's worldview: data first, code second.

The honest trade

R's trade is generality and speed: it is slower than Python for heavy computation, weaker for general-purpose software, and its syntax quirks (multiple assignment styles, inconsistent naming) confuse newcomers. Choose R when statistics, analysis, and publication-quality plots are the job, and choose Python when the job spans data, apps, and production systems.

Thinks in data

R is the language that thinks in data: vectors, data frames, and vectorised statistics, with the tidyverse turning analysis into readable pipelines. It trades general-purpose power for data-native fluency, and for analysts, that fluency is everything.

Originally published at https://practicaldevblog.blogspot.com/2026/10/r-explained-language-that-thinks-in-data.html