Про ёжика в тумане, зазнайство, языки программирования и вериги

[vit_r]

Мне влом писать много, так что объяснения в следующий раз. Может быть. Сейчас просто двумя абзацами. (Не думаю, что кто-то поймёт, но это не важно.)

Строгая типизация - она для записи решённой задачи, не строгая (которую называют динамической, но лучше бы называть её контекстной) - она для поиска решения.

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

То есть, где-то между крайними точками экономия ресурсов становится ниже потерь.

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

Comments

[rdia.livejournal.com]

А когда у нас вывод типов?

[rdia.livejournal.com]

Кстати, изложено исключительно прозрачно в отличие от предыдущих виршей.

[kouzdra.livejournal.com]

Строгая типизация помимо повышения эффективности довольно сильно экономит время и позволяет реализовывать всякие полезные повышающие продуктивность тулы типа идеи или эклипса. Ну и полезна чисто как комментарии.

Так что imho засилье динамической типизации в скриптинге связано в основном с "простотой в реализации", да экспоненциальным ростом производительности железа. Щас, кстати, imho обратный процесс пошел - по крайней мере Go мне уже рекламировали как "питон, только статически типизированный и быстрый". Возможно потому, что процессоры перестали убыстряться, а всякое распараллеливание с типизацией проще.

Что любопытно - совершенно не популярны "смешанные" языки типа cecil - где типизация есть, но опциональна (стирание всей информации о типах семантику программы не меняет)

[(Anonymous)]

> Так что imho засилье динамической типизации в скриптинге связано в основном с "простотой в реализации"

Ещё полиморфизм. Скажем, я не понимаю, как можно реализовать тот же grep, когда результат работы программы - поток объектов - a' list.

Собственно, попробуйте сделать sed который будет заменять поле 25:int на поле 88:int в произвольном выводе любой команды. Но со статической типизацией.

Т.е. к вам на вход этого статически типизированного sed'а может придти

float * int * float list или string * float list или просто int list.

Соответственно, если вы сидите на статической типизации, вам придётся задавать структуру данных, передаваемых на вход grep или sed.

[nestoklon.livejournal.com]

Есть довольно популярный "язык" cython. Типизация есть, но она опциональна: хочешь чтобы работало быстрее -- объявляй типы.

[alexott.livejournal.com]

ну распараллеливание больше имеет отношение к чистоте функций - та же кложура хорошо параллелится

[alexott.livejournal.com]

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

[kouzdra.livejournal.com]

Скорее как в Erlange - в защите локальных от сайд-эффектов (сами-то сайд-эффекты в Erlang есть в полный рост). Но это все только для мультипроцессорности, а если всякие GPU-SSE надо использовать - там без типизации как раз никак.

Но опять же - типизация куда более простой способ поднятия перформанса, чем распараллеливание - потому с нее начать логичнее.

[kouzdra.livejournal.com]

Ну как - он должен просто быть не 'a list, а обладать какими-нибудь свойствами - вариантов куча - в ML модули или объекты, в Haskell предикаты. Опять же: если вы не знаете, какие свойства от элемента потока вам нужны - значит в дизайне что-то не так.

Конкретно для грепа нужно иметь сравнение на равенство как минимум.

Eq => ...

Тот же Haskell это сам скорее всего выведет.

[sorhed.livejournal.com]

Я тоже раньше так считал, но потом понял, что в нормальных языках с выводом типов возможно top-down программирование. Что даёт неограниченные возможности для поисков и экспериментов; в то время как в языках с динамической типизацией в процессе экспериментирования легко запутываешься, где что лежало.

[guamoka.livejournal.com]

Ad-hoc решение begets новые ad-hoc решения, а не структурирование и строгое типизирование. Поэтому логическим продолжением получается "нужно больше индусов". Увы.

[vit-r.livejournal.com]

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

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

[vit-r.livejournal.com]

Потому что это только заметка на память. Не сказано ни о причинах, ни о следствиях.

[vit-r.livejournal.com]

Строгая типизация помимо повышения эффективности довольно сильно экономит время

Это определяется только по ощущениям и теоретическим измышлениям. На полный цикл в реале эти параметры никто не измерял.

[vit-r.livejournal.com]

Строгая типизация для заданных (сверху) интерфейсов.

Чем дальше, тем их меньше. Плюс старые интерфейсы древних систем плохо расширяются и диктуют развитие нынешних.

[vit-r.livejournal.com]

если вы не знаете, какие свойства от элемента потока вам нужны - значит в дизайне что-то не так.

В большинстве случаев - не знаем. Потому что "эти идиоты" или не задукоментировали, или описали не правильно. Единственный способ - попытаться и получить ошибку.

[vit-r.livejournal.com]

довольно популярный это как-то не особо хорошо для использования в реальных коммерческих проектах.

[vit-r.livejournal.com]

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

Естественно, всё имеет свою цену. И везде нужна правильная организация процессов, чтобы бороться со специфическим хаосом.

top-down - это замечательно, но возможно только в чистом поле. В реале слишком много мелочей задано окружением и часть из них не известна. У меня сейчас всё больше задач второго типа и всё меньше первого.

[vit-r.livejournal.com]

Это только если мы просто ищем, а не чётко документируем, что нашли.

[guamoka.livejournal.com]

Имхо, решение прежде всего ищется через (понимание)потановку задачи-- что мы должны решить, граничные условийя, критерии/параметры оптимальности и прочая. Правильная постановка задачи-- это 50% её решения. Неправильная- это от -50% до минус бесконечности к решению. Если мы пытаемся понять задачу, решая её ad-hoc в надежде, что "кривая выведет", то это никогда не приведёт к грамотно структурированному законченному решению.

[vit-r.livejournal.com]

Опять же. Задач в чистом поле всё меньше. Для решения остальных надо копаться по локоть в дерьме.

это никогда не приведёт к грамотно структурированному законченному решению

Это только в том случае, если мы не проверяем адекватность структуры и не перестраиваем её в соответствии с изменениями. ("Перестраиваем" тут в смысле дизайна, а не латания)

[guamoka.livejournal.com]

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

Да, но для этого нужно иметь в голове чёткое представление о том, какую конечную цель мы преследуем. Я же о том, что ad-hoc решения отнюдь не способствуют формированию этой цели-- "оно же и так всё работает", "строгая типизация- это же не гибко", "зачем нам тратить время на какой-то там анализ и проектирование, когда мы за пять минут можем наложить любой новый патч?!" и т.д.

[vit-r.livejournal.com]

Цель нужно иметь не в голове, а записанной на бумаге. А с бардаком можно бороться только организационными мерами.

[sorhed.livejournal.com]

У меня почти никогда нет задач первого типа.

Top-down активно используется мной в реальной практике уже года четыре, наверное. Я уже и забыл, как писать по-другому.

[vit-r.livejournal.com]

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