michaelfeathers

Confirmation bias. Once you start looking for confirmation bias you see it everywhere.

The key insight is that immutability is not an end in itself, it's a tool to give us referential transparency.

If a language can allow mutability in an area of code without allowing side effects to escape from it we can have all of the reasoning advantage that FP gives us at a level above the mutations. We can also have the performance we want.

Agreed. Breaking changes can lead to alienation of user base, but I think there's a danger in lulling people into expecting that kind of constancy in software. It creates dependency of another kind. Maybe the trick is to vary features at some rate, getting users used to change and bringing them along.

In retail it used to be the case that you could go to the same store a month later and see the same shirt to buy. The Sears catalog [1] presented that sort of constancy for consumers. Today there's a lot of flux. Some of it actually engineered to prevent people from delaying purchasing decisions. In software we can and do introduce breaking changes for ease of maintenance, and that can be ok as long as people are used to it. It's making the choice to have a living ecosystem.

[1] http://www.searsarchives.com/catalogs/history.htm

That's Postel's Law.

> If you build a system that doesn't deal with spam, it gets drowned in spam. If you build a system that doesn't deal with abuse, abuse becomes commonplace. If you don't secure your IoT devices you get journalists DDoSed by lightbulbs. It's the same kind of social responsibility.

I think it's deeper than that, it's Inverse Conway's Law_. Reddit was fine before they introduced sub-reddits. It used to be a nice "not quite so tech" HN. Sub-reddits allowed very different cultures to form and easily war with each other.

Conway's Law states that systems end up with structure that mirrors the structure of the teams that design them. The inverse is true too. Social systems tend to mirror geographical (or in this case, technical) structure.

I'd want to see an automated test suite for the build.

I think the 'ravioli code' moniker is really a slight on good code. It just takes some time to become acclimated to the style of having many smaller pieces. That said, over-engineering is real. Unnecessary layering should go away.

> That doesn't even address the hard part.

Fair enough. I did write a book on the other parts, though. https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...

The thing about unit testing existing code is that it is much easier than most people think: https://michaelfeathers.silvrback.com/characterization-testi...

The modern equivalent is called 'ravioli code' http://c2.com/cgi/wiki?RavioliCode

"thousands of little classes everywhere and no one knows how to find the places where things really happen."

I think the industry is on the cusp of settling on the Erlang model which is essentially allowing pieces of a program to crash so that the whole program doesn't have to. It will take time for practices and tools to spread.

> but it's still a gotcha for the audience this blog post is aimed at.

Would be nice if they had a pointer to the reason, however.

The behavior of 'assert' is not an anomaly. It comes from 'design by contract.' Assert is primarily meant to be documentation of constraints in code and secondarily a way of catching errors during development.

"Contract conditions should never be violated during execution of a bug-free program. Contracts are therefore typically only checked in debug mode during software development. Later at release, the contract checks are disabled to maximize performance." - https://en.wikipedia.org/wiki/Design_by_contract

Exactly.

The experience of other language communities is: you'll get used to it. When C# introduced its version of this with the 'var' keyword many felt that code would become less clear but, in general, context gives you what you need. If it doesn't that often means that there are other problems.

I don't know if this is true in your case, but often people who object haven't spent much time working in dynamically typed languages. The readability issue is orthogonal to typing and it tends to be fine.

It's just the same issue at another level. There's no reason that something can't have both properties. The issue is that it jars our preconceptions, which are formed from the things we've encountered so far. We want to understand things in terms of what we've seen. That's a basis of analogical reasoning.

It's kind of like the "monad tutorial" problem in software. Everyone tries to reach for analogy for that computational structure. Although there are some decent ones, in the end, people who work with monads just have to accept the monad laws (sort of a parallel to the data that physics has on quantuum phenomena) and eventually they develop a sense of what they are independent of cafeteria trays and burritos ( http://codetojoy.blogspot.com/2009/03/monads-are-burritos.ht... )

Exactly. Thinking about it more. Imagine we came at it from the other direction. All we know are quantum phenomena and then we encounter this human-scale world. We would be amazed and stunned by things like billiard balls that behave only half like quanta.

I'm surprised this way of seeing the world isn't more wide spread. My opinion is that it should be among people who have a deep interest in science.

> Quantum field theory is weird, but there are much more compelling analogies in classical world than particles.

As a teen I read a book by Robert Anton Wilson that made an interesting point. We have experiments showing wave-like and particular-like behavior but all we have is that data and we can accept it at face value without having to impose the idea of a wave or a particle on it. "Waves" and "particles" are, like you say, analogies.

There's no particular reason the phenomena can't behave like both, and, in fact, they do. It's only a paradox if we choose to analogize. We don't have to.

As Korzybski said "the map is not the territory." Trying to resolve wave/particle duality is trying to impose one of two maps from other territories to a new one.

This is space that the Clojure community has already visited.

I think the real problem is being able to distinguish between criticism of a language and criticism of the people using it. The former is ok, the latter isn't.

If we take a criticism of a technology we use as criticism of us, it's a rather unhealthy state to be in. Technologies come and go. They aren't something we should immerse our identity in.

It's a metaphor and it can definitely be taken too far. One of the abuses I don't care for is the notion that Technical Debt can be quantified and calculated for a code base. That's wrong in a number of different ways.

I'm convinced that the issue overall is lack of transparency about design quality. In an org with non-technical leadership, technical staff should periodically present assessments of their systems' readiness for change. Non-tech people need to understand technical debt and see how it changes over time.

In my experience, companies with technical founders tend to have cultures that handle this issue better.

I used to call them 'Prosthetic Goals' http://michaelfeathers.typepad.com/michael_feathers_blog/200...

I think it's more graph theory than distance. A fully connected graph costs more than an minimal spanning tree.

The deep learning is that there are forces that lead to centralization: generally they are variations of human choice and seeking economies of scale.

For instance, it's no accident that we started with hundreds of thousands of small websites and ended with most traffic going to a few. Ask yourself how the internet could have been constructed that would have prevented sites like Facebook or Twitter winning the popularity contest. The 'Power Law' dynamics behind this are the same ones that lead to some airports being hubs and others not, the fact that there is a backbone rather than everything going point-to-point, and many other phenomena.

We can have decentralization but there are costs. Someone has to pay them.

I think it's inevitable we'll use some of their toolset. The problems we solve don't get easier so we will reach for more powerful tools.

As an example, just being able to think in terms of a transpose makes many problems trivial: http://michaelfeathers.silvrback.com/moving-quickly-with-com...

Prediction: APL, J, K, or Q will be on this list soon.

True, the efficiency argument is wrong. Thinking about your algorithm and knowing where you actually need to be efficient are far more important.

What I appreciate about C in particular is that it seems harder to "program by accident" than it is in most languages. C was my first language. After I learned C, I programmed in a higher level language for a while later before discovering that its runtime threw exceptions on 'array subscript out of bounds.' I discovered it by looking over someone else's shoulder in a lab. I realized then that I had just learned not to do that because C was so unforgiving.

We can argue whether the kind of discipline of thought that you gain from that experience is good or even useful today, but I suspect it is. It's different from learning how to do mental math in a world full of calculators - that's just raw mental exercise.

There's this one. It isn't deep. More about making people aware: https://www.youtube.com/watch?v=UX7xmhpUoi4

I've given some talks making the case that what we are doing with Java streams, LINQ, Rx, Ruby Enumerable, point-free style in Haskell, etc is prepping us for array languages.

They are all emphasize transformation pipelines. What the array languages bring to the game is shape polymorphism and many more operators. I suspect we'll see both move into more mainstream languages over the next 5 years or so.