sumofzeros's comments

Which raises the following question: is it better to leave the potential source of problem around as long as it's not triggered, or is it better to temporarily activate it in order to remove it for good?

Sorry for the bluntness of my question: I only have little experience in using Python, which I acquired while trying out Django, and I remember using scripts to generate certain parts of the site (things might have changed since then?).

To be fair, Django is pretty good: iirc, it induces good discipline for development, which is perhaps why it is so easy to handle a large codebase.

On the other hand, the business logic is outside the scope of Django (or any other framework), and there, if the devs do not follow good practices and develop the right tools, it might be more difficult to be productive.

The way I see it, people using dynamic languages have much more freedom in development, but also less safeguards, which means that they have to build them to make their code more robust. Having code generators is a way of getting back some safety, because you only have to make sure the generators are producing correct code.

Custom code, however, need to be thoroughly tested to be considered safe, and if the compiler doesn't do any type level consistency check, it's that many more tests that needs to be written, which adds up to the LOC count.

You'd probably love COBOL too, it's closer to plain English than most other programming languages out there.

> 50K LOC python/django codebase.

How much of it is generated?

> When was the last time you saw a systems language that scaled comfortably and gracefully from embedded systems to web services?

Have a look at ATS[1], it supports many features that are available in Rust, and let you build proofs about your code behaviour. It's quite type annotation heavy though iirc, but it's very efficient.

[1] : http://www.ats-lang.org