I agree and disagree. A +tool+ should make anti-patterns painful - yes. A +tool+ should not make hard things possible. My ideal +environment+ is one which allows me to choose the most appropriate paradigm/tool for the sub-problem that I want to think about. That ideal environment should make it easy to compose solutions to uber-problems by plumbing sub-solutions together, regardless of the paradigm used. To make hard things possible, I should be able to use Assembler (line-oriented or tree-oriented (Assembler, C, etc. vs ASTs, CSTs, Lisp)) and bolt these bits into the overall solution. The last time I touched such an environment, was the UNIX command-line (#!/bin/bash, #!/usr/bin/env node, #!/usr/bin/env python, etc., etc.). The problems with the UNIX Shell are (1) it over-specifies (!) the format of IPCs by insisting that the special byte 0x0a terminate every blob of IPC bytes, and, (2) the Shell’s insistence on using 1D notation (sequential characters, leading to the unrealistic restriction that commands have exactly one input and exactly two outputs (the UNIX kernel allows more of each, but the shell does not encourage this)).