> However, a senior programming educator and a former engineer told me that > such a language is impossible due to the "Church-Turing thesis".
In all honesty, this is a bad and unrelated answer (and kind of a cop-out). Nim is not trying to question conundrums of computability, Nim is questioning conundrums of language design and engineering. Really, I like to think of Nim as **taking up the mantle where Lisp tried and failed.** My honest view, after five years of using Nim, is that Nim is really a kind of Lisp aiming to rectify against Lisp's historical follies; for example: * the dynamic typing-by default model (some Lisps tried to adopt an optional typing model, but it's really important that the base language itself has a strong "ground floor" in and of itself and not to just depend on DSLs of questionable integrity) * the overall lack of attention given to memory management (Lisp pioneered the use of refcounting in programming, but failed to adapt itself to its conclusions) * a syntax that focuses more on _human readability_ instead of being _just_ a visualized form of the AST So why call Nim a "Lisp?" Because what makes Lisp stand out from the most popular languages of today is not the typing model or idea of using GC (both of which are ubiquitous), but the belief in entrusting the programmers with a really flexible metaprogramming model beyond mere generics or substitution macros, and thus hope to remove certain excuses as for why a language couldn't do "XYZ" when the programmer has the ability at hand to reconfigure a good chunk of what the compiler as-is affords them to do in the first place. Lisp - through its macro system, sought to be the "one language to rule them all." Lisp implementations obviously vary wildly (which is indeed part of the problem with using Lisp), but Lisp's historical aspirations extend over [game engines](https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp), [social media platforms](https://github.com/reddit-archive/reddit1.0), [DBs](http://datomic.com), [text editor scripting](https://www.gnu.org/software/emacs/manual/html_node/eintr/) and [operating systems](https://en.wikipedia.org/wiki/Genera_\(operating_system\)) alike. Yet Lisp, even with its historical head start, failed tragically. The Lisp community continues to miss the point as to why it was outcompeted by everything else. Nim's hope, as I see it, is that it can fill the niche that Lisp sought after by observing its peers more closely and rapidly augmenting itself so that it doesn't lie in the dust. For instance, Nim was "just a GC'd language" for a long time, which is a no-go for many users right out of the box; but Nim was able to take realtime concerns more seriously, firstly with the development of the "controlled-pause" GC and later with the development of ARC. FWIW, trying to be "that language" is an increasingly difficult task. Lisp couldn't do it, and there were many Lisp programmers historically than there are Nim programmers now. Obviously there is more to a programming language that is not provided by the merit of how its individual features are designed. But, of course, the hope is that eventually that it will count for something - and that Nim would be known not only for its features, but as a language that one not only _could_ write for these different multivarious, non-intersecting applications, but as a language where you _would actually want to._
