Comment by AnimalMuppet | Hacker News Reader

Comment by AnimalMuppet | Hacker News Reader

Constraints provide freedom.

This is not Orwellian newspeak. In a Turing Machine, everything is possible. But nobody wants to program in it because it's too hard. Same thing with assembly. Everything that the CPU can do, you can do in assembly. But everyone wants out of assembly if at all possible. Why? Because the price for the freedom was too high.

Same thing with jumping to any line in a program. Sure, there are times when it could make your life easier, but they aren't very many. And what's horrible is when someone a decade ago, who doesn't even work there anymore, used it to make their life easier, and you have to figure out their bit of "cleverness". It's worth not being able to do that in order to keep that from being done to you. (This is the way civilized society works, by the way. I give up the freedom to kill random other people in order to not live in a society where I worry a lot about random other people trying to kill me.)

Within the constraints ("I can't do X"), you find two kinds of freedom. First, "I no longer have to worry about somebody else doing X in code that I need to work on". Second, "I gain Y".

For an example of the second kind, garbage collection means that I no longer have to keep track of when I should free memory. By giving up something (the ability to allocate and free memory myself), I gained freedom. This is a net win if I don't need the thing I'm giving up.

You're not trying to write something specific. Give up the things you don't need in order to write the program you're trying to write, if doing so reduces the number of things you have to do in order to write that program. Give up something you weren't going to use anyway in order to have less that you have to do. That's a win.

> Constraints provide freedom.

For a great video on this, see Runar Bjarnason's talk "Constraints Liberate, Liberties Constrain" (https://www.youtube.com/watch?v=GqmsQeSzMdw).

I've been slowly working on writing something up on this subject that shows how the constraint "energy must be conserved" allows us the freedom to solve a large number of problems just by describing them in terms of energy. Hopefully to tease out a more clarity on how we can transform abstract symmetries into practical solutions to real problems.

> "energy must be conserved"

I like this analogy! Are you thinking of “energy” as some measurement of the amount of freedom a specification gives implementors to make their own design decisions? (Possibly modulo some set of changes deemed “trivial”, like renaming identifiers, reordering independent statements, etc.)

I'm thinking of energy in the physics sense.

Oh, my bad. I'm certainly aware of the usefulness of the conservation of energy when you need to relate the initial and final states of a physical system solely under the action of conservative forces. But I thought you were talking about using the conservation of energy as an analogy for a strategy for tackling programming problems.

Energy is a linguistic construct for solving problems in abstract models of reality. That's not too different from how programming works, it's just a different set of models. Thus energy is just a special case of a more general problem solving technique which can be employed in other domains.

"Constraints provide freedom" is a nice saying but I think it's commonly applied to forms like poetry or sculpture. Unlike the discipline of creating a sonnet, virtually all modern programming languages provide few constraints on the form as a whole compared to the requirements of poems or realistic sculpture (whatever local hurdles they might involve) - remember the old saying: "A Real Programmer can write FORTRAN programs in any language".

I think programming languages do provide something unique and distinct from libraries.

Essentially a language is a generative, infinitely extensible tool. Another way to put it is that a language provides a geometry to move through the "space" of all possible programs. And different language make different potential programs closer.

> "Constraints provide freedom" is a nice saying but I think it's commonly applied to forms like poetry or sculpture.

Just like natural language can be used to write anything from poetry to shopping lists or even hate mail, programming languages can be used to write anything from beautiful code (say, a concisely expressed implementation of a nontrivial algorithm, based on a deep insight on the programmer's part) to mundane automation scripts or even spam bots and viruses.

> Unlike the discipline of creating a sonnet, virtually all modern programming languages provide few constraints on the form as a whole compared to the requirements of poems or realistic sculpture (whatever local hurdles they might involve)

I've found something very analogous to the discipline of writing a sonnet: writing programs where no single code path can fail. Where every single instruction or expression can be legitimately reached, and thus there is no need to throw exceptions or return error codes. For me, this is a form of art: the art of not branching more than it's necessary to. It requires a sense of aesthetics and an expressive technique far superior to those of most programmers, where the latter can be considered analogous to the native speakers of a natural language in which poetry is written.

> remember the old saying: "A Real Programmer can write FORTRAN programs in any language".

I'd love to see a Real Programmer write FORTRAN programs in Prolog, before yelling at the nearest person in frustration.

> Essentially a language is a generative, infinitely extensible tool.

Obviously, every general-purpose language lets you extend the universe of programs that exist. But relatively few languages let you extend the language itself, and even fewer do so in a disciplined way:

(0) Famously, Lisp and its derivatives let you define custom language constructs by essentially compiling them into Lisp using macros. Among the derivatives, particularly notable is Racket, which offers sophisticated ways to pattern match on syntax (objects).

(1) ML doesn't let you define new language constructs, but it lets you define abstract data types (not to be confused with abstract classes) whose internal representation isn't visible to its users, thus behaving as if they were primitive types.

i agree with your comment. limitation is what gives rise to creativity. however, consider that one can impose their own limitations. i can restrict myself to a subset of assembly, or c.

i would guess that even with today's popular verbose languages with hundreds of libraries, most programmers only know or use a subset of the language and libraries. strangely when i try to use these languages i feel too constrained. only because i feel i am trying to fit my own thinking into some other programmer's thinking.

sometimes this seems worth it. other times (most times) not.

whereas with assembly, i only have to fit my thinking to what the computer can do. this seems like what i should be doing if i am trying to program a computer.

> Constraints provide freedom.

My feeling when I program in ml / lisps. Limited set of abstractions and composition rules. Fuels my mind. My brain choke at the first mutable statement sequence.

ML lets you define just about any abstraction you want, and actually enforce it, both statically (using abstract types) and dynamically (using exceptions). The only thing that's limited in ML is which abstractions can be enforced using only static means.

ML is mostly sum and product types, function composition and induction (I never cared about patterns even though they're high grade convenience). The rest is up to my imagination I guess.

The module system lets you define abstract types. The module system is the first defining characteristic of ML, the zeroth being type inference. Without the module system, ML simply isn't ML.

The importance of abstract types can't be overstated: they can enforce nontrivial invariants of data structures (e.g., that self-balancing search trees are actually balanced), by just reducing the scope in which they could possibly be broken, and without bringing in the machinery of dependent types.

I don't disagree, but it doesn't contradict my point. ML module correlate functions. The basic feature that helped me are still there. I'd even say that without this I couldn't understand the value of Modules later on. Level zero functional programming enforce a strong thinking hygiene around parametricity. Modules and functors are just the next step.

> Constraints provide freedom. (...) This is not Orwellian newspeak.

This is just contravariance of function arguments. For every restriction on what the caller may supply, the callee earns the freedom to assume something about what it is supplied (namely, that the restriction holds). This is mathematically a triviality, of course. From a higher level point of view, the terminology might change, but the same essential fact remains: when a module/class/component/whatever author claims a freedom for themselves, they're denying freedoms to their users. This is inescapable.

The real problem is, if freedom is never absolute, but rather a matter of give and take between different software components, how do we find the right “distribution of freedoms” across software components? This is the essence of modular software design, and it's highly nontrivial.

Here's a nice quote for your personal collection:

"The more constraints one imposes, the more one frees one's self. And the arbitrariness of the constraint serves only to obtain precision of execution." - Igor Stravinsky

Garbage collected languages are slow though. So you are giving up performance.

"Programmer, you can only do things I know are correct" ===> "Programmer, you can do anything you want if you prove it's correct"

“Programmer, you can do anything you want if you prove it's correct and I can understand the proof.”

True

Did not you notice that goto bashing is out of fashion again this season? Mind updating your rant repertoire?

Reply on news.ycombinator.com