История изменений

Ну пусть pi = 4

Отлично, то что я понимаю программу на си, например, как описание _будущего_ процесса работы процессора, памяти, системных и библиотечных вызовов это pi = 4.

более того - нам такие функции _нужны_

Ещё раз, «частичные грязные функции» это только _один из_ способов очертить всё множество полезных программ, «чистые тотальные функции» + «описания процессов» — другой возможный. Так что тут нет какой-то явной необходимости.

добавим жопу к любому типу и будем счастливы

Ничего хорошего из этого не получится — при интерпретации типов как логических утверждений получится противоречивый язык, так что придётся довольствоваться отсутствием такой интерпретации.

Будьте внимательнее.

Не вполне понял — для всех значений из ОДЗ получаются результаты за конечное число шагов (1), причём каждый шаг требует конечного времени (5). Вполне финитно по времени. Или речь об алгоритмах которые реализованы как программы (= частичные функции) которые работают как тотальные алгоритмы (= алгоритмы, собственно) на одних значениях и проявляют какое-то UB / GIGO на других? В таких случаях под ОДЗ алгоритма просто нужно понимать ровне те значения на которых он работает хорошо — эти UB и garbage нам не нужны.

мы наблюдаем, что был взрывной рост популярности.

http://www.tiobe.com/content/paperinfo/tpci/images/history_paradigm_type syst...

Или JavaScript vs. GWT, HaXe, Opa, Dart, TypeScript, Roy, Fay, etc.

Ты можешь объяснить, как такая ситуация могла произойти при появлении заведомо худшей альтернативы?

Я не считаю что она худшая — в определённых случаях наоборот, например, примитивные веб-морды без обилия логики — о каких «ошибках» в них может быть речь? Они работают чисто номинально пока выглядят работающими, сам deploy по сути процесс тестирования. Или какая-то простая интерпретируемая скриптота — что-то не так с типам? Ну и ладно, всё равно это одноразовый однострочник который запускается сразу как был написан и либо отрабатывает как надо, либо нет.

Но как только появляется какая-то более сложная логика — даже чисто экспериментально, — попробуем поменять в большом проекте на статически типизированном языке сам тип, либо тип чего-нибудь (поля, аргумента), сдвинуть что-то в иерархии наследования, изменить саму эту иерархию — по всему проекту тут же появятся десятки несовпадений, без статических проверок все они будут отложены «до лучших времён» (то есть наоборот — ничего хорошего в перманентной ловле этих несовпадений нет).

Ну пусть pi = 4

Отлично, то что я понимаю программу на си, например, как описание _будущего_ процесса работы процессора, памяти, системных и библиотечных вызовов это pi = 4.

более того - нам такие функции _нужны_

Ещё раз, «частичные грязные функции» это только _один из_ способов очертить всё множество полезных программ, «чистые тотальны функции» + «описания процессов» — другой возможный. Так что тут нет какой-то явной необходимости.

добавим жопу к любому типу и будем счастливы

Ничего хорошего из этого не получится — при интерпретации типов как логических утверждений получится противоречивый язык, так что придётся довольствоваться отсутствием такой интерпретации.

Будьте внимательнее.

Не вполне понял — для всех значений из ОДЗ получаются результаты за конечное число шагов (1), причём каждый шаг требует конечного времени (5). Вполне финитно по времени. Или речь об алгоритмах которые реализованы как программы (= частичные функции) которые работают как тотальные алгоритмы (= алгоритмы, собственно) на одних значениях и проявляют какое-то UB / GIGO на других? В таких случаях под ОДЗ алгоритма просто нужно понимать ровне те значения на которых он работает хорошо — эти UB и garbage нам не нужны.

мы наблюдаем, что был взрывной рост популярности.

http://www.tiobe.com/content/paperinfo/tpci/images/history_paradigm_type syst...

Или JavaScript vs. GWT, HaXe, Opa, Dart, TypeScript, Roy, Fay, etc.

Ты можешь объяснить, как такая ситуация могла произойти при появлении заведомо худшей альтернативы?

Я не считаю что она худшая — в определённых случаях наоборот, например, примитивные веб-морды без обилия логики — о каких «ошибках» в них может быть речь? Они работают чисто номинально пока выглядят работающими, сам deploy по сути процесс тестирования. Или какая-то простая интерпретируемая скриптота — что-то не так с типам? Ну и ладно, всё равно это одноразовый однострочник который запускается сразу как был написан и либо отрабатывает как надо, либо нет.

Но как только появляется какая-то более сложная логика — даже чисто экспериментально, — попробуем поменять в большом проекте на статически типизированном языке сам тип, либо тип чего-нибудь (поля, аргумента), сдвинуть что-то в иерархии наследования, изменить саму эту иерархию — по всему проекту тут же появятся десятки несовпадений, без статических проверок все они будут отложены «до лучших времён» (то есть наоборот — ничего хорошего в перманентной ловле этих несовпадений нет).