Hypothesis 2: All successful statically-typed languages eventually grow large enough to have a dynamically typed scripting language embedded in them.
1 - dynamic languages, while granting great freedom, make it easy to shoot yourself in the foot with simple typing bugs, so we cope by adding type checking
2 - many (most?) static type systems are not expressive enough to type some programs, so people embed dynamic solutions to build the stuff they need.
Haskell is pretty decent at typing most stuff I want, but it makes me think about it up front, which is nice sometimes, but not always. Python lets me build stuff quickly and work out the design as I go, but it's hard to make sure everything works as intended. I wish there was something that let me bodge things together, but then constrain them with types when I need to...
Since Python has no 'compile' step, type-checking takes the place of compiling in other languages.
(iirc mypy has builtin support for namedtuple, but doesn't really support other types generated at runtime)
But big, successful programs will often do (2).
https://msdn.microsoft.com/en-us/library/windows/desktop/ms2...
The way dynamic is implemented is exactly following the same idea using DynamicObject instead of IDispatch.
https://docs.microsoft.com/en-us/dotnet/api/system.dynamic.d...
And if you actually bother to read MSDN documentation, one of the use cases for dynamic was to simplify COM automation interop.
https://blogs.msdn.microsoft.com/srivatsn/2008/02/04/dynamic...
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
COM integration with the CLR has existed since the beginning, which I used quite extensively many years ago, they just took advantage of the DLR to make it easier.
https://blogs.msdn.microsoft.com/hugunin/2007/04/30/a-dynami...
VB's variants and COM were not a consideration when conceiving of or designing the DLR, merely a convenient application.
Furthermore, integrating a dynamic type into C#'s type system absolutely built in the work on gradual typing. See their published work: https://www.researchgate.net/publication/221496299_Adding_Dy...
val s = "String"
val s:String = "String"https://herbsutter.com/2008/06/20/type-inference-vs-staticdy...
Examples are most text editors: emacs (elisp), Sublime Text (Python), Vim (VimScript), Atom (JavaScript). Many games and game engines: World of WarCraft (Lua), Unreal (UnrealScript), SCUMM, etc.
Dynamic codebases are rewritten in static languages to improve maintainability and code quality; programs written in static languages include an interpreter as a feature that supports user-defined programs, e.g., a browser's JS engine or emac's text editor and also for specialty domains where code quality is less important than developer velocity and the static language of choice is unnecessarily painful (games).
Assuming I didn't misrepresent your thesis, does this seem more or less accurate to you?
My feeling is that statically-typed languages and dynamically-typed languages are each better suited for certain kinds of problems. The former gives you better performance, long-term maintainability, and scales to larger programs. The latter gives you a faster iteration loop, is easier to learn, and is easier to dynamically load.
I think what happens is that any sufficiently large program covers so many different requirements that eventually different parts of the program are best implemented in different styles of language.
If you start statically-typed, you eventually get bogged down by the slow compile-reload cycle, need to dynamically load user-defined code, or what to express parts of the program in something higher level or more declarative. So you end up embedding a scripting or configuration language.
If you start dynamically-typed, eventually your program grows to the point that you either can't maintain it or it isn't fast enough, so you end up trying to bolt a type system onto your existing code or rewriting parts of it in a statically-typed language.
I think the costs for the latter are usually higher than the costs for the former, so I tend to lean towards starting statically-typed, but that's also because I'm comfortable using types.
Lua is of course popular and the topic of using it in games has been done to death: Love2D, Grim Fandango, Don't Starve, Cry Engine, Garry's Mod, etc.
Eve Online supposedly uses Stackless Python and I've seen Vampire the Masquerade Bloodlines (early Source engine) use Python.
Valve's wiki lists Squirrel, Lua, Python and Gamemonkey and they are all dynamic but I think Squirrel is the top language there.
I've also seen Angel Script in HPL1 (the Penumbra series by frictional) but it's another static scripting language and it markets this as a feature.
Unity of course has its C# 'scripts' which are static and I found the idea of scripting in such a behemoth of a language very novel when I've first seen it (yes, UnityScript has dynamic capabilities but it has static ones too and most of the users seem to be with C#).
SCUMM (and Z machine and similar) is a very weird case because it seems more like a script in the sense of a scene play (and the S might stand for script but they were naming utilities after gross stuff like CYST, MMUCUS, etc. so it might be shoehorned), not actual programming language, it's tied to the engine/game/genre/assets way more strongly than even Unreal Script was but I didn't do anything with SCUMM so I can't actually say for sure what would happen if you wrote something that didn't make sense (like tell a table to walk somewhere or reference an object or animation or something else that doesn't exist).
Many Naughty Dog games (including Crash Bandicoot games on PS1 which is frankly insane) also used their own Lisp inspired by Scheme called GOOL and then GOAL but I'm not sure how dynamic it was.
There's also a subtle line between embedding a language to make yourself scriptable and making yourself a library written in mix of C, C++ and that language and there is an interesting article on that[3].
GIMP also includes (or used to?) something related to Scheme/Lisp and has a system in place to support multiple scripting languages at once and calls between any of them called Procedural DataBase. Adobe Lightroom includes Lua too.
Id tech engines apparently used another language/technique each major engine version and I don't know the specifics of it at all.
I'm quite interested in the topic of extending applications (and specifically games) in various scripting languages, plugin systems, etc. but I'd not say all static programs grow dynamic scripting capabilities since AngelScript, Pascal Script (:D), Unreal Script and C# are all static 'scripting' languages and scripting in general is about 'scripting' (as in - small or big bits of code that is easy to change and safe to experiment with modifying a larger program in small or big ways), not necessarily dynamic programming (e.g. you could in theory every viably have Lua scripts in a larger Python program or even AngelScript scripts in a Python program to really mix it up and script a dynamic program with a static scripting language). You could also extend a C or C++ program with traditional 1990s/2000s style 'plugins' written in almost anything that can get the required ABI out into a dll/so and load, unload, reload, etc. those at runtime without stopping the main program.
[0] - https://wiki.beyondunreal.com/UnrealScript
[1] - https://api.unrealengine.com/udk/Three/UnrealScriptReference...
[3] - https://twistedmatrix.com/users/glyph/rant/extendit.html
Not having to write down the type isn't the same as the type not being determined at compile time, which is what "static" means.