Even when you disagree with his ideas, Rich Hickey’s talks are well worth a listen. I always learn something, and find I disagree less and less every time.
I’m normally in favour of type-driven design with static types for large programs, but I have to agree with his points here:
@cbowdon a lot of interesting thoughts here (and also some straw - [a] -> [a]?! It has exactly the same problems as a map with “data” as the key).
They also trigger my pet peeve with software engineering. They make lots of factual claims - type systems don't catch significant errors, type systems make maintenance harder, and so on - but don't even handwave about reliable *evidence* for those claims.
Software engineering is mired in dueling anecdotes. We *know* so little.
@RAOF Yup, it’s more a philosophical discussion than a scientific one. The problem is there is wide variation in software projects so there will be very few hard facts.
On type systems: I have been working lately with a Java application that is just a class soup, with multiple representations of the same objects everywhere. Definitely a net negative there.
But then yesterday I turned Mypy on a legacy Python application and picked up errors immediately. It always varies. 🙂
@cbowdon I disagree - just because there are a wide variety of software projects doesn't mean there are few hard facts. Rather that there may be *more* facts, only some of which apply to a given project (and dinner which apply to all - there's a wide variety of bacteria, but antibiotics kill them all).
@RAOF By hard facts I mean rules that apply absolutely in every situation, and as you say in different projects rules will be applicable to a different degree. Or it may be necessary to find a tradeoff between conflicting facts, e.g. balancing “functional style leads to fewer bugs” against “idiomatic style is more readable” and consider constraints like “only Java has the necessary Foo library”.
Agree on Java’s types. Unsure if any type system is better than no type system.
@cbowdon I think that's an unnecessarily restrictive definition of “hard facts” - virtually nothing applies absolutely in every situation in *any* discipline.
I think a more useful definition is a rule that we *know when it applies*.
@cbowdon And where there are tradeoffs - like your functional-style vs idiomatic example - there exists a point which maximises the property you're after (bug-freeness, or whatever) for a given problem domain.
We don't *know* what that point is, but it exists as a potentially-discoverable empirical fact about the universe, rather than a philosophical position.
@RAOF I’m not convinced on there being an empirically discoverable optimum balance between rules. These aren’t continuous and objectively measurable things and in some cases there will be logical contradictions. Add to that the truly variable stuff like the performance of an engineer at a given point in time and there is a large uncertainty. If you can’t agree with it being more like “philosophy” then how about “(macro)economics”?
@RAOF I hear you in the need to do some research, but it’s important to understand the limitations. There are definitely good default positions that can be backed up with evidence (e.g. TDD) but there’s enough variability/uncertainty that we can’t treat it like hard science.
@cbowdon I think Psychology is a really good comparison - it's obviously not a hard science, but there's also a bunch of empirical work done and known; so much that there's a reasonable base of theoretical knowledge we're moderately confident about.
If only software engineering was as rigorous as psychology 😉
@RAOF Yeah I’d say that comparison is very suitable. The human mind aspect of coding is a major part of it.
I can see that developing into a future profession. “Hi, I’m an Agile Psychologist” 😜
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!