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.
