4 ms·

It's strange that you make this incorrect comparison to static and dynamic typing. As with static typing, an automated tool prevents you from doing something. I

by voxl 6y ago

It's strange that you make this incorrect comparison to static and dynamic typing. As with static typing, an automated tool prevents you from doing something. It comes for free at the cost of you needing to satisfy the tool. Where is this in a monorepo? You make it sound like the company itself must invest in assuring that the rules are not broken. That sounds like _dynamic_ typing to me.

triceratops 6y ago
> As with static typing, an automated tool prevents you from doing something. It comes for free at the cost of you needing to satisfy the tool. Where is this in a monorepo? In a monorepo if your change breaks someone else's code, you'll know immediately because you won't be able to check in the code with a breaking build. If you have the correct monorepo tooling set up it will help you figure out what you're breaking. With multi-repos others will have to upgrade to your new version and then see that their code is breaking. GP's analogy was imperfect because as you pointed out the company has to invest in the monorepo tooling. But it makes sense to me.
gen220 6y ago
> Where is this in a monorepo? You make it sound like the company itself must invest in assuring that the rules are not broken. My argument, as made in the original comment, is that a monorepo is not a git repository. It is a git repository, a build tool / dependency graph manager, and a continuous integration system. In the same way, a statically-typed project is not a collection of source files. It is a collection of source files, a linker, and a compiler. The linker and compiler do not come "for free" any more than a build tool / ci system do, although they have been around for a very long time so you might consider them part of the background. In a well-structured monorepo, the build tool and ci system are as much in the background as `gcc` or `go build` might be.

by voxl 6y ago

triceratops 6y ago

> As with static typing, an automated tool prevents you from doing something. It comes for free at the cost of you needing to satisfy the tool. Where is this in a monorepo? In a monorepo if your change breaks someone else's code, you'll know immediately because you won't be able to check in the code with a breaking build. If you have the correct monorepo tooling set up it will help you figure out what you're breaking. With multi-repos others will have to upgrade to your new version and then see that their code is breaking. GP's analogy was imperfect because as you pointed out the company has to invest in the monorepo tooling. But it makes sense to me.

gen220 6y ago

> Where is this in a monorepo? You make it sound like the company itself must invest in assuring that the rules are not broken. My argument, as made in the original comment, is that a monorepo is not a git repository. It is a git repository, a build tool / dependency graph manager, and a continuous integration system. In the same way, a statically-typed project is not a collection of source files. It is a collection of source files, a linker, and a compiler. The linker and compiler do not come "for free" any more than a build tool / ci system do, although they have been around for a very long time so you might consider them part of the background. In a well-structured monorepo, the build tool and ci system are as much in the background as `gcc` or `go build` might be.