Hacker News Reader

Comment by scarface74 | Hacker News Reader

So by using a dynamic language, you trade the cost of a long build time with possible runtime errors that would have easily been caught by the build system? Instead of paying the cost once per build you are now inflicting runtime errors on your customers.

View on HN

No. In every large system I've ever seen, there's large dynamic components. Avoiding existing dynamic languages entirely simply means building your own ad-hoc one, which is neither more robust nor more efficient (at development time or at run time). You're trading "known, working dynamic system" for "unknown, homemade dynamic system". (In other words, Greenspun's Law holds true.) There isn't a third choice where users simply stop wanting features which are easily implemented in dynamic fashion.

Every web browser today includes lots of modules written in JavaScript. Every web browser today also has lots of bugs. But nobody believes that rewriting all their JS in C++ would improve the situation. For all the complaints I've ever had about Firefox/Safari/Chrome, "I got a JS TypeError" has somehow never once come up.

And how many ignored JS errors do you see when you look on the web console? Don’t you want a little more robustness on the backend?

I’ve never in 30 years of development needed to make an adhoc dynamic language for a large system. I use Python for simple scripts and JS because you have to for the browser.

Is there a strong, real world correlation between heavy use of dynamic languages, and a poor user experience (versus competitors, for example)?

The theory that it would makes sense to me, but I suspect other factors outshadow any effect it might have.

For example, I haven't heard that Facebook, Instacart, Booking.com, WordPress.com, etc, have stability or experience issues worse than their competitors.

Well, the costs are once per every build, which can take many hours, as the author describes it, even be only available on the next day. Static typechecking is a valuable tool, but it shouldn't be as the solution for all correctness problems. Testing is another. And when the build times become too large, testing suffers. Finally, it is absoultely possible to have dynamic languages with type declarations which can be automatically checked.

So now you trade reduced build times for increase in the amount of developer time for creating extra tests that check for type correctness and you increase the “build” time by having your build system run more tests?

And once you have type declaration that can “automatically” be checked - something has to run against the same code base to check the correctness of your code and you’re back to increasing your build time?

No. With dynamic languages, one gets not only "reduced" build times, they are instant. Testing for correctness needs to be done with any kind of language. Type checking is not a replacement for that. But you can add the necessary type declarations to dynamic language to facilitate static type checking if desired. These checks don't influence the build time significantly.

As written in my first post, using dynamic languages is only one way of improving development times. The other of course is, use languages which allow for fast compilation.

> But you can add the necessary type declarations to dynamic language to facilitate static type checking if desired. These checks don't influence the build time significantly.

Indeed, type checking is rarely the slowest compilation stage for most languages.

Reply on news.ycombinator.com