I think _entirely_ ignoring the kinds of considerations it covers is such a typical failure case for inexperienced programmers (or non-career coders) that it's an excellent prod to expand the scope of what enters their awareness when writing code.
Ideally folks notice discrepancies between their experiences and the things it recommends and find their taste and judgement that way, though it doesn't always work out.
So like, maybe the fact that some of the advice is clearly dreadful if you try it could be a useful wedge against the kind of cult thinking so pervasive in software. I've seen considerably more grief from people treating his SOLID stuff like a bible that clean code. YMMV.
Important to note that the book is an adaptation of content from Sussman and Hanson's Adventures in Advanced Symbolic Programming course[1]. My sense is that the 'Flexibility' angle is a bit of a misframing, making it sound more like a rough and tumble best practices book, rather than an elaboration on neglected idioms from symbolic programming that they feel deserve wider adoption, paired with blue skies ideas on how to make software robust.
My friend Phil put this together for a React Native project, when he got fed up with the mess that standard Javascript module imports and direct dependencies created when introducing testing. It's been really pleasant to use, just a solid well-thought out library.
Let's be clear: I don't think this article has created any confusion. It's manipulative, like a lot of headlines that hit the front page - you click on it expecting one thing, and find another. It's not misleading in the way poor naming in technical contexts is misleading, so I think you're somewhat guilty of conflating different concepts yourself.
The substitution is a rhetorical device to deliberately draw comparison between different ways of approaching the same goal, i.e. being more effective as a programmer.
The author, I expect, would justify the sleight of hand by saying: the audience that believes most wholeheartedly in 10x programmers is precisely the audience that needs to hear how to benefit from low-hanging fruit that will make teams more effective. Really it's an old saw, "the brilliant jerk vs. collaborative team".
You're welcome to disagree with that assessment, but I'd suggest that responding to the particular contentions in the article is more worthwhile that overinvesting in a rhetorical dichotomy which has been used for effect only.
I don't think the advice entails lower quality discourse. The prescription here, read literally, is to say the same thing, phrased in a way that invites relevant discussion.
Language emphasising subjectivity can do several things - a) you signal uncertainty so that the group has a better idea of what's really known, b) you explicitly distinguish opinion from fact, c) you invite people to share their understanding so you can get on the same page.
The emphasis seems to be less the informational (a) and (b) and more the cultural (c). It's tricky - in some sense if you're certain, you undermine the force of your opinion this way. Comparing the two communication styles there's a tradeoff between reducing friction (unnecessary? examination) and encouraging communication in general, with possible benefits for cohesion, shared understanding and expertise but also the possible detriment of communal navel gazing. If you trust the studies this refers to, encouraging equal turn-taking overall has long-term benefits for productivity.
I think both approaches have failure cases where communication becomes ineffective. Individuals will adapt to each style to different degrees, and there's no total substitute for savvy folks who are alert to social forces at play, and guide discussions when team members over- or under-play their hands.
To share the generalisation used by this piece, the suggested conversational style is more hospitable to women. Where this article talks about psychological safety, equal participation etc., I think a lot of male engineers feel safe in much more confrontational and argumentative situations than women - they can even find a kind of fun in conflict, or regard it as totally impersonal, where many women would find it deeply unpleasant and to be avoided at all costs.
Clojure isn't a Common Lisp implementation, it's a different Lisp dialect with an emphasis on immutable data and interacting with host systems like the Java VM.
ah, well, for preexisting Keybase users with linked GitHub accounts it fits that description - I found out about it because I got given some without doing anything.
The 'airdrop' analogy doesn't really capture anything about the involvement of branching ledgers, so it doesn't seem entirely unfair to use the same giveaway jargon the community's previously used. But definitely, a different mechanism is involved here.
It's mostly interesting biologically - it relates specifically to how synapses' vicinity to the main cell body affects their action, or more generally how the spatial configuration of a neuron's connections affects its computational function.
The gist seems to be that more distant synapses can't initiate an action potential, or firing of the neuron, but can prime the neuron to fire in reaction to synapses closer to the cell body. This means that outer synapses can provide 'context', e.g. indicate that prior steps in a sequence have been recognised, while inner synapses can cause firing if the context is fulfilled, i.e. context + necessary condition (recognition of the most recent step in the sequence) = action potential.
It's not computationally surprising, but it is a specific cellular mechanism.
They're researching the behaviour of real neurons by making computational models, rather than creating a "neural network" model for AI purposes, so the definition of "single neuron" they're using is meant to reflect the original meaning of the term.
Imperative builds are a different mindset - where lein projects feel like a different language which emulates Clojure syntax, boot feels more like a library, and context switching is a favourite HN bugbear. Being able to program a build can be a boon, where otherwise you might've had to rely on the creator of your build tool catering to your special case with an appropriate flag.
In practice, though, I've never created a project with very interesting builds in either tool, I only dabble in Clojure. The test will ultimately be whether the community finds it useful.
If you're not into his style, GEB can be a bit perverse, but Hofstadter is genuinely excited by the ideas (and the games and wordplay he uses to convey them). If you look at the sum of his work, its tone comes across as pretty humble - humble for himself, that is; not apologetic for the ideas.
His latest with Emmanuel Sander, "Surfaces and Essences: Analogy as the Fuel and Fire of Thinking", is comparatively much more straightforward and less obfuscated, and still fascinating.
On the thermostat, I get the impression McCarthy was being a bit obtuse just to goad Searle a little. What he was illustrating is that simple systems can exhibit apparent intentionality while remaining simple. A steam governor or a thermostat are great examples. Living creatures, like the Aplysia californica snail studied by Eric Kandel, make use of analogously pretty damn simple mechanisms for reasonably sophisticated behaviour. Following this line of research, we've created remarkably effective systems like the 'syntax-only' Google Translate system, and IBM's Watson.
The questions posed by Nagel and Searle are interesting ones. Qualia is really difficult to account for - it makes sense for a materialistic system to have 'distinct placeholders' for different experiences, but why should they 'feel like' anything? Precisely because they propose a non-materialistic solution, they're difficult ones to explore - and so it's not really surprising that their own attempt to illustrate their perspective haven't been that convincing to materialists. The Chinese Room thought experiment is only convincing if you start out assuming the only thing that can 'think' is the person doing the card shuffling, which begs the question. See Hofstadter's Metamagical Themas for a good exploration of the argument.
If you're interested in sophisticated explanations of conscious experience and semantics from a materialist's perspective, Hofstadter and Sander's 'Surfaces and Essences' and Minsky's 'Society of Mind' and 'Emotion Machine' are great. Dennett's 'Intentional Stance' is also relevant - discussing how we can sensibly talk about material systems as having intention. Bear in mind that dualism is the more 'natural thought' in historical terms, and even hardcore materialists lapse into dualist terms easily. Researchers are rightly suspicious of unexamined assumptions. When it comes to science of the mind we have a history of novel, unnatural thoughts that are also very flawed (like Behaviourism), but critically, materialism (and Behaviourism) have both been productive.
One thing you can comfortably say about the progress of science is that at any point we're going to be partly wrong. Materialists are actively investigating and testing ideas, which meets my definition of 'real science'. Even if researchers are wrong on an important point, it doesn't make their work worthless, so you should probably hold back on the character assassination. Brain injury's effect on subjective experience and behaviour suggests to me that pure mechanism is important to experience, which is why materialism is my 'default hypothesis'.
If you want to ask hard questions, then go back and look at your assertions. What does 'really doing' semantics entail? How can the 'void' between semantic and syntactic systems be accounted for? Or, if we can't currently explain it, what can we do to investigate it?