DEV Community: Magne

Meta-Programming and Macro capabilities of various languages

Magne — Thu, 02 Apr 2026 19:26:15 +0000

Meta-programming = the broad idea of “programs that manipulate or generate programs”. It can happen at runtime (reflection) or compile-time (macros).

Macros = one specific style of meta-programming, usually tied to transforming syntax at compile time (in a pre-processor or AST-transformer). It takes a piece of code as input and replaces it with another piece of code as output, often based on patterns or parameters. Macros consist of:

Rule‑based transformation: A macro is specified as a pattern (e.g., a template, an AST pattern, or token pattern) plus a replacement that is generated when that pattern is matched.
Expansion, not function call: Macro use is not a runtime call; the macro is expanded before execution, so the final code is the result of replacing the macro invocation with its generated code.

Here are some programming languages and their meta-programming and macro capabilities.

NB! Take with a grain of salt. The result comes from working with perplexity.ai, and I have not had a chance to personally verify all of the cells. They do look generally correct to me overall, though. Corrections are welcome!

Metaprogramming + macro features

Here are the programming languages with their scores (out of 15) and links to their repos or homepages:

Racket: 15
Common Lisp (CL): 13
Scheme (R7RS‑small): 12
Rust: 11
Nim: 10
Clojure: 10
Carp: 9
Jai: 5
C++: 5
Zig: 4
Ruby: 4

Scores are out of 15 = 4 (metaprogramming) + 3 (compile‑time facilities) + 8 (macro features).

Each cell is either ✅ (yes) or – (no / limited).

Feature / language	Racket	Common Lisp	Scheme (R7RS‑small)	Rust	Nim	Clojure	Carp	Jai	C++	Zig `comptime`	Ruby

Metaprogramming features:
Runtime metaprogramming (e.g., open classes, `define_method`, method hooks)	✅	✅	–	–	–	✅	–	–	–	–	✅
Runtime reflection / introspection	✅	✅	✅	–	–	✅	–	–	✅	–	✅
Runtime `eval` / dynamic code loading	✅	✅	✅	–	–	✅	–	–	–	–	✅
Build‑ or tooling‑level code generation supported	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
Metaprogramming score (out of 4):	4	4	3	1	1	4	1	1	2	1	4

Compile‑time facilities (not strictly macros):	Racket	Common Lisp	Scheme (R7RS‑small)	Rust	Nim	Clojure	Carp	Jai	C++	Zig `comptime`	Ruby
Run arbitrary code at compile time	✅	✅	✅	✅	✅	–	✅	✅	✅ (`constexpr`)	✅	–
Types as values at compile time	✅ (– but in Typed Racket)	–	–	✅	✅	–	–	✅	✅ (`constexpr` + templates)	✅	–
constexpr‑style type‑level / compile‑time computation	✅	–	–	✅ (`const`‑eval)	✅	–	✅	✅	✅ (via `constexpr`)	✅	–

Macro features:
Hygienic identifier binding	✅	✅	✅	✅	✅	✅	✅ (gensym but manual)	✅	–	–	–
Operate on AST / syntax tree	✅	✅	✅	✅	✅	✅	✅	–	–	–	–
Pattern‑based transformations	✅	✅	✅	✅	✅	✅	✅	–	–	–	–
Define new syntactic forms	✅	✅	✅	✅	✅	✅	✅	–	–	–	–
Define new keywords / syntax	✅	✅	✅	✅	✅	✅	✅	–	–	–	–
Override core language forms	✅	✅	✅	–	–	–	–	–	–	–	–
Multi‑phase / macros of macros	✅	✅	✅	✅	–	–	–	–	–	–	–
Full‑fledged DSL / language building (via macros)	✅	✅	✅	✅	✅	✅	✅	–	–	–	–

Macro & compile time features score (out of 11)	11	9	9	10	9	6	6	4	3	3	0

Total score	15	13	12	11	10	10	9	5	5	4	4
	Racket	Common Lisp	Scheme (R7RS‑small)	Rust	Nim	Clojure	Carp	Jai	C++	Zig `comptime`	Ruby

The score counts one point per row where the language can reasonably do what the feature describes (DSL‑building is counted as a full feature, even if “limited” in some languages).

The feature score is not an ultimate measure of meta-programming power, since a language (like C++) may have a higher score than another language (like Ruby), but generally be considered less tailored for meta-programming than the other language (Ruby is generally revered for its powerful meta-programming abilities).

Macro features are varied and many, and thus in the total score they gain an undue weight, although runtime meta-programming may be just as, or even more, powerful.

Lisp-style languages (with their homoiconic S-expressions) make out 5 of the 11 languages in our list: Racket, CL, Scheme, Clojure, Carp.

For further reading: https://github.com/oils-for-unix/oils/wiki/Metaprogramming

ReScript vs. Melange

Magne — Mon, 16 Mar 2026 16:05:04 +0000

rescript vs melange in 2026? which to choose and when?

Perplexity.ai answered (which was so good I decided to reshare it):

In 2026, Melange is the better fit if you want OCaml-first, dune/opam integration and sharing code with a backend; ReScript is better if you want a JS/TypeScript-team-friendly language that targets the JS ecosystem directly. github

How they differ

Ecosystem focus:
- Melange: Part of the OCaml world, installed via opam, built with dune, works with ocaml-lsp, ppxlib, etc., and compiles OCaml/Reason to JS. sancho
- ReScript: JS-centric, distributed via npm as prebuilt binaries, positioned as an alternative to TypeScript with strong JS interop. discuss.ocaml
Language and tooling:
- Melange: Uses standard OCaml (or Reason) syntax, leverages OCaml’s type system and tooling; editor support comes “for free” via the OCaml LSP stack. discuss.ocaml
- ReScript: Its own syntax and compiler, historically diverged from Reason/OCaml; has its own editor tooling and build story, more familiar to JS devs but less aligned with OCaml tooling. sancho
Advanced features & evolution:
- ReScript is adding features geared to JS devs like async/await syntax, new representation options, and improvements in JS interop, sometimes at the expense of OCaml compatibility. sancho
- Melange maintains compatibility with OCaml versions and tooling, so it deliberately does not adopt features that would break that alignment. github
Interop and code sharing:
- Melange: Excellent if you want to share types and modules between OCaml backend and JS frontend (via dune, virtual libraries, etc.). discuss.ocaml
- ReScript: Excellent if you primarily integrate with existing JS/React/Node codebases and care less about reusing OCaml libraries. discuss.ocaml

When to choose Melange

Pick Melange if:

You already use OCaml on the backend and want a unified language and tooling front-to-back. discuss.ocaml
You want dune, opam, ocaml-lsp, ppxlib, and the wider OCaml ecosystem to “just work.” discuss.ocaml
You value readable, modular JS output and are comfortable with OCaml-style development rather than JS-style toolchains. github
You may want to keep using Reason syntax or standard OCaml syntax with JSX via community dialects. dev

A concrete example: an OCaml-heavy company like Ahrefs moving their frontend to Melange to align frontend and backend while still using JS UI libraries. discuss.ocaml

When to choose ReScript

Pick ReScript if:

Your team is primarily JavaScript/TypeScript developers, and you want something that feels like “better TypeScript” with strong static typing but JS-first ergonomics. reddit
Your codebase and ecosystem are mostly JS/React, and you don’t need deep OCaml-library reuse or dune/opam integration. discuss.ocaml
You are happy to follow ReScript’s language evolution, even when it diverges from OCaml (syntax and features). sancho

An example: a React SPA team that already lives in npm, Webpack/Vite, and JS tooling, adopting ReScript as a typed language close to their current stack. discuss.ocaml

Quick decision matrix

Situation	Choose	Why
OCaml backend, want shared types/libs with frontend	Melange	OCaml ecosystem integration, dune/opam, same language everywhere. github
Existing JS/React app, TS-style team	ReScript	JS-first tooling, npm distribution, TS-competitor positioning. sancho
Heavy use of OCaml ppx, advanced OCaml tooling	Melange	Full ppxlib and dune support, aligned with OCaml compiler. github
You don’t care about OCaml, just want a typed JS language	ReScript	Focus on JS interop and language features tailored to JS devs. sancho
Long-term bet on OCaml ecosystem (editor, libs, community)	Melange	Developed as an OCaml JS backend, maintained in OCaml community. github

If you tell me more about your current stack (OCaml vs JS, build tool, hosting, team background), I can map you to a very specific recommendation and migration path.

Why did OOP become popular (from a DX perspective)?

Magne — Mon, 27 Oct 2025 15:54:15 +0000

My thoughts:

I propose OOP (class-based, C++, Java, etc.) became popular (more so than FP) because of these DX concerns:

Intuitiveness: humans typically objectify the world (objectification, essentialism). GUI's could naturally be described in OO terms.
Accessibility: It made access/namespacing easy: if you had an object, you could easily and automatically find its behaviors/methods (autocomplete!). It provided even easier (more accessible and natural) modularization than modules with functions.
Domain modeling: It enabled domain modeling (in the language of objects in the domain). Aligned with GUI development.
Organisation: It facilitated code organisation and organisational compartmentalization (coupled behavior to data and encapsulated it). "You are responsible for those things" (vs. the better: "you are responsible for those flows / use cases"). Encapsulation made teams able to refactor internals while the interface/API remained a stable contract (enabling parallel development).
Performance: It allowed mutation (merged with imperative/procedural), which didn't compromise on performance (in perf constrained environments and popular applications like games etc.)
Predictability and reuse: Classes provided a clear interface/template for data, which made handling similar kinds of data more predictable and reusable (inheritance and polymorphism).

Perplexity.ai answer:

Object-oriented programming (OOP) became popular from a developer experience (DX) perspective because it made code more modular, reusable, and maintainable, which are all critical for effective teamwork and long-term project growth. The ability to encapsulate data and abstract away complexity led to simplified development, easier code updates, and clearer project organization.1 7 8

Core DX Benefits of OOP

Modularity: OOP lets developers organize code into distinct, logical units (objects), helping teams work on separate pieces independently without interfering with each other's work.7 1
Reusability: Features like inheritance and polymorphism allow programmers to reuse code, reducing repetition and saving time across projects.6 1
Maintainability: With encapsulation, internal details are hidden, making bugs easier to locate and fix while protecting sensitive data from unexpected changes.1
Abstraction: Developers interact with objects through clear interfaces, reducing the cognitive load and making it simpler to teach, understand, and extend codebases.1
Real-World Modeling: OOP enables clearer modeling of real-world concepts, making complex domains easier to translate into software structures.3

Why Developers Chose OOP

Scalability: Applications built with OOP could more easily adapt to growing requirements and changes, speeding up both feature development and troubleshooting.7 1
Team Collaboration: OOP’s structure facilitated parallel development, letting larger teams contribute without merging conflicts or breaking core functionality.1
Industry Adoption: The prevalence of popular OOP languages (Java, C++, Python) further reinforced its spread, as developers preferred tools with strong IDE, library, and community support.5
GUI and Event-Driven Programming: As user interfaces became central, OOP patterns fit naturally for modeling buttons, menus, and interactive elements.3

These factors combined to make OOP a dominant paradigm, not only for technical reasons but also because it dramatically improved how developers experienced, managed, and scaled software projects.8 7 1

Why did FP not become as popular as OOP (from a DX perspective)?

Functional programming (FP) has not achieved the same mainstream popularity as object-oriented programming (OOP) from a developer experience (DX) perspective due to key challenges around approachability, mental models, and ecosystem adoption. [1] [4] [5]

Challenges for FP Adoption

Steeper Learning Curve: FP relies on abstract concepts like pure functions, immutability, and recursion, which are less intuitive for many developers, especially beginners. OOP's object-based approach more closely mirrors how people think about real-world entities, making it easier for teams to learn and collaborate. [4] [1]
Mental Model Differences: FP separates data from behavior and avoids state changes. While this leads to safer and more predictable code, it can complicate scenarios involving shared state, like working with files, databases, or real-time data streams, which often require side effects. [2] [1]
Tooling and Ecosystem: OOP languages such as Java, C++, and Python dominated industry adoption, offering richer IDE support, better documentation, and large communities, which further improved DX. FP languages often lacked these advantages in mainstream business contexts. [5]
Readability and Maintainability: While FP offers concise code, excessive use of higher-order functions and recursion can make code harder to read and debug for those unfamiliar with the paradigm, leading to slower onboarding and more confusion for teams. [1] [4]
State and Mutability Needs: Many practical business applications require direct management of state and mutable data. OOP’s encapsulation and state-handling patterns are often more effective and familiar for developers building GUIs, games, and large systems with complex interactions. [5] [1]

Key DX Differences: FP vs OOP

Aspect	OOP (DX) Advantage	FP (DX) Challenge
Learning & Onboarding	Easy to explain objects/entities [4]	Abstract maths concepts (recursion, immutability) [4] [1]
Code Organization	Modular, extensible codebases [1]	Compact but may be harder to maintain [4]
Community & Tooling	Larger libraries, better IDE support [5]	Smaller, academia-focused communities [5]
State Handling	Direct and familiar (classes/fields) [5]	Avoids mutation, harder with shared state [2]
Performance & Memory	Efficient for complex, mutable systems [1]	Overhead from immutability [5]

These factors made FP less attractive for DX in most mainstream software development contexts, even though it excels in niche domains such as data transformation and concurrent processing. [4] [1] [5]

How could a new FP language have at least as good DX as OOP without being OOP?

A new functional programming (FP) language could achieve developer experience (DX) at least as good as object-oriented programming (OOP) without actually becoming OOP by focusing on several key design principles and usability enhancements. [1] [2] [4]

Essential Features for Superior FP DX

Intuitive Syntax and Ergonomics: Adopt clean, readable syntax that lowers the cognitive barrier for newcomers, with familiar constructs for both beginners and experts. [4]
Rich Tooling and IDE Support: Provide high-quality debuggers, static analysis, code completion, and refactoring tools, matching the ecosystem strengths of OOP languages. [1]
Explicit and Powerful Data Modeling: Offer strong, expressive types, pattern matching, and algebraic data types so that developers can model business domains naturally, much like classes/objects in OOP, but with immutable data. [1]
Clear State Management: Include ergonomic mechanisms (perhaps via monads, effects, or built-in state-management utilities) to handle state and side effects in a way that feels intuitive and does not require advanced theory for daily use. [1]
First-Class Modules and Composition: Enable modular development via first-class modules, namespacing, and function composition, allowing team collaboration and code reuse with clear boundaries, similar to OOP packaging and interfaces. [2]
Concise Interop and Practical Libraries: Prioritize interoperability with existing systems and provide rich standard libraries for common tasks (GUI, database, networking), helping developers immediately solve practical problems. [1]
Declarative UI and Event Handling: Make building user interfaces and event-driven programs as seamless as in OOP by using pure, compositional approaches (e.g., Elm, React-style architectures). [1]
Strong, Accessible Documentation: Invest in clear guides, tutorials, and onboarding resources that demystify functional concepts and patterns for developers from OOP backgrounds. [1]

Key Principles to Emphasize

Pure functions for predictability and easy testing. [2] [1]
Immutability to prevent certain classes of bugs, with simple, ergonomic data updating. [1]
Higher-order functions and composition for modularity, without unnecessary academic jargon. [2] [1]
Declarative style for clarity and maintainability. [1]
Built-in support for recursion, effect management, and concurrency that feels natural in large-scale application development. [1]

By proactively addressing usability, approachability, and real-world application integration—while keeping FP's strengths—such a language could offer an excellent DX that rivals, and even surpasses, traditional OOP environments without relying on OOP constructs. [4] [2] [1]

Why necessarily "first-class modules"?

First-class modules are necessary in a new FP language aiming for excellent DX because they allow the modular organization and flexible composition of code at runtime, without adopting OOP’s class-based approach. This capability helps teams create scalable, maintainable, and collaborative projects by treating modules as values that can be passed, stored, and dynamically selected—much like functions in FP, but for entire feature sets or data models (3, 6).

Why First-Class Modules Matter in FP

Modularity without OOP: Unlike OOP, which uses classes and objects to encapsulate state and behavior, FP relies on composition and separation of concerns. First-class modules provide an alternative by allowing groups of related functions, types, and data to be packaged together and manipulated as units, increasing code reuse and adaptability (6, 3).
Dynamic Composition: Developers can pass modules to functions, store them in data structures, or swap implementations at runtime. This flexibility enables plugin architectures, runtime configuration, and testing scenarios that mimic OOP’s extensibility, but stay in the FP paradigm (3, 6).
Type Safety and Abstraction: First-class modules can encapsulate type definitions and provide strong abstraction boundaries, supporting safe, predictable evolution of codebases as requirements change (7, 3).
Collaboration and Scaling: Large teams benefit from clear modular boundaries, enabling parallel development and easier code management—a core DX advantage in any mature language ecosystem (6, 3).

Thus, first-class modules help FP languages deliver the same DX strengths as OOP—modularity, organization, extensibility, and collaboration—without relying on objects, and fit naturally within the functional paradigm (7, 3, 6).

Solito 5 is now web-first (but still unifies NextJS and React Native)

Magne — Wed, 22 Oct 2025 14:21:50 +0000

What is Solito?

"Navigation is the hardest piece of sharing code across platforms. Web has plain URLs for navigation state, whereas apps have complex sets of nested navigation patterns (stacks, tabs, modals, drawers). By combining the approaches into a single mental model and API, devs can build for Web and Mobile with ease. This is touched on at length in the "Methodology" and "Gradual Adoption" sections of the Solito docs.

The gap between web devs and native devs is shrinking. This stack enables you to ship native apps and websites with a single codebase. I'm the only frontend engineer at our startup, and I was able to do just that as we scaled to thousands of users (see https://beatgig.com). My goal with Solito is to 1) provide the code to let others do it, and 2) perhaps more importantly, document clear patterns to deal with platform differences.
"

-- fernandorojo @ Hacker News

With the launch of Solito v5, it drops the direct dependency on React Native for Web.

See Fernando's tweet of the release of Solito v5:

// Detect dark theme var iframe = document.getElementById('tweet-1980786809702609159-208'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1980786809702609159&theme=dark" }

That prompts some questions...

Why use Solito on web with pure NextJS, if Solito is precisely for cross-platform development?

Grok AI’s answer to:

> What is the utility of using Solito on web with pure NextJS? Couldn’t you just not use Solito? Isn’t Solito precisely for using React Native stuff on web (and vice versa)?

—-

Background context:

Solito 5 introduces a web-first approach by dropping the react-native-web dependency, allowing seamless integration into any Next.js app without configuration while maintaining unchanged native functionality for iOS and Android.
Major updates include support for Next.js 16 and Expo SDK 54, a shift to .native.tsx files for platform-specific code, and fixes like useSearchParams() on native, simplifying monorepo setups as shown in the updated starter template.
Originally launched in 2022 by Fernando Rojo to enable shared navigation patterns across web and mobile, this release builds on prior iterations like Zeego, addressing bundler complexities and enabling broader adoption in production cross-platform projects.

—-

The answer:

Let’s dive into the utility of using Solito on the web with pure Next.js, especially given its roots in React Native integration, and clarify how it fits into a web-only context as of today, October 22, 2025.

Background on Solito

Solito was originally created by Fernando Rojo to bridge the gap between React Native and Next.js, enabling developers to share navigation and UI logic across web and mobile platforms. It leverages React Navigation for native apps and Next.js Router for the web, providing a unified API to manage navigation patterns (e.g., stacks, tabs, modals) that differ between the two environments. Its initial design was heavily tied to React Native, often requiring react-native-web to render React Native components on the web.

Solito 5 and the Web-First Shift

With the release of Solito 5 (announced on October 21, 2025, via the target post), a significant evolution has occurred. Solito 5 drops the react-native-web dependency from its core components, making it web-first. This means it now operates as a pure Next.js solution on the web, with platform-specific code (e.g., native features) isolated to .native.tsx files. This shift simplifies the setup for web-only projects while retaining compatibility with React Native for those who need it.

Utility of Solito on Web with Pure Next.js

Even in a web-only Next.js context, Solito offers several practical benefits:

Unified Navigation Patterns:
- Solito provides a consistent navigation API inspired by React Navigation, which can be more intuitive for developers familiar with mobile patterns. This is particularly useful if your team works across web and mobile or if you plan to extend to native later. For example, Solito’s <Link> component can serve as a drop-in replacement for Next.js’s <Link>, offering a unified experience that aligns with its cross-platform philosophy.
- It handles complex navigation scenarios (e.g., modals, stacked screens) that go beyond Next.js’s flat, page-based routing, giving you more flexibility to mimic native-like navigation on the web.
Future-Proofing and Scalability:
- If you’re building a web app today but anticipate adding React Native support later, starting with Solito minimizes refactoring. Since Solito 5 is designed to work without react-native-web on the web, you can adopt it now and seamlessly extend to native by adding .native.tsx files and dependencies like Expo when needed.
- The release notes highlight its compatibility with Next.js 16 and Expo SDK 54, ensuring it stays current with modern frameworks, which is a boon for long-term projects.
Simplified Monorepo Setup:
- Solito 5 includes an updated Expo 54 starter monorepo, which, while aimed at cross-platform devs, also streamlines code organization for web-focused teams. Even if you ignore the native parts, the monorepo structure can help manage shared logic (e.g., components, hooks) across different parts of a large Next.js app.
Enhanced Developer Experience:
- Solito’s web-first approach reduces bundler complexity (e.g., no more index.web.tsx files), which can lead to faster build times and fewer configuration headaches, even in a pure Next.js setup.
- The migration guide and breaking changes (e.g., dropping TextLink defaults) encourage clean, explicit styling and props, promoting better code maintainability—a win for any web project.
Community and Ecosystem Alignment:
- Since Solito is backed by Fernando Rojo and has a growing community (evidenced by the positive reactions in the thread), it integrates well with other libraries like @expo/router or Tailwind, as seen with Zeego’s compatibility. This makes it a robust choice for web devs looking to leverage a battle-tested tool.

Isn’t Solito for React Native Stuff?

You’re right to question this—Solito’s origins are indeed tied to React Native. Historically, its primary value was enabling React Native developers to share code with Next.js apps, using react-native-web to render native components on the web. However, Solito 5 redefines its scope. By dropping react-native-web as a dependency, it’s no longer reliant on React Native rendering on the web. Instead, it positions itself as a versatile framework that:

Works standalone on Next.js for web apps.
Remains compatible with React Native for native apps, but only if you opt into that ecosystem.

This dual nature means Solito isn’t just for React Native anymore—it’s a tool for unifying development workflows, whether you stay web-only or expand to mobile. The web-first design ensures it doesn’t force React Native paradigms (like View or Text components) onto your Next.js app unless you choose to.

Practical Example

Imagine you’re building a Next.js e-commerce site. With Solito 5, you could use its <Link> component for navigation, benefiting from its ability to handle modal overlays (e.g., a cart popup) in a way that feels native-like. If your business later decides to launch an iOS app, you can extend the same navigation logic to React Native with minimal changes, leveraging Solito’s .native.tsx files. Without Solito, you’d need to rewrite navigation for mobile, potentially duplicating effort.

Caveats

Overhead for Web-Only: If you’re strictly web-focused and happy with Next.js’s built-in routing, Solito might add unnecessary complexity. Its value shines when you need advanced navigation or plan for cross-platform growth.
Learning Curve: The shift to web-first requires understanding its new conventions (e.g., no default styles on TextLink), as outlined in the migration guide.
Dependency: While react-native-web is dropped, some third-party React Native libraries you might use alongside Solito could still require it, so check your stack.

Conclusion

Using Solito on the web with pure Next.js is about leveraging a unified, future-proof navigation system that aligns with modern cross-platform trends, even if you start web-only. It’s not just for React Native anymore—it’s a strategic choice for developers who value flexibility, scalability, and a consistent API across potential future expansions. If your project is unlikely to go native and you’re satisfied with Next.js’s default routing, you might not need it. But for anyone eyeing a hybrid future or craving more navigation power, Solito 5’s web-first approach makes it a compelling tool.

—-

> Can you use web stuff on native by using solito?

Your question seems to be asking whether you can use web-specific features or components on the native (React Native) side by using Solito, or perhaps vice versa—using native features on the web. Based on the context of Solito 5 (released on October 21, 2025, as per the target post) and the ongoing discussion, I’ll interpret this as: Can Solito enable the use of web-specific ("web stuff") functionality or components in a native React Native environment, or allow native features to work on the web? Let’s break this down step by step, considering the current state of Solito 5 as of 04:06 PM CEST on Wednesday, October 22, 2025.

Solito 5 Overview

Solito 5, as introduced by Fernando Rojo, is now a web-first framework that drops the react-native-web dependency from its core components. This means it operates natively on Next.js for the web without relying on React Native rendering, while still supporting React Native for iOS and Android via platform-specific files (e.g., .native.tsx). The goal is to simplify cross-platform development by allowing shared logic and navigation, with clear separation between web and native implementations.

Can You Use Web Stuff on Native with Solito?

The short answer is no, not directly, but let’s explore why and how you can approach this.

Why Not Directly?

Platform Separation: Solito 5 enforces a clear distinction between web and native. Web-specific features (e.g., Next.js Server Components, useSearchParams(), or browser APIs like window) are designed to work in a Next.js environment, which relies on a DOM. React Native, however, uses a different rendering engine (e.g., Yoga for layout, native UI components) and lacks a DOM, making web-specific APIs incompatible without additional layers like react-native-web.
Dropped react-native-web: Previously, Solito relied on react-native-web to render React Native components on the web. With Solito 5 dropping this dependency, the web side no longer uses React Native’s rendering pipeline. Conversely, the native side doesn’t inherit web capabilities unless explicitly bridged.
File-Based Isolation: Solito 5 uses file extensions like .native.tsx for platform-specific code. Web-specific logic (e.g., in .web.tsx or default .tsx files) is ignored on native, and native-specific code is ignored on web. This prevents direct use of web "stuff" (e.g., Next.js hooks or components) on native.

Workarounds to Use Web-Like Features on Native

While you can’t use web-specific APIs or components directly on native, Solito’s design allows you to share logic and abstract functionality in a way that mimics web behavior on native where possible:

Shared Utility Logic:

Write platform-agnostic code (e.g., in a shared .ts or .tsx file) that adapts to the environment using runtime checks. For example:

 import { Platform } from 'react-native';

 const getParam = (key: string) => {
   if (Platform.OS === 'web') {
     return new URLSearchParams(window.location.search).get(key);
   }
   // Fallback for native (e.g., use React Navigation params)
   return null;
 };

This allows you to simulate web-like behavior (e.g., query params) on native, though you’d need to implement native equivalents (e.g., via React Navigation’s route params).

Custom Components with Conditional Rendering:

Create a shared component that uses conditional logic to render web-specific JSX on the web and native-compatible alternatives on mobile. For instance:

 import { Platform } from 'react-native';

 const MyLink = ({ href, children }) => {
   if (Platform.OS === 'web') {
     return <a href={href}>{children}</a>; // Web-specific
   }
   return <Text onPress={() => {/* native navigation */}}>{children}</Text>; // Native equivalent
 };

Solito’s navigation API (e.g., <Link> or <Stack.Screen>) can help unify this, but you’d need to handle platform-specific navigation logic.

Leveraging Expo or Third-Party Libraries:
- Expo SDK 54 (supported by Solito 5) provides web-like features for React Native, such as Web APIs (e.g., localStorage via expo-secure-store analogs). You could use these to approximate web functionality on native, though they’re not identical to browser-native implementations.
Monorepo Shared Code:
- In a Solito monorepo, you can place web-specific code in a web/ directory and native-specific code in a native/ directory. Use a shared layer (e.g., shared/) to export utilities or components that adapt to both platforms, reducing the need to duplicate effort.

Limitations

Incompatible APIs: Web-only features like Server-Side Rendering (SSR) with Next.js or browser events (e.g., onWheel) won’t work on native without significant polyfills or workarounds, which may not be worth the effort.
Performance: Emulating web behavior on native can introduce overhead or inconsistent UX, as native apps are optimized for touch/gesture interactions rather than mouse/keyboard events.
Complexity: Adding web-like functionality to native requires careful abstraction, which might negate some of Solito’s simplification benefits.

Can You Use Native Stuff on Web with Solito?

The reverse—using native "stuff" (e.g., React Native components like View, Text, or native modules) on the web—is also not directly supported in Solito 5 due to the dropped react-native-web dependency. However:

Historical Context: Earlier Solito versions relied on react-native-web to render native components on the web, allowing you to use View, Text, etc., with some styling adjustments. Solito 5 removes this, so native components no longer render on the web by default.
Workaround: You could reintroduce react-native-web as a project dependency and configure it manually, but this contradicts Solito 5’s web-first philosophy and adds complexity. Alternatively, use a library like react-native-web-lite or rewrite native components as HTML/CSS equivalents for the web.

Solito’s Intended Use

Solito 5 is designed to unify development experience and navigation logic across web and native, not to make web and native environments interchangeable. The utility lies in:

Sharing code (e.g., business logic, styles, navigation structure) between platforms.
Allowing a smooth transition from web-only to cross-platform with minimal refactoring.
Providing a consistent API (e.g., <Link>, <Stack>) that abstracts platform differences.

If your goal is to use web-specific features on native or vice versa, Solito facilitates this indirectly through shared abstractions rather than direct feature porting.

Practical Example

Suppose you want to use Next.js’s useSearchParams() on native:

On web, it works out of the box with Solito 5’s web-first setup.
On native, you’d need to replicate this with React Navigation’s route.params or Expo’s routing system. Solito’s monorepo structure lets you define a custom hook like:

  import { useRoute } from '@react-navigation/native';

  export const useCustomParams = () => {
    const route = useRoute();
    return route.params || {};
  };

Use this hook in both web and native contexts, with web falling back to useSearchParams() via a conditional import.

Conclusion

With Solito 5, you cannot directly use web "stuff" (e.g., Next.js APIs, DOM features) on native or native "stuff" (e.g., React Native components) on web without additional configuration or polyfills, as it prioritizes platform separation over feature unification.

The answer:

However, you can share logic and create platform-adapted implementations using Solito’s file-based structure and navigation API. This makes it ideal for projects where you want to start web-only with Next.js and later add native support, rather than forcing web-native interoperability.

What is PhotonJS?

Magne — Wed, 22 Oct 2025 13:59:51 +0000

Here are some clarifying answers from my session with perplexity.ai, edited for your convenience and saved here for posterity.

The Photon we are talking about:

photonjs.dev with source code at
https://github.com/photon-js/photon

The problem PhotonJS solves:

PhotonJS.dev is needed because not every JS based server can be deployed directly on every platform without additional work. Different server frameworks and deployment platforms have variations and incompatibilities in:

APIs for handling requests and responses
Environment constraints (e.g., edge versus Node.js, serverless versus long-running)
Deployment formats and packaging (containers, serverless functions, VMs)
Network and security specifics, lifecycle management, and support tools.

Photon acts as a unifying layer that abstracts these differences, providing a consistent developer experience and deployment workflow across multiple environments. Without such a layer, developers must often rewrite or heavily adapt their code for each platform.

Why Photon Matters

It saves development time and complexity by allowing one codebase to run on many deployment platforms (Cloudflare Workers, Vercel, Express servers, etc.).
It handles environment-specific quirks and APIs behind the scenes via adapters, so developers don’t need to manually tailor their servers to each host.
It enables easier integration with modern tooling like Vite and supports multiple server environments seamlessly.
Ensures consistent behavior and performance across platforms, improving reliability and security.

In Short

Though technically you can deploy many servers on many platforms, without a framework like Photon, you face significant manual effort, fragmentation, and platform lock-in. Photon solves this by providing a flexible, adapter-based abstraction that lets servers run everywhere with minimal changes.

The reasons it is needed and cannot be replaced by just deploying any server on any platform are:

Server frameworks differ in their request handling APIs, lifecycle, and runtime requirements, and each deployment platform (e.g., Vercel, Cloudflare Workers, Express servers) has its own environment constraints — Photon standardizes these differences with a core logic and adapter system to avoid rewriting code per platform.

Photon creates a flexible abstraction that lets developers write code once and deploy that same codebase seamlessly across multiple server and deployment environments by changing adapters instead of code.

So Photon is a framework-level solution enabling cross-platform server deployments. It fills a specific niche in JavaScript/TypeScript web development to unify server and deployment platform differences.

Think of Photon JS as a multiport adapter where you can choose one of multiple inputs (servers), and one of multiple outputs (deployment platforms/infrastructure). Alternatively: think of PhotonJS as a digital crosspoint switch.

Comparing Photon as a multiport adapter to an electric socket multiport adapter is a useful analogy:

Electric Socket Multiport Adapter

Purpose: Converts one electric socket into multiple sockets so multiple devices can plug in simultaneously.
Inputs/Outputs: Takes one power source input, provides multiple physical output ports.
Role: Acts as a physical bridge allowing diverse devices to share a common electricity source.
Flexibility: Supports different plug types and sometimes voltage conversion; enables hardware compatibility without changing the devices.

Photon as Multiport Adapter

Purpose: Provides a core framework that supports using multiple server adapters and deployment adapters.
Inputs/Outputs: Acts as the "bridge" between multiple backend frameworks (inputs) and multiple deployment environments (outputs).
Role: Defines common logic and interfaces that allow diverse server and deployment targets to integrate seamlessly.
Flexibility: Enables developers to write code once and deploy it anywhere by managing environment differences via adapters.

Summary Comparison Table

Aspect	Electric Socket Multiport Adapter	Photon Multiport Adapter (Metaphor)
Input	One electrical power socket	Multiple backend server frameworks
Output	Multiple physical sockets to plug devices	Multiple deployment environments/platforms
Function	Distributes power to multiple devices	Distributes app logic to multiple runtimes
Acts as	Hardware bridge	Software abstraction and runtime coordination
Supports diversity	Different plug shapes, sometimes voltage conversion	Different server frameworks and deployment targets
Purpose	Physical connectivity	Deployment and runtime flexibility
User scope	End users with devices	Framework authors and developers

In essence, just like an electric multiport adapter allows diverse electrical devices to plug into one power source, Photon allows diverse backend environments to "plug into" a single unified application framework by acting as a flexible multiport software adapter.

Yes, Photon can be described as a kind of multiport adapter with multiple inputs and outputs. It acts as the core abstraction layer that defines standard interfaces (ports) for inputs and outputs, and then separately implemented adapters handle the actual integration with various server frameworks and deployment platforms.

In architecture terms (similar to Hexagonal or Ports and Adapters architecture), Photon’s core codebase provides ports—the defined APIs and runtime logic—while the server adapters and deployment adapters are the external adapters implementing those ports for specific environments.

So Photon itself handles the common logic and coordination ("multiple ins and outs"), while the adapters handle the specifics of interacting with particular incoming requests or outgoing deployment targets. This design enables easy extension and flexibility across many backend and deployment scenarios without changing the core framework logic.[4][9]

Thus, Photon is effectively a multiport adapter infrastructure that supports multiple inputs (different server frameworks) and outputs (different deployment environments) through well-defined interfaces and adapter implementations.

Photon is best described as a deployment-agnostic infrastructure and framework toolkit aimed at making JavaScript server deployment flexible and cross-compatible. It is not in itself a separate/dedicated platform for hosting or deploying applications directly (like Vercel, Netlify, Cloudflare, AWS, GCP, Hertzner etc.).

The Photon project at photon-js/photon is a JavaScript web framework toolkit designed to make it easy for developers to build modern, framework-agnostic web apps that integrate well with Vite and various web servers and deployment environments.

What Photon Does

Photon acts as a unifying tool that helps web framework authors or developers:

Connect frontend build tools (like Vite) with backend frameworks.
Simplify integration across different environments like Cloudflare Workers, Vercel, or Node.js servers.
Provide pre-built adapters for popular server frameworks such as Express, Fastify, Hono, and Elysia, so the same codebase can run almost anywhere.

Explained Like You’re 5 Years Old (ELI5)

Imagine you have a bunch of different types of LEGO bases — one for your house, one for your car, one for your spaceship — and you want the same LEGO tower to fit on all of them. Photon is like a universal LEGO connector that lets your tower (web app) fit neatly on any base (Cloudflare, Express, Vercel, etc.) without rebuilding it each time.

How It’s Structured

Core: The heart of Photon, including Vite integration and general logic.
Runtime: Helper functions useful for framework developers.
Server Adapters: Pieces that make Photon work with different backend frameworks (Express, Hono, Fastify, etc.).
Deployment Adapters: Allow the same app to deploy easily on platforms like Vercel and Cloudflare Workers.

In Short

Photon is a (currently beta-stage) meta-framework toolkit that helps developers make flexible web frameworks that run the same code across many environments. It’s written mainly in TypeScript, which makes it developer-friendly and consistent across Node.js and edge environments.

What Photon actually contains code-wise:

Photon itself (as in the photon-js/photon project) isn’t a deployment adapter or runtime layer — it’s the core coordination layer that defines the shared logic, interfaces, and build system for all the adapters. Essentially, it contains the glue code that makes the different adapters (server and deployment) interoperable.

Here’s what Photon actually contains code-wise:

1. Core Package (`packages/core`)

This is the heart of Photon:

Provides the Vite integration so frameworks built with Photon can use Vite seamlessly within both Node and edge environments.
Exposes core abstractions like build hooks, file routing utilities, and module loading logic that adapters depend on.
Defines environment detection and API for runtime context (e.g., isServer, isEdge, isBrowser).

Think of this as the shared foundation that hides differences between deployment targets.

2. Runtime Package (`packages/runtime`)

This provides common runtime helpers:

Functions used inside user frameworks for handling requests, responses, and rendering pipelines.
Lightweight runtime utilities that work independently from any specific adapter, often exported to end users.

3. Adapter Interfaces

While Photon itself doesn’t directly contain adapter code, it defines TypeScript interfaces and base classes that each specific adapter (e.g., Express or Cloudflare) must implement.

This ensures that each adapter behaves consistently.

4. Tooling and Dev Features

Photon’s repo includes:

Shared developer utilities for testing and local development.
Configurations for monorepo management (via pnpm workspaces or TurboRepo).
Build scripts that bundle all the pieces cohesively for framework authors.

Summary

Photon’s own codebase is mainly:

Vite integration logic
TypeScript interfaces for adapters
Runtime utilities shared by all environments
A monorepo setup to compile, test, and bundle these packages

So, rather than being an adapter itself, Photon defines the infrastructure spine — the base code and contracts that allow independent server and deployment adapters to work together smoothly.

Referential transparency with mutation

Magne — Tue, 22 Jul 2025 14:40:40 +0000

From a conversation with perplexity.ai about a hypothetical programming language.

Referential transparency is the ability to replace a function call with its return value without affecting the program’s behaviour elsewhere (i.e. no side-effect).

Referential transparency is considered a staple in pure functional programming. It typically assumes immutability. But mutability is often more efficient than immutability, since it involves changing data structures in-place rather than always having to create copies.

So, could referential transparency be combined with mutability, if the language was sufficiently restrictive..?

—-

If a function mutates its input but is forced to return that mutated input as part of its result, and if the caller is constrained to never reuse the original input after calling the function, then this can preserve referential transparency despite the mutation.

This is because:

If the mutation is local and encapsulated within the function’s scope and the mutated value is immediately returned and used, then the outside program never observes the mutation except via the returned result.
The caller discards the old input reference and only uses the returned mutated version, so the externally observable behavior is consistent and predictable.
Practically, the mutation is "hidden" inside the function and the function's interface looks like it produces a new value, preserving functional purity in an external view.

This approach aligns with the insight that local mutation inside a function is allowed if it doesn't leak observable side effects — the function then behaves like a pure function and remains referentially transparent.

For example, an in-place reversal function that takes an array, mutates it internally, and returns it, while the caller uses only the returned array and never reuses the original, can be considered referentially transparent even though it mutates internally[1].

In summary:

Condition	Result
Function mutates input and returns it	Potential mutation exposed
Caller reuses original input after call	Breaks referential transparency
Caller discards original input, uses returned value	Preserves referential transparency if mutation is local and encapsulated

Thus, mutation inside a function combined with a strict contract on caller usage can preserve referential transparency, even though strictly speaking the function is not pure (since it mutates state internally). This is a subtle but important distinction in functional programming[1][3].

References
References:

[1] Mutation allowed internally if local and hidden, preserving referential transparency

[3] Referential transparency definition and differences with purity

[4][5][6] Definitions of referential transparency and pure functions

[1] https://betterprogramming.pub/your-code-should-read-like-a-story-how-to-mutate-state-and-have-effect-on-the-world-while-3e3ae808d2d6
[2] https://www.reddit.com/r/functionalprogramming/comments/10k28tm/example_of_a_function_that_has_referential/
[3] https://stackoverflow.com/questions/4865616/purity-vs-referential-transparency
[4] https://www.java-success.com/01-scala-functional-programming-basics-pure-functions-referential-transparency-side-effects-etc/
[5] https://dev.to/ruizb/function-purity-and-referential-transparency-7h1
[6] https://adabeat.com/fp/referential-transparency/
[7] https://www.edward-huang.com/functional-programming/tech/programming/scala/2020/01/30/pure-function-vs-referential-transparency/
[8] https://en.wikipedia.org/wiki/Pure_function
[9] https://colofabrix.github.io/the-road-to-fp/04_pure_functions.html
[10] https://blog.stackademic.com/functional-programming-immutability-and-pure-functions-1d52395353fb?gi=1c3e8037bd09

—-

Code example

Here's a clear JavaScript example illustrating the concept where a function mutates its input internally but returns it, and the caller does not reuse the original input after the function call. This setup preserves referential transparency from the caller's perspective, even though the function performs mutation internally:

// Function that mutates its input array in-place, then returns it
function reverseInPlace(arr) {
  let left = 0;
  let right = arr.length - 1;

  while (left < right) {
    // Swap elements - mutation happens here
    const temp = arr[left];
    arr[left] = arr[right];
    arr[right] = temp;

    left++;
    right--;
  }

  return arr; // returns the mutated array
}

// Original array
const original = [1, 2, 3, 4];

// Caller does NOT use 'original' after this call, only uses returned value
const reversed = reverseInPlace(original);

console.log(reversed); // [4, 3, 2, 1]
// original === reversed, but caller only uses 'reversed', not 'original'

Why this preserves referential transparency here:

The function call reverseInPlace(original) can be replaced with reversed everywhere in the code without changing behavior since the caller uses only the returned value after mutation.
The caller abandons the original input reference and treats the returned mutated array as the new value.
The mutation is internal to the function's scope and does not produce side effects observable outside beyond the returned result.
As a consequence, for any given input array that the caller will no longer access after the call, the output is deterministic and no externally visible unexpected mutation occurs.

References

Reference from search results:

Local mutation inside a function that returns the mutated value is considered an implementation detail that doesn't violate functional purity if the interface is pure (i.e., no visible side effects)[1][3].
Mutation is acceptable inside a function if it is internal and encapsulated and no external shared state is modified[3].

This example fits the pattern you asked about, where mutation happens but referential transparency is preserved by restricting the caller from reusing the original input.

[1] https://dev.to/macsikora/data-mutation-in-functional-javascript-1h97
[2] https://github.com/Manish-Giri/FreeCodeCamp/blob/master/curriculum/challenges/english/02-javascript-algorithms-and-data-structures/functional-programming/avoid-mutations-and-side-effects-using-functional-programming.english.md
[3] https://dev.to/macsikora/mutation-is-ok-3e00
[4] https://www.reddit.com/r/functionalprogramming/comments/rswsa6/how_to_handle_mutable_state_in_a_pure_functional/
[5] https://stackoverflow.com/questions/28792326/functional-style-javascript-good-practice-to-avoid-argument-mutation/28792393
[6] https://cs.brown.edu/courses/cs016/static/files/lectures/slides/18-functional-programming.pdf
[7] https://softwareengineering.stackexchange.com/questions/351593/automatically-convert-mutations-in-imperative-code-into-functional-actions
[8] https://maryrosecook.com/blog/post/a-practical-introduction-to-functional-programming
[9] https://ethankent.dev/posts/mutation_scopes/
[10] https://stackoverflow.com/questions/25777592/avoid-mutation-in-this-example-in-f

What if multiple functions use the same input?

Then all but the last one must take a copy of the input. The last one is allowed to mutate the input. All calls are thus referentially transparent wrt. the program as a whole.

function reverseInPlace(arr) {
  let left = 0;
  let right = arr.length - 1;

  while (left < right) {
    const temp = arr[left];
    arr[left] = arr[right];
    arr[right] = temp;
    left++;
    right--;
  }
  return arr;
}

const original = [1, 2, 3, 4];

// First call: copy original so original remains unmodified
const r1 = reverseInPlace([...original]);
console.log('r1:', r1);            // [4, 3, 2, 1]

// Second call: last use of original, so safe to pass original without copy
const r2 = reverseInPlace(original);
console.log('r2:', r2);            // [4, 3, 2, 1]

// After second call, original is mutated but not used afterward

Could parentheses be a reason Lisp is hard to read?

Magne — Thu, 20 Mar 2025 13:03:19 +0000

Many in the communities of Lisp-style languages (Lisp, Clojure etc.) seem to discount parentheses being a reason for people not adopting Lisp. (It must only be the unfamiliarity of FP! You get used to the parentheses, and see past them!) Even though newcomers frequently complain about all the parentheses (of Lisp S-expressions), and several people have attempted to make an indentation-based Lisp (I-expressions, T-expressions aka. Sweet expressions, Cirru, Wisp, etc.). So there must be something to it, or..?

Shared from perplexity.ai :

—-

Reasons why developers might find heavily nested parentheses in Lisp harder to read, and how the Python equivalent addresses that issue.

1. Visual Clutter

Lisp Example:

(defun complex-calculation (x y z)
  (+ (* (- x y) (/ z 2)) (sqrt (abs (- (* x x) (* y y))))))

Why it's hard to read in Lisp:

The parentheses dominate the visual space, making it difficult to focus on the actual logic of the computation. You have to mentally parse which parentheses belong to which operation, and this can be overwhelming in more complex expressions.

Python Example:

def complex_calculation(x, y, z):
    return (x - y) * (z / 2) + math.sqrt(abs(x**2 - y**2))

Why Python is clearer:

Python uses operator precedence and infix notation (+, -, *, /) instead of prefix notation (+, *, etc.). This reduces the need for explicit grouping with parentheses. The mathematical operators are familiar and visually intuitive, making the expression easier to read at a glance.

2. Lack of Visual Cues

Lisp Example:

(if (and (> x 0) ( 0 and y  a b)
      (+ (- a (* b c)) (/ (+ a b) c))
      (- (* a b) (/ (- b c) a))))

Why it's hard to read in Lisp:

With multiple levels of parentheses nested within an if statement, it becomes difficult to match opening and closing parentheses at a glance. Misplacing or omitting just one parenthesis can lead to errors that are hard to debug.

Python Example:

def nested_function(a, b, c):
    if a > b:
        return (a - (b * c)) + ((a + b) / c)
    else:
        return (a * b) - ((b - c) / a)

Why Python is clearer:

Python uses indentation and blocks instead of parentheses for structure. The logical separation between the if and else branches is clear. Parentheses are only used for grouping where necessary, making them easier to match visually.

Sidenote:

In postfix syntax (similar to a stack-based language like PostScript) the Lisp would look like:

((a (b c *) -) ((a b +) c /) +)
((a b *) ((b c -) a /) -)

5. Reduced Readability

Lisp Example:

(loop for i from 0 to 10
      when (evenp i)
        collect (list i (expt 2 i))
      else
        collect (list i (1+ i)))

Why it's hard to read in Lisp:

The combination of nested parentheses and keywords like collect makes it harder to follow what’s happening at each step of the loop. The logic is compact but not immediately intuitive because everything is expressed as nested expressions.

Python Example:

result = []
for i in range(11):
    if i % 2 == 0:
        result.append([i, 2**i])
    else:
        result.append([i, i+1])

Why Python is clearer:

Python's loop syntax separates each part of the logic into distinct lines (for, if, else). The use of indentation makes it easy to see what happens under each condition without needing to mentally parse nested constructs.

6. Limited Expression of Precedence

Lisp Example:

(setq result (+ (* 2 (- 5 3)) (/ 10 (+ 2 3))))

Why it's hard to read in Lisp:

In Lisp's prefix notation, every operator requires explicit grouping with parentheses. This makes it harder to intuitively understand operator precedence because there’s no visual shorthand like infix operators provide.

Python Example:

result = 2 * (5 - 3) + 10 / (2 + 3)

Why Python is clearer:

Python uses standard mathematical notation with infix operators (+, -, *, /) that inherently express precedence rules without requiring extra grouping symbols. This makes the expression more natural and easier for most developers to understand.

Edit:
Actually, I'd argue that the need for precedence rules (due to infix syntax) is a bad thing since it indicates ambiguity. So it is a good thing to have a syntax (prefix or postfix) that makes the order of computation so clear it doesn't need precedence rules. The problem with Lisp syntax comes when using inherently infix operators (plus +, minus -, times * etc.) in a prefix language like Lisp. Better to go by the more declarative names addition and subtraction. It is not as confusing to read as it looks more like regular function calls:

(setq result (add (mul 2 (sub 5 3)) (div 10 (add 2 3))))

7. Indentation Challenges

Lisp Example:

(defun process-data (data)
  (let ((processed
          (remove-if
            #'null
            (mapcar
              #'(lambda (item)
                  (when (valid-item-p item)
                    (transform-item item)))
              data))))
    (sort processed #'item-compare)))

Why it's hard to read in Lisp:

Proper indentation is critical here because it’s the only way to visually separate different parts of the code. Without clear indentation or if indentation is inconsistent, it becomes nearly impossible to follow what’s happening at each level of nesting.

Python Example:

def process_data(data):
    processed = [transform_item(item) for item in data if valid_item(item)]
    return sorted(processed, key=item_compare)

Why Python is clearer:

Python enforces consistent indentation as part of its syntax rules. This ensures that code blocks are visually distinct and easy to follow without relying on parentheses or other delimiters.

Conclusion

In each case:

Lisp's reliance on heavy nesting and uniform syntax creates challenges related to readability, cognitive load, and debugging.
Python addresses these issues by using features like indentation, infix operators, keywords (if, for), and breaking logic into smaller steps.

This comparison highlights why many developers perceive Lisp's syntax as harder to read while appreciating Python's more structured approach!

Answer from Perplexity: https://www.perplexity.ai/search/8f98d153-997c-4cca-8236-2ea8c2149ca6?utm_source=copy_output

Dynamic memory allocation - when, why and woes

Magne — Thu, 13 Mar 2025 12:12:49 +0000

Sharing a good answer from perplexity.ai about dynamic memory allocation (as opposed to static memory allocation).

Dynamic memory allocation is the process of assigning the memory space during the execution time (aka. the run time). (Static memory allocation is a process in which memory for variables and data structures is reserved at compile time, before the program runs.)

When was dynamic memory allocation first introduced and why?

Dynamic memory allocation was first introduced in the early days of the C programming language, which was developed in the early 1970s. The concept became fully established and standardized with the 7th Edition of Unix, released in 1979[1].

The introduction of dynamic memory allocation was driven by several key factors:

Flexibility: It allowed programs to request memory as needed at runtime, rather than having to pre-allocate all required memory at compile time[2].
Efficient resource use: Dynamic allocation enabled more efficient use of limited memory resources, as memory could be allocated and deallocated as needed during program execution[2].
Handling variable-sized data: It provided a solution for managing data structures whose size was not known until runtime, such as when reading data from user input or files[2].
Overcoming limitations: Dynamic allocation addressed limitations of static and automatic memory allocation, which required compile-time constant sizes and had restricted lifetimes[2].
Complex program needs: As programs became more complex, there was an increasing need for greater flexibility in memory management beyond what static and stack-based allocation could provide[2].

The introduction of dynamic memory allocation represented a significant advancement in programming capabilities, allowing for more sophisticated and flexible software design. However, it also introduced new challenges, such as the need to manually manage memory to prevent leaks and fragmentation[3].

Citations:
[1] https://patents.google.com/patent/US20110078404
[2] https://en.wikipedia.org/wiki/C_dynamic_memory_allocation
[3] https://en.wikipedia.org/wiki/Memory_management
[4] https://patents.google.com/patent/US20050268049A1/en
[5] https://stackoverflow.com/questions/49354528/c-when-do-objects-of-classes-allocated-dynamic-memory
[6] https://azrael.digipen.edu/~mmead/www/Courses/CS120/DynamicMemoryAllocation-1.html
[7] https://gamedev.stackexchange.com/questions/8206/dynamic-memory-allocation-and-memory-management

What problems did it lead to?

Dynamic memory allocation, introduced in the early 1970s with the C programming language, led to several significant problems:

Memory leaks: Programs could lose references to allocated memory, causing gradual resource exhaustion[1][5].
Fragmentation: Repeated allocation and deallocation could lead to memory fragmentation, making it difficult to find contiguous blocks of free memory[1][3].
Non-deterministic behavior: Allocation times became unpredictable, which is problematic for real-time systems[2][3].
Allocation failures: Programs could run out of memory unexpectedly, or fail to allocate due to fragmentation[1][2].
Dangling pointers: Improper deallocation could result in pointers referencing freed memory[1].
Performance overhead: Dynamic allocation functions have significant execution overhead[1].
Lack of reentrancy: Common implementations were not thread-safe, causing issues in multi-threaded systems[2].
Inefficient memory usage: Dynamic allocation could lead to wasted space and inefficient memory utilization[1][5].
Debugging complexity: Memory-related bugs became harder to identify and fix[5].
Security vulnerabilities: Improper memory management could lead to exploitable security flaws[5].

These issues are particularly problematic in embedded and real-time systems, where resources are constrained and predictable behavior is crucial[3][5].

Citations:
[1] https://electrical.codidact.com/posts/286121
[2] https://embeddedcomputing.com/technology/software-and-os/ides-application-programming/dynamic-memory-allocation-just-say-no
[3] https://www.design-reuse.com/articles/25090/dynamic-memory-allocation-fragmentation-c.html
[4] https://barrgroup.com/tech-talks/memory-allocation
[5] https://www.reddit.com/r/embedded/comments/u31pse/why_is_dynamic_memory_allocation_bad/
[6] https://stackoverflow.com/questions/72211874/what-is-the-practical-scenario-example-use-of-dynamic-memory-allocation-and-vect
[7] https://blog.jyotiprakash.org/basic-dynamic-memory-allocation-programming-questions
[8] https://docs.multiversx.com/developers/best-practices/the-dynamic-allocation-problem/

Programming languages without dynamic memory allocation?

https://www.reddit.com/r/ProgrammingLanguages/comments/rz41q6/programming_languages_without_dynamic_memory/?rdt=40847

Offline-first app with GraphQL: React Relay vs. URQL

Magne — Tue, 25 Feb 2025 11:37:29 +0000

— A too good answer from perplexity.ai not to share, so here it is:

—-

Here’s a comparison of using React Relay (with or without react-relay-offline) versus Urql with Graphcache for building offline-first apps:

React Relay (Manual or with `react-relay-offline`)

Pros:

Relay’s Strengths: Built for GraphQL with optimized performance and normalized caching out of the box.
Customizability (Manual): Full control over offline persistence, mutation queuing, and cache management when implementing manually.
Out-of-the-Box Offline Support (react-relay-offline): Simplifies offline functionality with features like mutation queuing, retries, and cache persistence.
Optimistic Updates: Easy to implement optimistic responses for better user experience during offline operations.

Cons:

Complexity (Manual): Manual implementation requires significant effort to handle caching, persistence, and retries.
Bundle Size (react-relay-offline): Adds ~16.4 kB to the app size.
Learning Curve: React Relay has a steeper learning curve compared to Urql due to its strict architecture and reliance on GraphQL fragments.

Urql with Graphcache

Pros:

Modular Design: Urql’s exchange-based architecture allows flexibility in adding offline support using the offlineExchange from Graphcache.
Graphcache Features: Provides normalized caching, automatic updates based on schema, and offline persistence through storage layers like AsyncStorage or IndexedDB (learn more about @urql/storage-rn).
Simplified Setup: Adding offline support is straightforward by configuring offlineExchange with storage (e.g., @urql/storage-rn for React Native) (check out this tutorial).
Optimistic Updates: Supports optimistic responses and cache updates for seamless offline behavior.

Cons:

Custom Logic for Mutations: Offline mutations may require more manual handling (e.g., queuing failed mutations) compared to libraries like react-relay-offline.
Limited Offline Mutation Handling: Mutations are only optimistically updated locally; if the server is unreachable during retries, changes may not persist unless custom logic is added (see discussion on Urql and learn how to handle mutations offline).
Schema Dependency: Requires a well-defined schema for effective caching and updates.

Key Differences

Feature	React Relay (Manual)	React Relay (`react-relay-offline`)	Urql with Graphcache
Ease of Setup	High complexity	Medium complexity	Low complexity
Offline Query Caching	Manual setup	Automatic	Automatic
Mutation Queuing & Retry	Manual implementation	Built-in	Requires custom handling (see how to handle mutations)
Persistence Options	Custom storage logic needed	Pre-configured options	Pre-configured options
Optimistic Updates	Manual	Built-in	Built-in
Network Monitoring	Manual	Built-in hooks	Built-in
Customization	Full	Moderate	High
Bundle Size Impact	Minimal	+16.4 kB	Minimal

Recommendation

Use React Relay with react-relay-offline if:
- You are already using React Relay and need robust offline support with minimal additional setup.
- You require built-in mutation queuing and retry mechanisms.
Use Urql with Graphcache if:
- You prefer a lightweight, modular library with flexibility in customizing exchanges.
- Your app primarily focuses on query caching and optimistic updates but can handle custom logic for mutation retries.
Choose Manual React Relay Implementation if:
- You need full control over every aspect of offline functionality without relying on third-party libraries.

—-

Why Relay is sometimes superior to URQL

Relay is often considered superior to URQL for complex React applications due to its advanced features and optimizations:

Performance: Relay's compiler pre-optimizes queries for runtime efficiency, ensuring high performance as applications scale (learn more about Relay's performance).
Declarative Data Fetching: Relay allows developers to declare data dependencies in components, automating data fetching and reducing boilerplate (see Relay's declarative approach).
Type Safety: It auto-generates TypeScript/Flow types, ensuring schema consistency and reducing runtime errors (explore Relay's type safety features).
Built-in Features: Relay provides out-of-the-box support for caching, pagination, optimistic updates, and conflict resolution, which URQL lacks natively (discover Relay's built-in features).
Strict Conventions: Relay enforces GraphQL best practices, ensuring reliable APIs and clean architecture (understand Relay's conventions).

However, Relay has a steeper learning curve and requires stricter schema design, making URQL a simpler choice for smaller or less demanding projects (compare Relay and URQL for different project sizes).

—-

Built-in Features in Relay (Point 4 Expanded)

Relay stands out because it provides robust, built-in features that simplify complex GraphQL workflows. These features are designed to handle common challenges in data fetching and state management, reducing the need for additional libraries or custom implementations. Here's a detailed breakdown of these features:

1. Caching

Relay includes a sophisticated normalized cache out of the box. This means that data fetched from the server is stored in a normalized format, where each entity is stored by its unique identifier. This allows Relay to:

Efficiently update only the parts of the UI that are affected by changes in the data.
Avoid redundant network requests by reusing cached data whenever possible.
Automatically merge new data into the cache without manual intervention.

Relay's cache is highly optimized and works seamlessly with its compiler, ensuring minimal runtime overhead.

In contrast, while URQL has a caching layer (via its @urql/exchange-graphcache package), it requires additional configuration and doesn't offer the same level of integration or performance optimization as Relay's built-in solution.

2. Pagination

Relay provides automatic pagination support for GraphQL connections (a common pattern for paginated data in GraphQL). It includes:

Relay-style Cursor-based Pagination: Relay is designed around GraphQL's connection model, making it easy to implement infinite scrolling or "load more" functionality.
Automatic Cache Updates: When fetching additional pages, Relay automatically updates the cache and merges new results with existing data without requiring manual intervention.

URQL does not have native pagination support. Developers often need to write custom logic or use third-party libraries to handle pagination effectively.

3. Optimistic Updates

Relay supports optimistic updates out of the box, allowing developers to update the UI immediately after a mutation is triggered, even before receiving a response from the server. This creates a smoother user experience by reducing perceived latency.

For example:

If a user submits a form, Relay can optimistically update the UI as if the mutation succeeded.
If the mutation fails, Relay will roll back the optimistic update automatically.

While URQL also supports optimistic updates, it requires more manual configuration compared to Relay's seamless integration with its store and cache.

4. Conflict Resolution

Relay includes mechanisms for handling data conflicts that may arise when multiple operations (e.g., mutations) affect overlapping parts of the cache. For example:

If two components request overlapping fields from the same object, Relay ensures that both components receive consistent and up-to-date data.
When mutations are performed, Relay intelligently updates only the affected parts of the cache without overwriting unrelated fields.

This conflict resolution is tightly integrated with Relay's normalized cache and compiler-generated artifacts, making it reliable and efficient.

URQL does not provide built-in conflict resolution mechanisms, leaving developers to handle such scenarios manually.

5. Subscriptions

Relay supports GraphQL subscriptions for real-time updates via third-party extensions or libraries (e.g., subscriptions-transport-ws or graphql-ws). Subscriptions integrate well with its caching layer, ensuring that real-time data updates are reflected throughout your application automatically.

URQL also supports subscriptions but requires additional setup using its @urql/exchange-subscription package. However, integrating subscriptions with URQL's cache can be more challenging compared to Relay's seamless approach.

Summary

Relay's built-in features like caching, pagination, optimistic updates, and conflict resolution are tightly integrated into its architecture. This makes it an excellent choice for large-scale applications where managing complex GraphQL workflows efficiently is critical. While URQL can achieve similar functionality with add-ons and custom logic, it requires more effort and lacks the deep integration and optimizations that Relay offers out of the box.

Ways of handling side-effects and IO

Magne — Mon, 28 Oct 2024 12:20:23 +0000

I had this interaction with perplexity.ai regarding how various (functional) programming languages handle Input/Output (IO) and side-effects in relation to balancing functional purity vs. developer ergonomics, and this summary was too good to not share, so here it is:

Linear types and explicit IO handling can indeed help manage side effects, but they come with trade-offs. Let's explore this concept and its implications:

Linear Types and IO Handling

Linear types, as used in languages like Rust, can provide a way to track and control side effects by ensuring that objects are used exactly once. This approach has several benefits:

Explicit resource management
Guaranteed cleanup
Thread safety

However, as you've noted, there are some challenges:

Passing IO Objects

Passing an IO object through multiple function levels can become cumbersome. This is often referred to as "threading the state" through your program (akin to "prop drilling" in React). While it makes side effects explicit, it can lead to:

Verbose function signatures
Reduced code readability
Potential for "parameter explosion"

Using ...args

Using variadic arguments (...args) to implicitly pass the IO object could indeed reduce the explicitness of the IO operations. This approach:

Reduces verbosity
May improve readability in some cases
Loses some of the benefits of explicit IO handling

Calling IO Directly

Calling IO operations directly from the lowest-level function where they're needed might seem simpler, but it has drawbacks:

Reduces testability
Makes the function less pure and harder to reason about
Can lead to hidden dependencies and make refactoring more difficult

Alternative Approaches

There are several ways to balance the benefits of linear types and explicit IO handling with code ergonomics:

Dependency Injection: Pass IO dependencies explicitly, but at a higher level of abstraction.
Monad Transformers: Used in functional programming to compose different effects, including IO.
Effect Systems: Provide a way to track and manage side effects at the type level, without the strict linearity of linear types.
Capability-based Systems: Control access to IO operations through capabilities that are passed explicitly.

Conclusion

The choice between explicit IO handling with linear types and more implicit approaches depends on your specific needs:

For systems programming or safety-critical applications, the explicitness of linear types can be beneficial.
For application development, a more flexible approach might be preferred.

Ultimately, the goal is to find a balance between safety, explicitness, and ergonomics that suits your project's requirements.

Citations:
[1] https://docs.rs/linear_type/latest/linear_type/
[2] https://smallcultfollowing.com/babysteps/blog/2023/03/16/must-move-types/
[3] https://blog.yoshuawuyts.com/linearity-and-control/
[4] https://verdagon.dev/blog/linear-types-borrowing
[5] https://blog.yoshuawuyts.com/linear-types-one-pager/
[6] https://faultlore.com/blah/linear-rust/
[7] https://www.reddit.com/r/rust/comments/rei55q/less_painful_linear_types/
[8] https://www.youtube.com/watch?v=mocS_lErB1M

Examples of each of the alternative approaches

Certainly! I'll provide examples of the alternative approaches to dependency injection and IO handling that were mentioned. These approaches aim to balance the benefits of explicit IO handling with code ergonomics.

1. Dependency Injection

Dependency Injection (DI) is a technique where dependencies are provided to a class from the outside, rather than being created within the class itself[1].

public class ProductService {
    private final Database database;

    // Constructor Injection
    public ProductService(Database database) {
        this.database = database;
    }

    public Product getProduct(int id) {
        return database.fetchProduct(id);
    }
}

// Usage
Database database = new PostgresDatabase();
ProductService service = new ProductService(database);

In this example, the Database dependency is injected into the ProductService through its constructor. This allows for easy swapping of database implementations without changing the ProductService code.

2. Monad Transformers

Monad Transformers are used in functional programming to compose different effects, including IO. While Java doesn't have built-in support for monads, we can simulate the concept:

public class IOMonad<T> {
    private final Supplier<T> computation;

    private IOMonad(Supplier<T> computation) {
        this.computation = computation;
    }

    public static <T> IOMonad<T> unit(T value) {
        return new IOMonad<>(() -> value);
    }

    public <R> IOMonad<R> flatMap(Function<T, IOMonad<R>> f) {
        return new IOMonad<>(() -> f.apply(computation.get()).run());
    }

    public T run() {
        return computation.get();
    }
}

// Usage
IOMonad<String> readFile = new IOMonad<>(() -> Files.readString(Path.of("file.txt")));
IOMonad<Integer> wordCount = readFile.flatMap(content -> 
    IOMonad.unit(content.split("\\s+").length)
);
int count = wordCount.run();

This approach allows for composing IO operations in a more functional style, making it easier to reason about and test.

3. Effect Systems

Effect systems provide a way to track and manage side effects at the type level. While Java doesn't have a built-in effect system, libraries like ZIO for Scala demonstrate this concept. Here's a simplified example of how it might look:

public interface Effect<R, E, A> {
    A run(R environment) throws E;
}

public class IOEffect<A> implements Effect<IORuntime, IOException, A> {
    private final Function<IORuntime, A> effect;

    public IOEffect(Function<IORuntime, A> effect) {
        this.effect = effect;
    }

    @Override
    public A run(IORuntime runtime) throws IOException {
        return effect.apply(runtime);
    }
}

// Usage
IOEffect<String> readFile = new IOEffect<>(runtime -> 
    runtime.readFile("file.txt")
);

This approach allows for explicit tracking of effects in the type system, making it clear what side effects a function might have.

4. Capability-based Systems

Capability-based systems control access to IO operations through capabilities that are passed explicitly:

public interface FileSystemCapability {
    String readFile(String path) throws IOException;
    void writeFile(String path, String content) throws IOException;
}

public class FileManager {
    private final FileSystemCapability fs;

    public FileManager(FileSystemCapability fs) {
        this.fs = fs;
    }

    public String processFile(String path) throws IOException {
        String content = fs.readFile(path);
        return content.toUpperCase();
    }
}

// Usage
FileSystemCapability fs = new RealFileSystem();
FileManager manager = new FileManager(fs);
String result = manager.processFile("input.txt");

In this approach, the FileSystemCapability represents the ability to perform file operations. By passing this capability explicitly, we can control and track IO operations more effectively.

Each of these approaches offers different trade-offs between explicitness, safety, and ergonomics. The choice depends on the specific requirements of your project and the language features available to you.

Side-effects vs. side-causes

Magne — Tue, 21 May 2024 10:24:13 +0000

The concept of "side-causes" doesn't seem to be a very established term yet, but I think it should be, for conceptual clarity.

The current discussion in functional programming revolves very much around side-effects (and how to avoid them). I've noticed a tendency to label every undesired influence or reliance on externals as "side-effects". Which doesn't really make sense, if you think about it in terms related to our physical world (from where the concept of an 'effect' assumedly was derived, originally). In the physical world we have both causes and effects, which are clearly distinguished (albeit sadly often confused or reversed). So we'd do well to distinguish these concepts in programming as well.

The colloquial definition seems to be that side-causes are hidden inputs, and side-effects are hidden outputs.

But, with some help of our AI language model / search engine of choice (perplexity.ai), to word it more precisely and list useful examples, we can say the following.

Side-effects and side-causes are related but distinct concepts in programming:

Side Causes

A side cause refers to an implicit input or dependency that a function relies on, beyond its explicit arguments. Some examples include:

Reading from global variables or module-level state
Getting the current time or generating random numbers
Reading configuration from the environment or system properties
Calling impure functions that depend on external state

Side causes violate referential transparency, meaning you cannot simply replace a function call with its result because the result may be different each time due to implicit inputs. This makes code harder to understand, test in isolation, optimize, and run in parallel.

Side Effects

A side effect is a change in system state or observable behavior that occurs as a result of executing a function or expression, beyond just returning a value. Some examples of side effects include:

Modifying a variable or data structure outside the function's local scope
Writing to a file, network, or database
Triggering an exception or error
Calling other functions that have side effects
Outputting data to the console or UI

Side effects make a program's behavior dependent on the order of execution and previous state, which can make code harder to reason about, test, and maintain.[1]

In summary, [explicit (my note)] side effects are about outputs/changes beyond the return value, while side causes are about implicit inputs beyond the arguments. Both can make code harder to reason about, especially in combination. Functional programming aims to minimize or isolate side effects and side causes for better modularity and determinism. [1][3]

Explicit vs Implicit Side-effects

In addition here, we can make a further distinction between two variants of side-effects. Importantly, side-causes often result in implicit side-effects. Because:

if a function has a side-cause,
and the side-cause changes from an invocation of the function to another,
and the function uses it in computing its result,

then, even if the function does not affect the outside world apart from returning its result, the result is affected. This can be seen from the outside of the function (by anything that relies on its result). So even though the function didn't directly affect the outside world, through a write operation or other kind of output occurring during the function execution, it still introduced some side-effect into it's own result. This is another way to view side-effects. Side-effects can be explicit (hidden extra outputs), but also implicit (silently modified results).

I think the reason that side-causes are often erroneously called side-effects, is because side-causes generally introduce (implicit) side-effects, if the side-cause affects the function's result in any manner. (If it doesn't change the result, why is the function even relying on that side-cause in the first place?). In this case you could say that "there is an unintended side-effect/surprise when calling the function", but simultaneously that "the function does not have a direct side-effect/cause on its environment".

I hope this helped give some conceptual clarity, and can be a post to link to for distinguishing these two terms specifically.

PS: Funnily enough, it seems the AI derived its understanding from the following citations, where the only citation it used that mentioned side-causes was my own brief comment on the Software Engineering Stack Exchange site:

"read from any input stream" is strictly speaking a side-cause, not a side-effect. Writing to an output stream would be a side-effect. See: blog.jenkster.com/2015/12/what-is-functional-programming.html

Citations used by the AI:
[1] https://en.wikipedia.org/wiki/Side_effect_%28computer_science%29
[2] https://www.linkedin.com/advice/0/what-some-common-sources-side-effects-functional
[3] https://softwareengineering.stackexchange.com/questions/15269/why-are-side-effects-considered-evil-in-functional-programming
[4] https://dev.to/ruizb/side-effects-21fc
[5] https://www.freecodecamp.org/news/pure-function-vs-impure-function/

The top Google results I've found previously mentioning "side-causes" are:

http://blog.jenkster.com/2015/12/what-is-functional-programming.html (Dec 2015)
https://chaddha.me/understanding-the-enigma-of-rxjava-part-1-8e04a456d9de (3. Oct 2016)
https://gist.github.com/mattclaw/554cf037cdf5d05425d738863e8cfe97 (22. Sept 2016)
https://medium.com/go-for-marty/what-are-pure-functions-side-causes-and-side-effects-5a2a01f7cbcd (14. Nov 2017)
https://www.skylerlemay.com/blog/2019/08/19/what-is-a-side-effect-anyway-30daysoffp-week-2 (19. Aug 2019)
https://www.reddit.com/r/functionalprogramming/comments/15axgtp/a_concise_name_for_code_lines_without_side/ (27. Jul 2023)

Do you know of any earlier reference to "side-causes"?

Transducers and Eduction in Clojure simply explained

Magne — Wed, 24 Apr 2024 13:35:36 +0000

With help from our coming AI overlords:

Transducers and eduction in Clojure are ways to efficiently process and transform data, especially when working with large datasets.

Here's a simple explanation:

Transducers:

Transducers are functions that can be composed together to create a sequence of transformations.
They allow you to define a series of operations (like mapping, filtering, etc.) that can be applied to any collection of data, without having to worry about the specific data structure.
Transducers are "context-independent" - they don't care about the input or output data structures, they just focus on the transformations.
This makes transducers very flexible and reusable. You can combine them in different ways to create complex data pipelines.

Eduction:

Eduction is a way to apply a transducer to a collection of data without creating intermediate data structures.
Normally, when you apply a series of transformations to a collection (e.g. map, filter, etc.), you end up creating a new collection at each step.
With eduction, the transformations are applied "on the fly" as the data is consumed, without creating those intermediate collections.
This can be much more efficient, especially when working with large datasets, because you don't have to allocate memory for all the intermediate results.
eduction is a Clojure core function that takes transducers as arguments, and captures the transduction process into a function. It applies the transducers to the input collection, but the result is a reducible/iterable, not a concrete data structure. You need to use functions like iterator-seq to get a sequence from the reducible result.

In summary, transducers allow you to define reusable data transformations, and eduction allows you to apply those transformations efficiently without creating unnecessary data structures. Together, they provide a powerful way to build composable, high-performance data processing pipelines in Clojure.

Eduction is best used when the result will be completely consumed in a reducible context. But transducers can be used with other functions as well, depending on the specific use case.

DEV Community: Magne

Meta-Programming and Macro capabilities of various languages

Metaprogramming + macro features

ReScript vs. Melange

How they differ

When to choose Melange

When to choose ReScript

Quick decision matrix

Why did OOP become popular (from a DX perspective)?

Core DX Benefits of OOP

Why Developers Chose OOP

Why did FP not become as popular as OOP (from a DX perspective)?

Challenges for FP Adoption

Key DX Differences: FP vs OOP

How could a new FP language have at least as good DX as OOP without being OOP?

Essential Features for Superior FP DX

Key Principles to Emphasize

Why necessarily "first-class modules"?

Why First-Class Modules Matter in FP

Solito 5 is now web-first (but still unifies NextJS and React Native)

Why use Solito on web with pure NextJS, if Solito is precisely for cross-platform development?

Background on Solito

Solito 5 and the Web-First Shift

Utility of Solito on Web with Pure Next.js

Isn’t Solito for React Native Stuff?

Practical Example

Caveats

Conclusion

Solito 5 Overview

Can You Use Web Stuff on Native with Solito?

Why Not Directly?

Workarounds to Use Web-Like Features on Native

Limitations

Can You Use Native Stuff on Web with Solito?

Solito’s Intended Use

Practical Example

Conclusion

What is PhotonJS?

The problem PhotonJS solves:

Why Photon Matters

In Short

Electric Socket Multiport Adapter

Photon as Multiport Adapter

Summary Comparison Table

What Photon Does

Explained Like You’re 5 Years Old (ELI5)

How It’s Structured

In Short

What Photon actually contains code-wise:

1. Core Package (packages/core)

2. Runtime Package (packages/runtime)

3. Adapter Interfaces

4. Tooling and Dev Features

Summary

Referential transparency with mutation

Code example

Why this preserves referential transparency here:

Reference from search results:

What if multiple functions use the same input?

Could parentheses be a reason Lisp is hard to read?

1. Visual Clutter

2. Lack of Visual Cues

5. Reduced Readability

6. Limited Expression of Precedence

7. Indentation Challenges

Conclusion

Dynamic memory allocation - when, why and woes

When was dynamic memory allocation first introduced and why?

What problems did it lead to?

Programming languages without dynamic memory allocation?

Offline-first app with GraphQL: React Relay vs. URQL

React Relay (Manual or with react-relay-offline)

Urql with Graphcache

Key Differences

Recommendation

Why Relay is sometimes superior to URQL

Built-in Features in Relay (Point 4 Expanded)

1. Caching

2. Pagination

3. Optimistic Updates

1. Core Package (`packages/core`)

2. Runtime Package (`packages/runtime`)

React Relay (Manual or with `react-relay-offline`)