Programming Languages Quotes

“While functions being unable to change state is good because it helps us reason about our programs, there's one problem with that. If a function can't change anything in the world, how is it supposed to tell us what it calculated? In order to tell us what it calculated, it has to change the state of an output device (usually the state of the screen), which then emits photons that travel to our brain and change the state of our mind, man.”
― Miran Lipovača

“Rust’s central feature is ownership. Although the feature is straightforward to explain, it has deep implications for the rest of the language.

All programs have to manage the way they use a computer’s memory while running. Some languages have garbage collection that constantly looks for no longer used memory as the program runs; in other languages, the programmer must explicitly allocate and free the memory. Rust uses a third approach: memory is managed through a system of ownership with a set of rules that the compiler checks at compile time. None of the ownership features slow down your program while it’s running.”
― Steve Klabnik, The Rust Programming Language

“In languages with a garbage collector (GC), the GC keeps track and cleans up memory that isn’t being used anymore, and we don’t need to think about it. Without a GC, it’s our responsibility to identify when memory is no longer being used and call code to explicitly return it, just as we did to request it. Doing this correctly has historically been a difficult programming problem. If we forget, we’ll waste memory. If we do it too early, we’ll have an invalid variable. If we do it twice, that’s a bug too. We need to pair exactly one allocate with exactly one free.

Rust takes a different path: the memory is automatically returned once the variable that owns it goes out of scope.”
― Steve Klabnik, The Rust Programming Language

“Inheritance has recently fallen out of favor as a programming design solution in many programming languages because it’s often at risk of sharing more code than necessary. Subclasses shouldn’t always share all characteristics of their parent class but will do so with inheritance. This can make a program’s design less flexible. It also introduces the possibility of calling methods on subclasses that don’t make sense or that cause errors because the methods don’t apply to the subclass. In addition, some languages will only allow a subclass to inherit from one class, further restricting the flexibility of a program’s design.

For these reasons, Rust takes a different approach, using trait objects instead of inheritance.”
― Steve Klabnik, The Rust Programming Language

“It is possible, indeed important, to be able to separate these two notions—to create procedures without naming them, and to give names to procedures that have already been created.”
― Harold Abelson, Structure and Interpretation of Computer Programs

“You’re building your own maze, in a way, and you might just get lost in it.”
― Marijn Haverbeke, Eloquent JavaScript: A Modern Introduction to Programming

“The keyword const doesn’t turn a variable into a constant! A symbol with the const qualifier merely means that the symbol cannot be used for assignment. This makes the value read-only through that symbol ; it does not prevent the value from being modified through some other means internal (or even external) to the program.”
― Peter van der Linden, Expert C Programming: Deep C Secrets

“The most important thing in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language.”
― Donald Knuth

“The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.”
― Geoffrey James, The Tao of Programming

“Q: Why bother doing proofs about programming languages? They are almost always boring if the definitions are right.
A: The definitions are almost always wrong.

- Anonymous”
― Benjamin C. Pierce

“When the ANSI C standard was under development, the pragma directive was introduced. Borrowed from Ada, #pragma is used to convey hints to the compiler, such as the desire to expand a particular function in-line or suppress range checks. Not previously seen in C, pragma met with some initial resistance from a gcc implementor, who took the “implementation-defined” effect very literally—in gcc version 1.34, the use of pragma causes the compiler to stop compiling and launch a computer game instead! The gcc manual contained the following: The “#pragma” command is specified in the ANSI standard to have an arbitrary implementation-defined effect. In the GNU C preprocessor, “#pragma” first attempts to run the game “rogue”; if that fails, it tries to run the game “hack”; if that fails, it tries to run GNU Emacs displaying the Tower of Hanoi; if that fails, it reports a fatal error. In any case, preprocessing does not continue. —Manual for version 1.34 of the GNU C compiler”
― Peter van der Linden, Expert C Programming: Deep C Secrets

“We invented a whole new class of computer programming languages known as list processing languages. The basic idea is that whenever a piece of information is stored in memory, additional information should be stored with it telling where to find the next associated piece of information.”
― Herbert A. Simon, Models of My Life

“A lot of people want to make badly designed programming languages easier to use by giving them fancy IDE’s. This makes sense if you are forced to use a badly designed language. I think it would be better to try making well designed languages instead.”
― James Moen

“A Japanese programming manager put it this way at a computing conference (in Japan), "The important language for the programmer to know well is not JCL or PL/I, it is Japanese!”
― Richard C. Linger, Structured Programming: Theory and Practice