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

[vit_r]

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

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

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

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

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

Comments

[rdia.livejournal.com]

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

[vit-r.livejournal.com]

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

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

[rdia.livejournal.com]

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

[vit-r.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.

[kouzdra.livejournal.com]

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

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

Eq => ...

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

[vit-r.livejournal.com]

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

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

[metaclass.livejournal.com]

grep a' list?
см. LINQ

Статически типизированный sed - структурные типы. "Запись у которой есть поле c именем X и типом int".

[nestoklon.livejournal.com]

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

[vit-r.livejournal.com]

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

[alexott.livejournal.com]

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

[kouzdra.livejournal.com]

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

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

[vit-r.livejournal.com]

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

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

[kouzdra.livejournal.com]

Есть объективный, хотя не абсолютный, критерий - длина кода. С типизацией сейчас код получается короче. Хотя конечно дело не только в типизации - тот же паттерн-матчинг в Перл вставить раз плюнуьть, а польза будет.

Но Ларри упирался и отбивался даже от замыканий.

[alexott.livejournal.com]

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

[sorhed.livejournal.com]

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

[vit-r.livejournal.com]

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

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

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

[sorhed.livejournal.com]

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

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

[guamoka.livejournal.com]

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

[vit-r.livejournal.com]

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

[asox.livejournal.com]

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

А разве миожно писать программу - не найдя заранее решения?

[http://users.livejournal.com/_windwalker_/]

а разве можно продать покупателю программный комплекс, которого не существует ?

[vit-r.livejournal.com]

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

[perepertoz.livejournal.com]

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