Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It can be annoying though.

I think Rich Hickey has a point that bugs like this almost certain get caught by running the program. If they make it into production it usually results in an obscure edge case.

I’m sure there are exceptions but unless you’re designing for the worst case (safety critical etc) rather than average case (web app), types come with a lot of trade offs.

I’ve been on the fence about types for a long time, but having built systems fast at a startup for years, I now believe dynamic typing is superior. Folks I know who have built similar systems and are excellent coders also prefer dynamic typing.

In my current startup we use typescript because the other team members like it. It does help replace comments when none are available, and it stops some bugs, but it also makes the codebase very hard to read and slows down dev.

A high quality test suite beats everything else hands down.



An engineer getting up to speed on a 10 year old web app that uses dynamic types will likely have a very different opinion.

No types anywhere, so making a change is SCARY! And all the original engineers have usually moved on. Fun times. Types are a form of forced documentation after all, and help catch an entire class of bugs. If you’re really lucky, the project has good unit tests.

I think dynamic typing is wonderful for making software quickly, and it can be a force multiplier for startups. I also enjoy it when creating small services or utilities. But for a large web app, you’ll pay a price eventually. Or more accurately…the poor engineer that inherits your code in 10 years will pay the price. God bless them if they try to do a medium sized refactor without types lol. I’ve been on both ends of the spectrum here.

Pros and cons. There’s _always_ a tradeoff for the business.


I think you’re right.

But most startups aren’t building for 10 years out. If you use a lot of typing, you’ll probably die way before then. But yeah if you’re building a code base for the long term then use types unless you’re disciplined enough to write comments and good code.

As for refactoring, that is exactly what test suites are for.


> I think Rich Hickey has a point that bugs like this almost certain get caught by running the program.

That is certainly correct... but that doesn't make it a good thing. One wants to catch bugs before the program is running, not after.


Depends which is quicker. If I catch a trivial bug on the first run, I just saved myself writing the type system to find it ahead of time.


When a bug like this can cause real world harm, we can't just bumper car program our way out of things. As engineers we should be able to provide real guarantees.


I do agree for safety critical systems, you’re right.

But I don’t think we are engineers. Software dev isn’t like engineering. You can’t change the structure of a bridge after it has been built by deploying code to prod in a minute. Software dev is just software dev, it’s not engineering or science. It has some parallels with craftsmanship, but it’s unique.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: