>If dynamically typed languages are really okay for smaller systmes, than avoiding bad architecture of large tightly-coupled systems in favor of loosely coupled compositions of smaller subsystems means that it is also okay for large systems.
It doesn't mean that at all. You might as well say "if shoes are good enough for going to the corner store, then multiple pairs of shoes are good enough for going to the moon". The notion that large systems are no more complex than small systems if you simply make the large system out of small systems is not supported by anything I can find.
>IME, that's why they've historically been harder to read and navigate for humans
That doesn't make any sense at all. How is having information written down instead of having to constantly remember and/or deduce it an impediment to reading?
> It doesn't mean that at all. You might as well say "if shoes are good enough for going to the corner store, then multiple pairs of shoes are good enough for going to the moon".
A large system can be decomposed into a set of loosely-coupled smaller systems (indeed, that's often a preferred architecture for a variety of reasons independent of whether the language is static or dynamic).
A trip to the moon cannot be decomposed into a series of walks equivalent to a walk to the corner store.
Therefore, no, your analogy is not valid.
> That doesn't make any sense at all. How is having information written down instead of having to constantly remember and/or deduce it an impediment to reading?
Visual (and mental, really) noise, mostly -- there is a reason why clear, effective, easy-to-read writing is often not writing that avoids all potential ambiguities and is sure to define as much as possible to avoid people having to deduce things. Making everything explicit is generally generally in tension with readability, not an aid to it.
You don't achieve freedom through bad software. What the hell? Note that the NSA spying on you is also facilitated by all the complex, buggy, broken software we use.
In many cases a few examples and type signatures are enough for the intermediate Haskell user. Virtually all packages for Haskell are free software though, so you can of course contribute documentation if you feel there ain't enough, because obviously if the current Haskell users don't need more docs they won't write it.
I find records are used most heavily in web development, where you are pretty much just shuffling data from browsers to databases and the other way around. But even there the field name thing doesn't pose much of a problem, I prefer defining my records in the module that handles the functions for it, so there's no issue with conflicting names anyways. I found the fact that 'id' is a standard library function to be a bigger minor annoyance.
It doesn't mean that at all. You might as well say "if shoes are good enough for going to the corner store, then multiple pairs of shoes are good enough for going to the moon". The notion that large systems are no more complex than small systems if you simply make the large system out of small systems is not supported by anything I can find.
>IME, that's why they've historically been harder to read and navigate for humans
That doesn't make any sense at all. How is having information written down instead of having to constantly remember and/or deduce it an impediment to reading?