Hacker News Reader

Comment by user3939382 | Hacker News Reader

There's a specific scenario where I have more sympathy for weak typing, which is: I'm writing a small, focused utility by myself whose scope can never expand and whose code will never be collaborated on. I do have these, little shell scripts. I write them, they work, I move on and use it for 10 years. No types in there, fine whatever.

As soon as there's any complexity at all or another person involved that exception stops.

View on HN

Note that weak typing and dynamic typing are orthogonal. I believe you're expressing sympathy for strong dynamic typing: types are checked an enforced dynamically by the runtime (such as Python raising an exception if you try to add a string and an int), but there's no static type analysis done at compile / load time. Python, JS, Ruby, etc. are strong dynamically typed languages.

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.

The C runtime, 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 statically typed, but weakly 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 in a Turing-complete language, as per Godel's incompleteness theorem and the halting problem, there will be some programs that cannot statically type-check but still will never encounter a type error, regardless of input. So, in practice, there will always be escape hatches in the type system to allow programs that are correct but not provable. 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. For some pairs of languages, you can say one's statically enforced properties are a superset of the other or that one runtime enforces a strict superset of the other's dynamic checks. However, it's often a case that you can't say one language strictly offers stronger static type guarantees or one runtime strictly enforces stronger dynamic type restrictions.

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

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

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

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.

Reply on news.ycombinator.com