Indeed this. There are benefits. Less code, faster to write.

You are the other person. Come back in six months needing to make a change, and it's almost like you're new to the code.

Now, in general, I agree with you. If it's a one-off (or if it's really never going to need maintenance), and if it's small enough that you don't need types while writing it, then sure, do whatever is easiest at the time. But "never going to need maintenance" often turns out to be a lie, and when that time comes, you may be happy for some types as signposts to give a hint of what you were thinking all those months or years ago.

This is the trojan horse dynamic types use to get into your castle :P

I want a shell scripting language that allows a max line length of (for example) 128 characters and a max script length of (for example) 128 lines, with no `source` equivalent. If the script expands to not be a "small, focused" single-file script it should just fail to run at all. Just enough for small utilities, but unusable for giant monstrosities.

... and unable to call external programs or communicate with external programs via pipes / sockets / etc.?

Otherwise, if you're unable to source another script, you could just have another script return a normal result in addition to a JSON blob of the environment variable changes the caller should make, which is probably worse than just allowing sourcing.

Pipes allow arbitrarily complex networks of communicating sequential processes. In some cases, networks of tiny CSPs are cleaner, but without discipline, they can rapidly become worse than huge monoliths.

I suppose I should just say "any sourced file counts against the length limits".

That doesn't prevent the problem of length limits encouraging users to break their programs into networks of smaller programs communicating over pipes. I'm sure that sort of thing can be done well, but it certainly takes discipline.

Particularly as programs start out simple and organically grow, once they start hitting length limits, they're going to start evolving into locally-distributed computation. Maybe you get something nice like composable small unix-like utilities. However, I suspect there's a large overlap between the set of developers who would do that well and the set of developers who would still keep things nice and modular within a single process if they didn't have size limits.

Note that weak typing and dynamic typing are orthogonal. I believe you're expressing sympathy for strong dynamic typing: types are checked an enforced by the runtime, but there's no static type analysis done at compile / load time. Python, JS, Ruby, etc. are strong dynamically typed languages.

The C runtime, on the other hand, will gladly (with UB nasal demon caveats) allow you to treat an int as a pointer. There are static type checks, but no hard limits on the type-confused nonsense it will attempt to execute. C is weakly statically typed.

Java, C#, etc. are strong statically typed. There are static checks at compile time, and the runtimes do their best (modulo escape hatches) to use dynamic runtime type checks to plug the gaps in the static type systems. (For any sufficiently complex sound/consistent type system, as per Godel, there will be some type-correct programs that cannot statically type-check. So, in practice, there will always be escape hatches in the type system. Hopefully most of these escape hatches are backed by dynamic runtime checks.)

Of course, these categories are a partially-ordered continuum, not clear binary distinctions. Also, type weakness is more a property of the runtime than the language, but for those languages with specifications, the language specification usually also specifies a large amount of behavior for a compliant runtime.

I’m aware of the difference, I was contemplating bash in my comment. Some people construe it as strongly typed though it’s a little ambiguous, here’s another discussion about it https://news.ycombinator.com/item?id=12704050