Хотя конечно я не в курсе как оно в той экзотике

Дык сами то типы никуда не деваются, просто определяются "на лету".

то пишите на асмах

а потом подвели теоретическую базу.

Всё прекрасно читаемо. Просто это не вписывается в Ваш шаблон.

Так конкурентов то особо не видно, по крайней мере у JS

да и на вотчину PHP покушается пожалуй что только неожиданно ставший модным Пайтон

Это не экзотика.

В ряде случаев никакие проверки не нужны.

Кто на неё только не покушается.

Проверок (в compile-time) много не бывает.

ну да, лисп же задумывался только для интерпретатора

Подход 50-ых: не машина для человека а человек для машины.

вместо решения непосредственно задачи

Да — не нужно бороться с изъянами системы типов

Такими темпами скоро, вместо решения непосредственно задачи, программисты будут большую часть времени заниматься описанием типов, метатипов, лишь бы удовлетворить компилятор.

Что за чушь?

Это в этих ваших «жуткотипизированных» языках такой подход: всё компилятору разжуй да в рот положи.

Такими темпами скоро, вместо решения непосредственно задачи, программисты будут большую часть времени заниматься описанием типов, метатипов, лишь бы удовлетворить компилятор.

Все функциональщики так говорят

Может это изъяны в голове, а не в системе типов?

Если в стандарте есть eval - то это интерпретируемый язык.

Myth #4: Lisp has no compiler

Since its earliest days, now 40 years ago, Lisp implementations have been variously interpreted or compiled, and often both. In fact, much important work in the theory of program compilation has been done using Lisp, and Lisp compilers have benefited enormously by this. No modern commercial Lisp is without a compiler. The fact that modern Lisps often come with an interpreter as well is simply a convenience for some implementations to encourage late-binding semantics and promote program flexibility, including interactive debugging.

The ANSI Common Lisp standard does not require the presence of a compiler provided that an interpreter achieves the defined semantics. It is intended that the marketplace will sort out this issue. The ability to omit a compiler allows certain price/performance points to be achieved, especially among subset and freeware implementations. However, serious commercial implementations invariably offer optimizing compilers as a standard part of their product. Ask to be sure, but don't let ever anyone tell you there's no such thing!

Вы пытаетесь описать идеальный язык

Написать, что ли свой js с блек джеком и статическими типами компилируемый в js?

поздно http://www.typescriptlang.org/

И тебя отсылаю читать TAPL.

А что там в двух словах?

Будучи статическими, системы типов обязательно консервативны (conservative): они способны однозначно доказать отсутствие определенных нежелательных видов поведения, но не могут доказать их наличие, и, следовательно, иногда вынуждены отвергать программы, которые на самом деле при выполнении ведут себя корректным образом. Например, программа

if <сложная проверка> then S else <ошибка типа>

будет отвергнута как неверно типизированная, даже если <сложная проверка> всегда выдает значение <<истина>>, поскольку статический анализ неспособен это заметить.

...

Аналогично, относительно незамысловатые виды анализа, воплощенные в большинстве систем типов, неспособны запретить совсем любое нежелательное поведение программ; они гарантируют только отсутствие в программах определенных видов ошибок. Например, большинство систем типов могут статически проверить, что в качестве аргументов элементарных арифметических операций всегда используются числа, что объект-получатель в вызове метода всегда имеет соответствующий метод, и т. п., но не могут обеспечить, чтобы делитель всегда не был равен нулю или чтобы индексы массива никогда не выходили за предельные значения.

...

Безопасность языка — это не то же самое, что статическая безопасность типов. Безопасности языка можно достичь при помощи системы типов, но можно добиться ее и с помощью проверок на стадии выполнения, которые отлавливают бессмысленные операции при попытке их исполнения, и останавливают программу или порождают исключение. К примеру, Scheme является безопасным языком, несмотря на отсутствие статической системы типов.

С другой стороны, в небезопасных языках часто имеются статические проверки типов, которые <<по возможности>> отлавливают хотя бы самые очевидные огрехи программистов. Впрочем, такие языки не могут считаться и безопасными с точки зрения типов, поскольку в общем случае они не могут гарантировать, что корректно типизированные программы ведут себя корректно — проверка типов в таком языке может предположить наличие ошибок во время выполнения (что, безусловно, лучше, чем ничего), но не доказать их отсутствие.

Если в стандарте есть eval - то это интерпретируемый язык.

А хаскелем заинтересовался когда увидел сорцы и подумал "Ух, ты, какой питон необычный!". (Сам Питон, я кста, до сих пор не знаю.)

Безопасность языка — это не то же самое, что статическая безопасность типов

большинству людей неудобно.

Что-то уровня: подушки безопастности не нужны, потому что все равно они не дают 100% гарантии( например от лобового столкновения с бетонной стеной на высокой скорости, лол ). Отличная логика, что сказать

У меня нет времени чтобы точить пилу, мне нужно пилить!

будет отвергнута как неверно типизированная, даже если <сложная проверка> всегда выдает значение <<истина>>, поскольку статический анализ неспособен это заметить.

неспособны запретить совсем любое нежелательное поведение программ

что в качестве аргументов элементарных арифметических операций всегда используются числа

или чтобы индексы массива никогда не выходили за предельные значения

но можно добиться ее и с помощью проверок на стадии выполнения

eval в CL -- метациклический вычислитель

Сравнивать Python и Haskell -- это надо обкуриться

А я так понимаю: если строка формируется в рантайме, то к проге должен быть прикручен интерпретатор.