{"slug": "language-plasticity-is-more-important-than-ever", "title": "Language Plasticity is More Important Than Ever", "summary": "A study on code formatting and LLM budgets found that removing formatting elements like indentation, extra whitespace, and newlines reduced input tokens by an average of 24.5% across models and languages, with negligible effects on output quality (Pass@1 drops under 4.2% on average). The D programming language, with its brace-based syntax and uniform member access, offers token efficiencies compared to Python and C++, potentially lowering costs when working with large language models.", "body_md": "Large language models are rewriting how we build software. From quick prototypes to full features, prompting an LLM to generate or refactor code in the D programming language feels increasingly natural. But as context windows grow and API bills mount, a subtler question emerges: does the language itself influence how many tokens an LLM consumes and therefore how much it costs to work with?\n\nD, with its blend of systems-level power and modern conveniences, offers us an intriguing lens through which to evaluate LLM Token usage. While the community often champions D for performance and expressiveness, its static typing, consistent syntax, and thoughtful design choices might also deliver hidden efficiencies when paired with AI tools. Let’s explore three angles where language design intersects with token economics, with a light nod to the ongoing debates that keep us all entertained.\n\nThe tabs-versus-spaces debate has long divided developers. In the LLM era, it carries real financial weight. Many tokenizers treat whitespace as distinct tokens, and common conventions amplify the difference.\n\nPython’s official style guide recommends four spaces for indentation. In practice, this means every level of nesting can add multiple individual space tokens. D, like C-family languages, relies on braces for structure, so indentation serves readability rather than syntax. This flexibility lets teams choose tabs (a single character) without breaking semantics.\n\nA recent study on code formatting and LLM budgets quantified the impact. Removing formatting elements like indentation, extra whitespace, and newlines, reduced input tokens by an average of 24.5% across models and languages, with negligible effects on output quality (Pass@1 drops under 4.2% on average). Java saw the largest savings (~35%), while Python’s reliance on significant whitespace limited reductions to around 6%. Indentation alone often accounted for 8–10% of tokens in C-style languages.\n\nFor a quick case study, consider equivalent snippets. A deeply nested Python function with four-space indents piles on tokens quickly. The same logic in D, using braces and tabs, trims the count, especially if your formatter or LLM prompt favors compact style. The takeaway? Consistent, minimal formatting isn’t just aesthetic; it’s a budget hack. Many teams are now experimenting with unformatted prompts for generation, then pretty-print afterward.\n\nDynamic languages shine for rapid iteration, but their flexibility can demand extra tokens from the LLM. In duck-typed environments like Python or JavaScript, a variable’s behavior emerges only through usage. When an LLM builds context, it often needs surrounding code, comments, or explicit hints to infer “this variable quacks like a list here, but might be something else later.”\n\nStatically typed languages flip the script. In D, a parameter declared as `int[] arr`\n\nor a struct with explicit methods tells the model exactly what operations are valid, right there in the signature. No detective tokens required.\n\nThe result? When using LLMs with duck-typed languages, the model often spends more tokens reconstructing intent. Explicit types and consistent call-site semantics in D let it focus on logic instead of inference.\n\nLanguage design choices ripple through edit tasks. One classic pain point in C++ is the distinction between `.`\n\nfor value types and `->`\n\nfor pointers/references. Change a type from `Foo`\n\nto `Foo*`\n\n, and suddenly every member access across the codebase flips operators. LLMs tasked with this refactor must hunt down and update dozens, or hundreds, of call-sites, burning tokens on repetitive churn.\n\nD sidesteps this entirely. Member access uses the dot operator uniformly for structs, classes, and even pointers to them. No `->`\n\noperator exists for this purpose. Refactoring a value type to a reference (or vice versa) often requires only changing the declaration and a few dereferences, far less widespread editing.\n\nD brings additional plasticity through Uniform Function Call Syntax (UFCS). Any free function can be called as a method: `foo(bar)`\n\nbecomes `bar.foo()`\n\n. This enables seamless chaining and lets you extend types without modifying their definitions. When an LLM suggests adding a helper, you can often integrate it via UFCS without touching call sites or introducing new boilerplate.\n\nOther D features amplify this. Compile-time function execution (CTFE) and powerful templates let the compiler handle complexity that might otherwise require verbose runtime code in other languages. When prompting for changes, the model can lean on these abstractions rather than generating repetitive patterns.\n\nData from token-efficiency analyses show dynamic languages often win on raw count: no type annotations means fewer tokens per line. One comparison across RosettaCode tasks found a 2.6× gap between the least efficient (C) and most efficient languages, with dynamic options and strongly-inferring functional languages (Haskell, F#) leading the pack. JavaScript proved surprisingly verbose among dynamics, while pure static languages paid a clear price for declarations.\n\nYet the picture isn’t purely about fewer tokens. Static typing provides immediate, machine-checkable context that can reduce the LLM’s need for explanatory scaffolding. Combined with D’s consistent operators, UFCS, and brace-based structure, this often translates to lower churn during iterative edits, the very tasks that dominate real-world LLM usage.\n\nUltimately, token efficiency is one factor among many. D’s compile-time feedback, memory safety options, and expressiveness pair well with rapid AI iteration. Whether you land on “static wins on cost” or “dynamic saves so much time” depends on your workload. The real experiment? Try prompting the same task in D versus Python or C++, measure the tokens, and see what your budget (and your code) tells you.\n\nWhat are your experiences prompting LLMs in D? Drop a comment in the forums. I’m genuinely curious how the community is navigating this new landscape.\n\n*References and further reading:*\n\nHappy coding—and may your token counts be ever in your favor!", "url": "https://wpnews.pro/news/language-plasticity-is-more-important-than-ever", "canonical_source": "https://blog.dlang.org/2026/08/10/language-plasticity-is-more-important-than-ever/", "published_at": "2026-08-10 00:00:00+00:00", "updated_at": "2026-08-10 13:12:14.137089+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools"], "entities": ["D programming language", "Python", "C++", "Java", "JavaScript"], "alternates": {"html": "https://wpnews.pro/news/language-plasticity-is-more-important-than-ever", "markdown": "https://wpnews.pro/news/language-plasticity-is-more-important-than-ever.md", "text": "https://wpnews.pro/news/language-plasticity-is-more-important-than-ever.txt", "jsonld": "https://wpnews.pro/news/language-plasticity-is-more-important-than-ever.jsonld"}}