Why Goblin?

Goblin exists because many programming problems are harder than they need to be.

Not because computers are difficult.

Not because programming is inherently difficult.

But because modern software development often prioritizes mechanisms over communication. Or decades of convention are hard to break, even when they don't make any sense. People often do things the way they've always been done because that is what's comfortable.

The result is a world where developers spend enormous amounts of time memorizing vocabulary, learning frameworks, managing dependencies, and deciphering code that says how instead of why.

Goblin was created as a path in a different direction.

Why Another Language?

The world does not need another programming language.

There are already thousands.

Most of them are perfectly capable of solving real problems.

Goblin was not created because existing languages are useless.

It was created because many common frustrations continue to appear across nearly every language ecosystem.

Questions like:

• Why are there ten names for the same operation?
• Why do simple tasks require external packages?
• Why do package managers create dependency chains nobody understands?
• Why does code often describe mechanisms instead of intent?
• Why is learning a language often harder than learning the actual programming concept?

Goblin attempts to answer those questions differently.

Complexity Is Not the Same as Power

Programming often rewards complexity.

Developers are encouraged to learn increasingly sophisticated abstractions, patterns, frameworks, and tools. Algorithms. Leet Code puzzles. Goblin is not interested in making you look clever. It is interested in helping you build something.

Don't get me wrong; some complexity is necessary.

Much of it is accidental.

Goblin attempts to reduce accidental complexity wherever possible.

If an operation is common and useful, it should be easy to express.

If a concept appears repeatedly, it should use consistent vocabulary.

If a programmer can clearly describe their intent in plain language, the language should help express that intent directly.

The Vocabulary Problem

One of the biggest challenges in programming is not logic.

It is vocabulary.

Different languages often use completely different names for the same operation.

A developer may already understand the concept perfectly while still being unable to remember the correct function name.

Goblin attempts to reduce that burden.

Instead of continuously introducing new terminology, Goblin favors a small set of consistent verbs that appear throughout the language.

The goal is not to make programming simpler by removing capability.

The goal is to make programming simpler by reducing unnecessary memorization. The goal is to establish patterns and repeat the same ideas in the same ways so that mental overhead is cleared for what really matters: getting shit done.

Programming Should Teach Concepts

Many languages teach syntax first.

Goblin attempts to teach concepts first.

When possible, the documentation explains:

• What the concept is
• Why it exists
• When to use it
• How Goblin expresses it
• Why certain design choices were made

This allows new programmers to learn programming itself instead of merely learning Goblin syntax. This also helps people coming from other languages when they encounter something that feels alien. When you understand why syntax or a feature was designed the way it was, things start clicking into place.

A language should help people understand programming.

It should not become another obstacle between the programmer and the concept.

Software Should Be Understandable

Programs are read more often than they are written.

Most of a developer's time is spent understanding existing code.

Future-you is no exception.

Goblin prioritizes readability because readability is practical.

Code that clearly communicates intent is easier to maintain, easier to debug, easier to teach, and easier to improve.

When reading code, the reader should spend less time decoding syntax and more time understanding the problem being solved.

An Ecosystem, Not Just a Language

Goblin is not only a programming language.

It is an attempt to build a coherent ecosystem.

Tools should work together.

Documentation should be integrated.

Packages should be understandable.

Common workflows should feel consistent.

Projects such as Sheriff, GLAMs, Prospector, and the Box all exist for the same reason: to reduce friction between an idea and a working solution.

Each tool solves a different problem.

All of them are guided by the same philosophy.

The Experiment

Goblin is ultimately an experiment.

Some ideas will succeed.

Some ideas will fail.

Some ideas will evolve into something entirely different.

That is acceptable.

The goal is not to preserve tradition.

The goal is not to be different for the sake of being different.

The goal is to explore whether programming can be made more readable, more consistent, more practical, and more enjoyable.

If an idea works, Goblin keeps it.

If an idea does not work, Goblin changes it.

Shaped by Use, Not Ideology

The language is shaped by use, not ideology.

While Goblin often takes a different approach to things (see loops for a good example), it does so because it works in practice.

Everything in Goblin is tested with real projects. When friction is encountered, it evolves to sand off any rough edges. Check out broadcast tether and summon and nullish coalesce.

https://sheriff.sheriffcloud.com, what these docs are made with, is proof that Goblin is capable of doing stuff. And Sheriff is also a testament to this process. Many of the syntax choices, concepts, and principles were born from that crucible.

Why Goblin?

Because somebody has to be willing to ask:

What if we tried a different way?