3 ms·

Why not? I would be curious to see how people tackle large, complex web software in an efficient way - that is with tools support, not by fighting against them

by blub 11y ago

Why not? I would be curious to see how people tackle large, complex web software in an efficient way - that is with tools support, not by fighting against them and working around inadequacies. Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing. And here's some examples of complex software for comparison: image editor, digital audio workstation, CAD, video conferencing, computer vision & imaging, office suite, large games (think DeusEx, not minesweeper). Not complex: almost anything CRUD

forgotpwtomain 11y ago
> Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing Unit tests are checking a lot more than argument type.. I have no idea what environment you worked in, but the comment comes across as rather clueless.
- lmm 11y ago
  Unit tests check a lot more than whether the argument is Int or String, but so do good type systems. I'd say your comment comes across as more clueless.
- MustardTiger 11y ago
  A huge portion of unit tests are doing exactly that. Many people simply don't realize how many problems are actually type problems. Like null/nil/whatever as the most trivial example. It is more likely that your comment is made out of ignorance than the one you replied to.
- blub 11y ago
  The 50% heuristic comes from a story I read once about a company claiming they were able to build a ~200 kloc app in a dynamic-typed language. The secret was their ~200 kloc unit test suite. :) It has nothing to do with argument types per se, just that one must have very high coverage in order to be able to be reasonably sure that their app won't crash after minor code changes. In my current project we can get away with having integration tests cover a lot of ground and only unit test what makes sense thanks to static typing. High coverage is good to have, but should be balanced with test development and maintenance effort.
carsongross 11y ago
Mmm. By that definition, I would not define the software I built as "complex". But I also wouldn't define Facebook, GMail or Stripe's web app as "complex" either, and I see folks using very complicated client-side technology to build those "simple" apps. I use intercooler.js, which I built, and which I shill heavily because I'm quixotically trying to fight the Facebook/Google 80's-style-thick-clients-in-javascript zeitgeist.

by blub 11y ago

forgotpwtomain 11y ago

> Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing Unit tests are checking a lot more than argument type.. I have no idea what environment you worked in, but the comment comes across as rather clueless.

lmm 11y ago
Unit tests check a lot more than whether the argument is Int or String, but so do good type systems. I'd say your comment comes across as more clueless.
MustardTiger 11y ago
A huge portion of unit tests are doing exactly that. Many people simply don't realize how many problems are actually type problems. Like null/nil/whatever as the most trivial example. It is more likely that your comment is made out of ignorance than the one you replied to.
blub 11y ago
The 50% heuristic comes from a story I read once about a company claiming they were able to build a ~200 kloc app in a dynamic-typed language. The secret was their ~200 kloc unit test suite. :) It has nothing to do with argument types per se, just that one must have very high coverage in order to be able to be reasonably sure that their app won't crash after minor code changes. In my current project we can get away with having integration tests cover a lot of ground and only unit test what makes sense thanks to static typing. High coverage is good to have, but should be balanced with test development and maintenance effort.

carsongross 11y ago

Mmm. By that definition, I would not define the software I built as "complex". But I also wouldn't define Facebook, GMail or Stripe's web app as "complex" either, and I see folks using very complicated client-side technology to build those "simple" apps. I use intercooler.js, which I built, and which I shill heavily because I'm quixotically trying to fight the Facebook/Google 80's-style-thick-clients-in-javascript zeitgeist.