Здравствуйте, gandalfgrey, Вы писали:
IT>> два 'за' в пользу статики: рефакторинг и возможность качественной поддержки IDE. G>... для рефакторинга Хаскеля
С Хаскелем как раз все понятно. Статическая типизация. Можно рефакторить не опасаясь, компилятор даст по рукам если что.
G>и Ерланга. G>Для NetBean есть весьма качественная поддержка Ерланга ( плагином ). Есть и для Эклипса, и для Емакса...
А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ? И когда вылезет ошибка если вдруг преименовали не так? конечно есть Dyalizer, но это как бы и не компилятор, и я не уверен, что IDE вовсю пользуют его возможности.
Здравствуйте, Mirrorer, Вы писали:
M>А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ?
"Элементарно Ватсон..."
Поскольку в Erlang нет глобальных переменных, то при перемиеновании переменной за пределами функции ничего искать не надо. При переименовании функции, тоже все обычно, как везде (даже проще, поскольку функции не экспортированные явно, локальны в пределах модуля).
Да и нет там особой необходимости в рефакторинге переименования, именно в силу локальности имен.
Здравствуйте, Mirrorer, Вы писали:
M>А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ? И когда вылезет ошибка если вдруг преименовали не так? конечно есть Dyalizer, но это как бы и не компилятор, и я не уверен, что IDE вовсю пользуют его возможности.
Вопрос — что же переименовать хочешь
В голове такие варианты:
1. имя функции
2. имя переменной
3. имя атома
4. имя процесса
первые 3 варианта элементарны, 2-й самый примитивный, т.к. переменные локальны, то даж смотреть больше никуда не надо
Если у нас есть исходники всех модулей системы, то 1 и 3 тоже решаются довольно несложно.
Правда, если есть "сторонние" модули (а такое возможно т.к. статически мы прочекать всё не можем, нет монолитной системы), то возникают некоторые проблемы.
Ну и 4-й пунт как раз вот "сторонними" вызовами чреват, т.к. мы не можем отследить "внешние" вызовы, которые приходят из сети, но тут думаю играет роль тот фактор, что адресация напрямую к процессу есть архитектурно неправильное решение.
AE>Поскольку в Erlang нет глобальных переменных, то при перемиеновании переменной за пределами функции ничего искать не надо. При переименовании функции, тоже все обычно, как везде (даже проще, поскольку функции не экспортированные явно, локальны в пределах модуля).
А вот тут как раз не всё так гладко как кажется
Имя функции может быть выражением, т.к. вычисляться в рантайме (хотя реальных примеров видел такого мало).
Пример:
Здравствуйте, Mirrorer, Вы писали:
M>А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ? И когда вылезет ошибка если вдруг преименовали не так? конечно есть Dyalizer, но это как бы и не компилятор, и я не уверен, что IDE вовсю пользуют его возможности.
А в чем проблема ? Если уж CTAGS находит то, что нужно — то переименовать можно без проблем. Не говоря уж о том, что средства получения и манипуляций AST есть в стандартной бибилиотеке Ерланга.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, Курилка, Вы писали:
К>>Имя функции может быть выражением, т.к. вычисляться в рантайме (хотя реальных примеров видел такого мало).
L>Думаю, и в статических языках в подобных ситуациях (напр, рефлекшн) при рефакторинге будут аналогичные проблемы.
Ясен пень, там получается, что на самом деле в рамках статики используется динамика (правда многословно будет )
Тут Mirrorer говорит, что в 2005-й студии есть галка для замены ссылок на методы в строках.
Естественно это лишь костыль, но всёж.
Здравствуйте, Alex EXO, Вы писали:
К>>Имя функции может быть выражением, AE>Согласен. Но это в любом случае уже несколько извращенный вариант (лучше уж саму функцию положить в переменную).
Не, вроде бы какие-то вменяемые варианты использования в рассылке пробегали, только уже не помню...
Думаю пример такого — использование функций из разных модулей (т.е. имя функции одно и то же, но в зависимости от фазы луны вызываем модуль1 или модуль2), хотя тоже сценарий несколько жутковатый
AE>В Java если все откастовать в Object, то рефакторинг тоже накроется. Так что абсолютной дуракоустойчивости не бывает.
Конечно, только есть языки более "чёткие" с этой точки зрения, скажем Haskell, где статическая типизация более скурпулёзна чтоли.
Здравствуйте, Mirrorer, Вы писали:
M>А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ? И когда вылезет ошибка если вдруг преименовали не так? конечно есть Dyalizer, но это как бы и не компилятор, и я не уверен, что IDE вовсю пользуют его возможности.
Не думаю, что переименование чего-нибудь является сложной проблемой для динамики.
Гораздо интереснее изменение прототипов функций или структур. В статике все эти вещи компилятор отлавливает.
Disclaimer: ситуации, когда что-нибудь передается как void* или приведенное к типу Object не интересны.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
E>>Дело не в Erlang-е как таковом. В 1.2Mloc Java можно было бы впихнуть компилятор, run-time и отладчик какого-нибудь доморощенного DSL, на котором данная задача решается вообще в несколько тысяч строк G>Оно таки-да ! Но тут проблема психологическая. Народ не готов был к этому
Ну вот мы и выяснили что дело не в том что динамика рулит, а втом что на жабе писали...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ну вот мы и выяснили что дело не в том что динамика рулит, а втом что на жабе писали...
Дык ить ! Может, потому жаба и некошерна, что сугубо статична ?
Люди, разрабатывавшие проект на жабе, тоже ведь не маниаки какие-то. Но чем же обьяснить такой разрыв в количестве строк ?
Как было все, связанное с программингом, искусством во времена Вирта и Хоара, так и сейчас осталось на уровне восприятия и подсознательных побуждений...Рационального обьяснения для многих парадоксов разработки просто не существует, да и не может существовать по причине полной иррациональности и субьективности этих парадоксов.
Здравствуйте, gandalfgrey, Вы писали:
G>Как было все, связанное с программингом, искусством во времена Вирта и Хоара, так и сейчас осталось на уровне восприятия и подсознательных побуждений...Рационального обьяснения для многих парадоксов разработки просто не существует, да и не может существовать по причине полной иррациональности и субьективности этих парадоксов.
Что не отменяет естественного желания поверить алгеброй гармонию, чем мы здесь все и пытаемся заниматься
Здравствуйте, gandalfgrey, Вы писали:
WH>>Ну вот мы и выяснили что дело не в том что динамика рулит, а втом что на жабе писали... G>Дык ить ! Может, потому жаба и некошерна, что сугубо статична ? G>Люди, разрабатывавшие проект на жабе, тоже ведь не маниаки какие-то. Но чем же обьяснить такой разрыв в количестве строк ?
По отношению к Java меня этот вопрос всегда интересовал. Почему Java и вокруг нее приводит вот к такому: Execution in the Kingdom of Nouns
Хотя есть один объективный фактор: спецификация исключений в методах. Из-за чего приходится в Java коде плодить массу catch-ей с перехватом исключений, не перечисленных в собственной спецификации, и преобразования их к чему-нибудь другому.
Опять же нет делегатов, замыканий или хотя бы указателей на функции. Поэтому любой callback должен реализовываться как интерфейс с его последующей имплементацией (хотя бы и в виде анонимного класса).
IDE теже самые, думаю, свою лепту вносят -- в них так быстро мегатонны кода клепаются, что сами авторы не успевают это осознавать.
G>Как было все, связанное с программингом, искусством во времена Вирта и Хоара, так и сейчас осталось на уровне восприятия и подсознательных побуждений...Рационального обьяснения для многих парадоксов разработки просто не существует, да и не может существовать по причине полной иррациональности и субьективности этих парадоксов.
Должны существовать. Просто нужно учитывать еще и психологию, как минимум.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Это так. Только ответ на вопрос — как это скажется на всем сроке разработки не так однозначен.
Согласен, не однозначен.
G>Чтобы ответить на него, надо знать, каком процент ошибок типизации к прочим ошибкам — раз, и среднее время исправления ошибки типизации против ошибок прочих классов — два.
Более того он может быть разным на разных задачах, у разных людей. А возможно при попытке его измерения сработает левый фактор который будет записан как основное действие.
G> Не собирая подробных метрик ответить на ти вопросы невозможно, это три. Но можно дать экспертные заключения.
Собирая тоже не просто. Тут можно только говорить об опыте. Что в общем можно назвать экспертным заключением.
G>К примеру, алгоритмические ошибки и ошибки управления ресурсами обходятся существенно дороже — они занимают примерно от 15 мин до двух часов, в среднем — около получаса на исправление.
Не соглашусь. Хотя тут важно разбить проблему.
1. Алгоритмические ошибки. Не факт, что они обходятся дороже или дешевле. Тут могут быть варианты. 99% алгоримический ошибок у меня отлавиливаются очень быстро. Но есть такие которые я ловлю днями. Или даже откладываю их поиск и справление на потом в виду сложности их обнаружения/исправления.
При этом помню ошибки на динамических языках (ЯваХрип в ASP (не .NET)) которые я искал очень долго. Было это, например, так... Все работало как часы. Потом что-то там поправил в другом месте и привет. Не пашет и все тебе. Точнее пашет, но не так как следовало бы. Искал ошибку долго. Только откатив изменения и накатывая их частями я нашел ошибку. Оказалось перекрытие перменной в виду очепятки. Все работало пока перменная не была по сути нужа, но как только появилась такая же переменная которая временами получала значения изменялась еще одна переменная и уже этот побочный эффект вылизал как-будто ошибка была в логике программы. По сути была ошибка второго порядка которые я до этого видел только в С++ при ошибках с указателями (т.е. затирание памяти и наложенка от этого). В типизированной прорамме я бы получил предупреждение компилятора о том, что а) я переопределяю переменную (в прочем это к динамике не отностися, но наблюдается во всех динамических императивных языках), б) о том, что я использую одну и ту же переменную для хранения разных типов данных (одна была строка, а вторая что-то более сложное).
2. Управление ресурсами... На самом деле эта проблема относится к типобезопасности. Просто потери памяти не так страшны. Да и в GC-языках их можно допустить:
calss Global
{
public static List<object> AddGarbageHere = List<object>();
}
А вот ошибки с указателями, использование "мертвых" объектов и т.п. — это уже все следствие слабости системы типов.
Мне, чесно говоря кажется, что без GC или подсчета ссылок (короче, без автоматического управления памятью) вообще нельзя создать типобезопасный рантайм.
Так вот, С++ попросту не типобезопасный язык. А вот подавляющее большинство скриптовых языков как раз типобезопасны. Вот только типобезопастность проявляется исключительно в рантайме.
Так что я согласен, что "скрипты безопаснее С++", но не потому, что они "скрипты", а потому что С++ не типобезопасен (вообще). Если же мы возьмем к примеру Яву, то тут все уже будет по другому. Она как раз типобезопасна, причем в огромной мере эта типобезопасность проверяется еще до компиляции.
Далее вспоминаем о приемуществе раннего обнаружения ошибок...
...и сделаем простой вывод, что при прочих равных статика обеспечивает большую надежность. Другой вопрос насколько. Вот это уже зависит от взглядов, опыта и т.п.
G> Простыми тестами они не ловятся. Ошибки типизации ловятся простейшими тестами, и их исправление (обыкновенно такие ошибки — что-то вроде опечаток) обходится в минуты.
Я еже говорил, что "это зависит". Бывают разные ошибки. Бывают ошибки типов которые хрен поймаешь (С++ тому ярчайшее подтверждение). А быват и логические которые ловятся банальным пробеганием в отладчике.
G> По моему опыту так.
А по моему — иначе.
G> И замедление разработки от динамики в результате получается незначительное — в рамках погрешности измерения. Я его не замечаю. Однако, эти статистики очень индивидуальны.
Тут не учтены еще несколько факторов. Не маловажным является поддержка IDE. Я понимаю, что есть люди которые пишут по английски вслепую, помнят все библиотеки на изусть, и программу сначала продумывают на бумажке. Но таких все же не много, да и есть у меня подозрение, то они просто решают слишком примитивные задачи. Или решают задачи слишком медленно (никто же не сравнивал "быстродействие" разных программистов?).
Для работы боьшинства сервисов IDE нужна информация о типах. Причем она нужна еще до запуска программы. Динамика это обеспечить не может. Даже интелисенс будет очень ограниченым, а уж о хинтах, навигации, автоматическом рефаторинге можно забыть. И не надо мне преводить в качестве примера Смолток. Сколько бы не вопили его фанаты, но рефаткорирг там примитивнешйий (по функционалу почти сравнимый с поиском с заменой на базе регекспов).
G>Я бы сказал так — динамический язык со сборкой мусора будет безопаснее и продуктивнее, чем строготипизированный С++ с ручным управлением памятью.
Я бы тоже так сказал, но... см. выше.
G>Подтвердить или опровергнуть все это объективно может только сбор метрик с реальных проектов, как по статике, так и по динамике. У меня есть только данные по метрикам Эрикссона
Откровенно говоря доверия к Эриксону в этом вопросе у меня нет совсем. Им нужна база для пиара своей разработки. Такие оценки должны делаться независимыми экспертами. И даже при этом такие данные будут весьма спорными.
Точно установить истину можно было бы проведя большой объем эксперементов. Но это слишком дорого. Так что этим никто заниматься не убдет.
VD>>Влияет. Я могу пологаться на более высокоуровневые тесты и на меньший их обхем. G>Твои тесты должны обеспечить хотя бы то, что каждая строчка написанного тобой кода будет ими вызвана — независимо от типа типизации.
На самом деле этого недостаточно. Программа это не примитивная фукнция. В ней меняется состояние и один и тот же код может перестать работать при некоторых условиях.
G> Иначе это не тесты, а говно — у тебя ни разу не тестированный код в релиз попадет. Так вот, такие тесты выловят 99% ошибок типизации
К сожалению не выловят. Все по той же причине. Состояние меняется и с ним меняются условия. Чем динамичнее система тем меньше толку от тестов всего лишь "покрывающих код".
Есть задачи где тесты могут что-то гарантировать, есть в которых они бессильны. Многие интерактивные системы и просто системы со сложной логикой и большой вариативностью данных приводят к тому, что тесты могут только снизить число ошибок и гарантировать отсуствие их повторения (если это пакетные тесты проганяемые переодически).
Так вот компилятор с жесткой (или жестокой) логикой контроля все же нехило помогает в контроле за структурой кода. То что у любого объекта можно взывать любой метод (послать сообщение и т.п.) приводит к тому, что могут появляться наложенные ошибки. А вот именно они то и являются самыми опасными, так как мы должны уже думать в двумерном пространстве (точнее в Х-метром).
Просто, согласен, что в С++ такие ошибки получаеются чаще чем в динамике. И согласен, что в том же Эрлэнге таких ошибок оказвается меньше чем в обычных динамических языках, так как язык функциональный (меньше состояния, меньше побочных эффектов). Но давайте признаем правду. Приемущество Эрлэнга не в динамике, а в некоторых архитектурных решениях его авторов.
VD>>А скажем для рефакторинга мне вообще тесты не нужны будут. G>Агащаз. Доказывать функциональную эквивалентность нового и старого кода (что он после твоего рефакторинга делает то же самое, что и раньше) кто будет без тестов? Пушкин?
Мне не нужно доказывать если рефакторинг автоматический. Как раз статическая типизация позволяет алгоритмизировать рефакторинг.
VD>>Более того его можно будет автоматизировать). Ведь мы знаем все о коде еще до его запускат. Значит мы может менять его соблядая при этом инваринт. G>Если бы мы действительно знали о коде все, до того, как мы его запустим, то тогда конечно да. Только знание типов гораздо ближе к "почти ничего".
Э... не надо таких приемов. Я не в филосовском смысле. Просто если мы переименовываем переменную в СТЯ (статически типизированном языке), то мы в состоянии вычислить все вхождения этой переменной в программе и не будем страдать от наличия одноименных переменных. Та же фигня с другими видами рефакторинга. Так что "знаем о коде все" не значит, что наш компилятор/IDE стали вдруг обладать интелектом. Это значит, что мы знаем, что означет какой идентификатор и можем использовать это знание для автоматизации нашей работы.
G>Знаешь Влад, меня в последнее время больше заботит не то, что человек сказал, а то — зачем он это сказал.
Красивая фараз. Чья?
G> Человек сказал, что ему кажется, что динамика помогает ему писать надежный код. Ему так сильно это кажется, что он не представляет, как это можно вообще без динамики. Ну, сразу видно, сгоряча сказал, и наверняка сам это понял.
Ага.
G>И все заметили, и все поняли, что характерно.
Да? Странно. Заметь я всего лишь слегонца постебался над товарищем. И сдела я это именно потому что "сразу видно, сгоряча сказал, и наверняка сам это понял". И сказал это просто для того, чтобы он в дальнейших своих речах был чуть аккуратнее и не заговаривался. Можно сказать, помочь ему хотил. Но нашлись несогласные
Да какой шашкой. Просто смешно ведь когда люди серьезно обсуждают исходно обсурдную фразу брошенную на радостях, в пылу писательского порыва.
G>Мне интересно, с чем же он таким столкнулся в разработке, что пришел к настолько убежденной и нестандартной позиции.
Ну, дык выяснили же. Человек путает понятие надежности и скорости разработки. При этом он делает набор ложных умозаключений:
* Эрлэнг позволяет ускорить разработку.
* Ускорение разработки может дать дполнительное время на тестирование.
* Дополнительное тестирование приводит к повышению качества.
* Эрлэнг — динамический язык.
Выоды: Значит — динамика единственный способ добиться надежности софта.
То что при этом ускорение не обязательно ведет к повышению качества, и то, что Эрлэнг обладает обладает кроме динамики рядом других достоинств (метапрограммирование и сопоставление с образцом) которые приводят к ускорению разрабтки он даже не подумал. В прочем как он вообще умудрился сделать связь с динамикой для меня вообще остаяется загадкой. В этих рассуждениях нет ни одной зацепки для этого.
С тем же успехом я могу сделать вывод, что скажем Nemerle (обладающий тем же паттерн-матчингом и поддерживающий метапрограммирование) так же ускоряет разработку (и это скорее всего верный вывод), а дальше сделать тагую же логическую ошибку и заявить, что так как Немерле статически типизированный, то стало быть статика является необходимым средством для построения надежных систем.
Бред?... Несомненно. Но логика (точнее ее отсуствие) та же.
G> Это наверняка что-то интересное — и это не так просто объяснить. Тут бы человеку наводящими вопросами помочь, чтобы объяснил.
Дык я уже под столом лежал. Мне надо было о жувоте заботиться, а не вопросы задавать .
G>А ты вместо этого цепляешься к словам, и пытаешься всем доказать и так очевидные для всех вещи. Зачем?
Как показывает практика это не "очевидные для всех вещи".
G> К тебе точно так же можно докопаться, и доказать, что с формальной точки зрения ты несешь чушь. Да к любому можно так докопаться — рано или поздно скажет что-нибудь неоднозначное. Думаешь, ты мало таких вещей говоришь?
Я думаю, что все в этой жизни ошибаются. И я, и ты и автор этих строк. И думаю, что на моее сообщение
Здравствуйте, gandalfgrey, Вы писали:
G>В нее вбухано более 20 человеколет. Это число достаточно велико, чтобы обьяснить, почему я считаю С++ малопригодным для построения чего-то более-менее сложного — это просто ОЧЕНЬ дорого обходится.
С этим спорят только оконченные фанаты С++.
G>К Жабе примерялись, но существенного выигрыша тут все же нет.
А вот это уже откровенно не верный вывод.
G>Вот использование Ерланга и Тикля себя оправдало. Сейчас даже при желании от них невозможно отказаться — уж очень эффективно решаются проблемы с их помошью. G>Более того, во многих других конторах, занимающихся аналогичными задачами, как-то стихийно наметился уклон в сторону языков с динамической типизацией.
Если бы ты сказал "Эрлэнг нам помог разрабатывать приложения быстрее" никто ничего не сказал бы. А так...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Соотношение количества строк для проектов на Жаве и Ерланге, реализующих примерно одинаковую функциональность. Я эти числа приводил в исходном сообщении. Разница более чем на порядок ( в пользу Ерланга )
Разница на порядок это такой же гон высасаный из пальца как гон о том, что только динамика обеспечивает надежность. У эрлэнга есть ряд факторов позволяющих сократить объем кода. Основны из них отсуствие декларации типов. Это не даст более 30% выигрыша. И паттерн-матчинг. Это может дать несколько раз. Но никак не порядок.
Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина.
G>Вряд ли я могу представить исчерпывающее теоретическое обоснование такового мнения... Все, что я излагал в прочих сообщениях, является моим личным експириенсом и ИМХО.
К сожалению, просто опыт мало интересен. Интересны обоснования. Вот их и не видно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Вообще крайне сомневаюсь, что возможны РАЦИОНАЛЬНЫЕ аргументы по поводу превосходства одного языка над другим. Разве что для очень близких языков...Возможно, таких как С++ и D ? И даже в этом случае не уверен в корректности этого сравнения
Мне кажется рациональным аргументом является то что язык A может все что B плюс неких z который позволяет упрощать ряд решений. Скажем если у нас есть Ява с паттерн-матчиногом, то просто Ява отдыхает. Если у нас есть Ява с миксинами, то просто ява отдыхает. В итоге сомнений в том, что Ява < Скала лично у меня нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И когда вылезет ошибка если вдруг преименовали не так? конечно есть Dyalizer, но это как бы и не компилятор, и я не уверен, что IDE вовсю пользуют его возможности.
