This book is intended as a programmer’s introduction or refresher to the Blub programming language. It is incomplete, opinionated, and short.
We assume that you are a working programmer with several years experience in at least one common “conventional” programming language: e.g. BASIC, C, C++, C#, Java, JavaScript, Python, Perl, Ruby, Lua. By the time you finish this book, we intend that you’ll be able to:
- Read and make sense of conventionally-written Blub code.
- Navigate a Blub codebase and understand how the parts fit together.
- Diagnose unexpected program behaviors.
- Make meaningful additions and changes to a codebase in idiomatic Blub style.
Like all books in the “Enough ___” series, this book adheres to a few fundamental principles:
Learn from living code
You will not find the usual progression of “syntax, flow control, functions, data types, tools” here. Like a real-world software project, we will chuck you directly into the deep end of a mature Blub codebase. Nearly all of the examples in this book are drawn from the same project, which you can (and are encouraged to) run on your own machine.
Over the course of this book you will build up your understanding of Blub by interacting with that codebase: reading code, making changes, and seeing how those changes impact the behavior of the code. We will introduce you to Blub syntax, semantics, data types, and abstractions in a just-time-fashion, as needed.
Fast-forward through the boring bits
We assume you understand typical programming features like scalar datatypes, if
/else
statements, and functions. You don’t need to know that you can write a hexadecimal literal by prefixing it with 0x
. You do need to know if, as in JavaScript, that hexadecimal number will actually be stored as a floating-point value, rather than as an integer.
We will endeavor to speed through the unsurprising aspects of Blub, and focus on the less usual aspects.
No hype
There are lots of programming languages. Blub is fine. Other programming languages are also fine. Life is too short to wax breathless about how destructuring assignment is going to change your life.
You need to get shit done in Blub. We will show you how.
Acknowledge history
Things are the way they are because they got that way.
All programming languages have quirks. Some of them are intentional design decisions; others are historical accidents. Most are somewhere in between.
Over the course of decades of language geekery, your authors have all experienced the slow retconning of acknowledged language warts into “the right way to do it” by over-eager language fan[atic]s. We promise not to blow sunshine up your ass about historical misfeatures.
But we’re also not going to linger over them. We believe that getting hung up on language oddities is a waste of time, and that language snobbery is actively harmful. We will call out surprising behavior. We may giggle over it, briefly. We’ll try to provide just enough context to make it a little less surprising, where possible.
And then we’ll move on.
Go with the grain
Not all language surprises are mistakes. Every programming language has its own grain; its own set of idiomatic styles, patterns, processes and tools that fit together into a productive workflow.
For example, statically-typed languages like Java and Haskell and their associated tools give you lots of support for writing correct code before you ever compile and run it. Python and Ruby, by contrast, offer fewer static aids, but reward constant small the-proof-is-in-running-the-code experiments in the REPL and in unit tests.
We don’t believe in making excuses for warts. We also have little patience for attempts to write Blub in the style of some other language, followed by complaints that it’s painful to do so. Where Blub code and style is surprisingly, intentionally different from other languages, we will show you how to swim with the current rather than fighting it.
Learn within a system
Unlike other books, we will not relegate discussion of the essential tools of day-to-day development to appendices. We will teach you Blub in the context of a typical, batteries-included Blub programming environment. Including command-line tools, editors and editor extensions, testing tools, debuggers, tracing tools, etc.
We will definitely not give you a comprehensive introduction to any of these tools, but we’ll make sure you have pointers to more information for when you need it.
Be opinionated
We intend to equip you to write robust, legible, idiomatic Blub code. Toward this end, we will specifically call out elements of the Blub language and libraries that are:
- Sus: Inspired by the popular game Among Us, using sus features doesn’t automatically make you a saboteur of quality code… but you’d better know what you’re doing, and be able to explain yourself.
- Hinky: These features might not be outright warts, but they will almost certainly surprise you if you don’t realize how they differ from similar constructs in another language. E.g. the way a string containing the numeral
"0"
is considered “falsy” in PHP. Or the way Ruby will not automatically convert numbers into strings, and will instead raise an exception. - Bogus: Bogus features exist for backwards compatibility. They might even still be used by some programmers. But you shouldn’t use them. Example: the way C’s
strcat()
is unsafe at any speed.
That’s it
Blub is a programming language. You need to know Blub to get shit done. Let’s learn Blub.