The backlash against scripting languages has begun

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 13 May 2016 at 09:57:16 UTC, Chris wrote:
> "basing themselves on interpreted, slow languages that favoured 
> ‘easy to learn’ over ‘easy to maintain’."

"Easy to learn" often correlates with "easy to maintain". I think 
you are referring more to static typing vs dynamic typing.

Sure, catching problems at runtime is not the best option, but 
C-like languages have plenty of sources for runtime errors, so it 
isn't that big of a difference. Especially now that gradual 
typing is becoming popular.

> Yep. Frustration kicks in sooner or later. I always tell people 
> not to use scripting languages for bigger or real world 
> projects.

You mean like gmail,  youtube, Visual Studio Code, emacs...?

Anyway, self-modifying code is in general a bad idea, except in 
situations where you build a compatibility layer. So, no, "monkey 
patching" isn't universally bad. It is only bad if you don't keep 
it on a separate layer. Patching up a runtime environment (such 
as a web browser) with polyfills makes for more maintainable code 
than versioning/feature-detecting conditionals in the core logic 
of the program.

In the real world you don't get to define your running 
environment. You adopt to the actual running environment. If you 
can get away with creating a compatibility layer then that almost 
always makes for more maintainable code. "monkey patching" is 
sometimes an effective strategy to getting that compatibility 
layer in place, or simply fixing bugs in the runtime on legacy 
platforms.