Здравствуйте, Alex EXO, Вы писали:
AE>Поскольку в Erlang нет глобальных переменных, то при перемиеновании переменной за пределами функции ничего искать не надо. При переименовании функции, тоже все обычно, как везде (даже проще, поскольку функции не экспортированные явно, локальны в пределах модуля).
Вспоминаем про программно изолированные процессы, сообщения которыми они обмениваются и про то, что в Эрлэнге есть разные хэш-таблицы хранящие состояние процесса. Как с ними?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вспоминаем про программно изолированные процессы, сообщения которыми они обмениваются и про то, что в Эрлэнге есть разные хэш-таблицы хранящие состояние процесса. Как с ними?
С ними согласен — есть сложности.
Но не в смысле "рефакторинга переименования" (о котором был вопрос). С этим видом рефакторинга как раз сложности минимальные.
Вот если бы было спрошено про рефакторинг набора параметров в сообщении — то да...
Здравствуйте, VladD2, Вы писали:
VD>Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина.
VladD2, в последних постах тут ты что-то упираешь на метапрограммирование — можно поинтересоваться, что ты имеешь в виду под этим в Эрланге? Там, конечно, есть parse transforms, но их даж рекомендуют по возможности избегать.
Здравствуйте, VladD2, Вы писали:
VD>Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина.
У Явы есть одна проблема свер прочих: слишком много халявного кода, с не очень (мягко скажем) хоршей архитектурой.
На ранних этапах проектов — это соблазн, на поздних — попадалово...
Здравствуйте, VladD2, Вы писали:
VD>Хочу поменять структуру записи которая используется для передачи сообщений в другие процессы.
VD>Что делать?
Тут есть 2 варианта — если используется именно структура, т.е. record в рамках Эрланга, то это сделать имхо вполне возможно. Считай чуток стат. типизации имеется
Но вот только эти recordы не есть повсеместно используемая вещь, т.к. для их использования необходима перекомпиляция всех модулей, а это даёт зависимости и т.п. Поэтому чаще сообщения посылают обычными туплами/списками. А тут рефакторинг — дело, по меньшей мере, тяжкое
Здравствуйте, VladD2, Вы писали:
VD>Откровенно говоря доверия к Эриксону в этом вопросе у меня нет совсем. Им нужна база для пиара своей разработки. Такие оценки должны делаться независимыми экспертами. И даже при этом такие данные будут весьма спорными.
А собственно, почему ? Они же Ерлангом не торговали. Покупателям же всякого ихнего железа без разницы, что внутри — Ерланг или Бабсик. Лишь бы обеспечивалось соответствие заявленным параметрам
VD>Э... не надо таких приемов. Я не в филосовском смысле. Просто если мы переименовываем переменную в СТЯ (статически типизированном языке), то мы в состоянии вычислить все вхождения этой переменной в программе и не будем страдать от наличия одноименных переменных. Та же фигня с другими видами рефакторинга. Так что "знаем о коде все" не значит, что наш компилятор/IDE стали вдруг обладать интелектом. Это значит, что мы знаем, что означет какой идентификатор и можем использовать это знание для автоматизации нашей работы.
Отсутствие глобальных переменных уже не раз спасало отцов русской демократии
VD>Да? Странно. Заметь я всего лишь слегонца постебался над товарищем. И сдела я это именно потому что "сразу видно, сгоряча сказал, и наверняка сам это понял". И сказал это просто для того, чтобы он в дальнейших своих речах был чуть аккуратнее и не заговаривался. Можно сказать, помочь ему хотил. Но нашлись несогласные
.
Ну как, "сгоряча" ? Заинтересованные люди спросили меня о ходе проекта, я изложил то, что думаю о причинах успеха. Ежели кому-то это показалось не очень осмысленным или вовсе бредовым — что ж, jedem das seine.
VD>Да какой шашкой. Просто смешно ведь когда люди серьезно обсуждают исходно обсурдную фразу брошенную на радостях, в пылу писательского порыва.
"Исходно абсурдную" — звучит весомо
VD>Ну, дык выяснили же. Человек путает понятие надежности и скорости разработки.
Так-таки и путаю ? Надежность в моем понимании ( для краткости обьединим это понятие с устойчивостью ) — это вероятность отработки системой своего функционала в полной мере на протяжении некоего, достаточно большого, периода. Надежность 99.9999 % означает, что время дисфункции за месяц не может превышать 2.5 секунд.
Или есть какие, более другие трактовки этого термина ?
VD>* Эрлэнг позволяет ускорить разработку.
Это верно VD>* Ускорение разработки может дать дполнительное время на тестирование.
Тоже верно, но не только ЭТО оно может дать. Вследствие брожения, происходящего в репах разработчиков, длительные процессы имеют тенденцию еще более замедляться и как бы сопровождаться дополнительными глюками. По моему глубочайшему убеждению, сокращение времени разработки само по себе способствует повышению надежности, даже без привлечения дополнительных факторов. VD>* Дополнительное тестирование приводит к повышению качества.
И это верно, но не как основной фактор. VD>* Эрлэнг — динамический язык.
Именно VD>Выоды: Значит — динамика единственный способ добиться надежности софта.
Как я уже писал в этой теме, и писал не раз — способ не единственный, но самый дешевый. И вывод этот сделан был не на основании упомянутых выше 4-х факторов, а как экспертная оценка. Надеюсь, разница заметна ?
VD>То что при этом ускорение не обязательно ведет к повышению качества, и то, что Эрлэнг обладает обладает кроме динамики рядом других достоинств (метапрограммирование и сопоставление с образцом) которые приводят к ускорению разрабтки он даже не подумал.
Опять-таки, подумал или нет — это вопрос, на который могу ответить только я. Верно ? Паттерн матчинг есть сейчас во многих языках, потому я исключил его их рассмотрения. А метапрограммирование в Ерланге — и вовсе совершенно отдельная песня.
VD> В прочем как он вообще умудрился сделать связь с динамикой для меня вообще остаяется загадкой. В этих рассуждениях нет ни одной зацепки для этого.
Как я уже НЕ РАЗ писал, это вывод из личного опыта. Причем не только моего.
Здравствуйте, VladD2, Вы писали:
G>>Более того, во многих других конторах, занимающихся аналогичными задачами, как-то стихийно наметился уклон в сторону языков с динамической типизацией.
VD>Если бы ты сказал "Эрлэнг нам помог разрабатывать приложения быстрее" никто ничего не сказал бы. А так...
В данном случае я говорю не только про Ерланг. Тикль, несмотря на свою ограниченность, тоже очень часто выигрывает у статических языков. А это уже тенденция, не правда ли ?
Кстати ! Почему все время "Эрлэнг" ? Это фамилия скандинавского мужика, и читается она как "Ерланг".
Здравствуйте, VladD2, Вы писали:
VD>Разница на порядок это такой же гон высасаный из пальца как гон о том, что только динамика обеспечивает надежность. У эрлэнга есть ряд факторов позволяющих сократить объем кода. Основны из них отсуствие декларации типов. Это не даст более 30% выигрыша. И паттерн-матчинг. Это может дать несколько раз. Но никак не порядок.
Ну что означает "гон" ? Есть данные по нашему проекту, есть данные по аналогичному проекту на Жабе, который делался достаточно квалифицированными разработчиками. И есть соотношение чисел
VD>Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина.
Метапрограммирование ? Тут какая-то ошибка. У нас динамически порождаются функции и интерфейсы к данным, но это все в рамках лямбда-исчисления
VD>К сожалению, просто опыт мало интересен. Интересны обоснования. Вот их и не видно.
Я попытался изложить некоторые догадки об обоснованиях...
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется рациональным аргументом является то что язык A может все что B плюс неких z который позволяет упрощать ряд решений. Скажем если у нас есть Ява с паттерн-матчиногом, то просто Ява отдыхает. Если у нас есть Ява с миксинами, то просто ява отдыхает. В итоге сомнений в том, что Ява < Скала лично у меня нет.
То-есть сравнение корректно ТОЛЬКО для языков, один из которых является прямым наследником другого ?
Re[12]: Бизнес-логика на Erlangе
От:
Аноним
Дата:
23.05.07 14:22
Оценка:
VD>Мне кажется рациональным аргументом является то что язык A может все что B плюс неких z
БАшня из слоновой кости
Сравниваем C и D.
Есть в D malloc/free ? есть в нём #define ? есть в нём "массив == указатель" ?
Получается, что D не больше C.
И так будет почти в любой паре языков, если специально их не подбирать.
Здравствуйте, gandalfgrey, Вы писали:
G>В данном случае я говорю не только про Ерланг. Тикль, несмотря на свою ограниченность, тоже очень часто выигрывает у статических языков. А это уже тенденция, не правда ли ?
Не правда — ли.
Вообще ты меня извини за некоторый переход на личности, но твое неумение грамотно делать логические выводы просто напрягает.
Даже если отбросить ничем не подтвержденное заявление о том что Тикель выигрывать у чего-то абстрактного на статически типизированного, то как его выигрышь можно проецировать на весь класс динамических языков. Скажем QuickBasic динамический язык, но с чего он может дать какие-то приемущества?
G>Кстати ! Почему все время "Эрлэнг" ? Это фамилия скандинавского мужика, и читается она как "Ерланг".
По правилам английской грамматики .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alex EXO, Вы писали:
AE>У Явы есть одна проблема свер прочих: слишком много халявного кода, с не очень (мягко скажем) хоршей архитектурой. AE>На ранних этапах проектов — это соблазн, на поздних — попадалово...
Да, уж. Проблема выбора — ужасная вещь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Ну что означает "гон" ? Есть данные по нашему проекту, есть данные по аналогичному проекту на Жабе, который делался достаточно квалифицированными разработчиками.
А я вот сегодня пример на Васике написал. По моим данным там 10 строк кода и ни одной ошибки. Можно на основании этого делать какие-то выводы?
Помйми, есть научные принцыпы получения достоверных сведений. Нельзя сравнивать что-то просто ради того, что у ниго схожие фукнции и потом проецировать результат этого сравнения на языки прогаммирования. Возможно в иных условиях оказалось бы, что программа на Эрлэнге распула и равалилась, а Явская блестела и сверкала. Причем просто потому, что изменился состав команд.
Сравнивать можно только есть достоверные и объективные данные. Такими данными могут быть специльные сравнения в которых гарантируется, что качество проектирования одинаково высокое. Или статистика собранная по большому количеству проектов (где высчитывается среднее качество).
Я уверен, что объм эрлэнг-кода для многих задач будет существенно меньеш явского, но меня гложут большие сомения, что тут можно говорить о порядках.
VD>>Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина. G>Метапрограммирование ? Тут какая-то ошибка. У нас динамически порождаются функции и интерфейсы к данным, но это все в рамках лямбда-исчисления
Любое программное порождение кода — это метапрограммировиние. А лямбд-исчисления вообще невозможны на современных компьютерах. Тут скорее о машине Тюринга нужно говорить. И вообще это обастракный треп. Вы берете некую модель и получаете код для обработки нужных вам данных. Это ни что иное как метапрограммирование. Конечно Ява не лучшее средства для метапрогараммирования, но тем не мнее им можно заниматься и в нем. Только по сложнее.
Так вот сравнивая решения одно из которых создано с массовым использванием МП, а другое решено методов закидывания буденовками ты можешь сделать только один вывод — задача проще решается средствами МП. Но на Яву это уже обощать нельзя.
VD>>К сожалению, просто опыт мало интересен. Интересны обоснования. Вот их и не видно. G>Я попытался изложить некоторые догадки об обоснованиях...
И даже в этом делашь море логических ошибок нивилирующих твои слва.
ЗЫ
На самом деле я очень тебя понимаю. Ты чувствуешь, что некое средство Х дает тебе приемущество перед тем, что ты использовал ранее. И ты хочешь этим поделиться. Это хорошо. Но ты не можешь найти реальную суть приемущества и ты начинашь обощать догадки. Результат получается фиговый. Тут лучше все же потратить время на анализ и попытаться докопаться до сути.
Проблема только в том, что мне кажется, что эта суть будет сильно расходиться с твоими теперешними выводами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А>БАшня из слоновой кости
Тебе виднее.
А>Сравниваем C и D. А>Есть в D malloc/free ?
Есть аналоги.
А> есть в нём #define ?
Специально изведен. Вместо него даны адекватные, но не имеющие тех проблем замены.
А> есть в нём "массив == указатель" ?
В С/С++ фактически нет массива. Он там ублюдочный. В ди же есть и массивы и указатели и возможность получить указатель на массив.
А>Получается, что D не больше C.
Получаем безответсвенный гон с твоей стороны в данном случае.
Но мысль ясна. Не все языки можно разложить в некую линию где один однозначно лучше, а другой однозначно хуже. Вот только D и C точно не из этого списка.
А>И так будет почти в любой паре языков, если специально их не подбирать.
Скажем так. Любой язык программирования — это дизайнерское решение. Всегда нужно идти на компромисы выбирая между решениями. И конечно сравнение языков есть сложный и не однозначный процесс. Вот толко это никак не влияет на возможность сравнивать языки. Те же С/С++ на столько отстали от жизни, и являются настолько ублюдочными по сравнению с более молодыми, что проигрывают всегда если сравнение объективно.
Собственно единственное на чем пока держится С/С++ — это на том, что для него существуют компиляторы с офигительными оптимизаторами и то, что рантаймы этих языков минимальны. Со временем эти приемущества будут нивелироваться. Они уже и сейчас не актуальны для большинства задач.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>То-есть сравнение корректно ТОЛЬКО для языков, один из которых является прямым наследником другого ?
Скажем так. Для таких языков оно 100%-доказуемо корректно. В прочем, и тут можно найти свои "но". Скажем в C# есть unsafe-код, а в Немерле нет. Для кого-то это недостаток.
Вторая проблема сравнения — это выбор предпочтений. Скажем кто-то может настолько верить в идею, что любая анотация типов — это вселенское зло, что кроме динамики ни во что не верить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
VD>>Откровенно говоря доверия к Эриксону в этом вопросе у меня нет совсем. Им нужна база для пиара своей разработки. Такие оценки должны делаться независимыми экспертами. И даже при этом такие данные будут весьма спорными. G>А собственно, почему ? Они же Ерлангом не торговали. Покупателям же всякого ихнего железа без разницы, что внутри — Ерланг или Бабсик. Лишь бы обеспечивалось соответствие заявленным параметрам
Они Эрлэнг продвигали. Они априори предвзяты. Как бы ты отнесся к тому, что тебя разрешили судить не судье, а милиции или налоговой? А аргументировали бы так же как ты "они же не продают ничго...".
G>Отсутствие глобальных переменных уже не раз спасало отцов русской демократии
В Эрлэнге их аналоги все таки есть. Хотя наверно их меньше чем скажем в Питоне. Вот только это заслуга выбора авторами Эрлэнга функционального подхода, а не динамики. Иначе бы твои рассуждения можно было бы распространить и на Питон с Васиком.
G>Ну как, "сгоряча" ? Заинтересованные люди спросили меня о ходе проекта, я изложил то, что думаю о причинах успеха. Ежели кому-то это показалось не очень осмысленным или вовсе бредовым — что ж, jedem das seine.
То есть ты считашь утверждение "только на динамике можно добиться надежности" верным?
G>"Исходно абсурдную" — звучит весомо
Ну, что поделаешь. Если бы ты умел применять логический вывод к своим утверждениям, то понял бы, что так оно и есть.
VD>>Ну, дык выяснили же. Человек путает понятие надежности и скорости разработки. G>Так-таки и путаю ? Надежность в моем понимании ( для краткости обьединим это понятие с устойчивостью ) — это вероятность отработки системой своего функционала в полной мере на протяжении некоего, достаточно большого, периода. Надежность 99.9999 % означает, что время дисфункции за месяц не может превышать 2.5 секунд. G>Или есть какие, более другие трактовки этого термина ?
Конеретные цыфры ты сюда зря влючил. Без них определение вполне приемлемо. Но причем тут это?
В прочем, согласен. Ты не термины путашь. Ты законы логики нарушаешь. Ты из заключения о том, что из А следует Б, делаешь заключение что из Б следует В. Причем никакой видимой связи межд Б и В нет.
G>Тоже верно, но не только ЭТО оно может дать. Вследствие брожения, происходящего в репах разработчиков, длительные процессы имеют тенденцию еще более замедляться и как бы сопровождаться дополнительными глюками. По моему глубочайшему убеждению, сокращение времени разработки само по себе способствует повышению надежности, даже без привлечения дополнительных факторов.
А вот люди которые делали первые ракеты делали все крайне долго проверя все по сто раз и усложняя тем самым решение. Но в итоге на их разработках мы и сейчас в космос летаем.
VD>>* Дополнительное тестирование приводит к повышению качества. G>И это верно, но не как основной фактор.
Какой к черту факто?
VD>>* Эрлэнг — динамический язык. G>Именно
Что именно? Где связь? Где логика?
VD>>Выоды: Значит — динамика единственный способ добиться надежности софта. G>Как я уже писал в этой теме, и писал не раз — способ не единственный, но самый дешевый. И вывод этот сделан был не на основании упомянутых выше 4-х факторов, а как экспертная оценка. Надеюсь, разница заметна ?
Заметно, то что с логикой у тебя просто кранты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А я вот сегодня пример на Васике написал. По моим данным там 10 строк кода и ни одной ошибки. Можно на основании этого делать какие-то выводы?
Вот если бы этот пример обеспечивал функциональность информационной системы, то можно было. А так — нет. Мы же сравниваем характеристики проектов на разных языках, но с близким функционалом.
VD>Помйми, есть научные принцыпы получения достоверных сведений. Нельзя сравнивать что-то просто ради того, что у ниго схожие фукнции и потом проецировать результат этого сравнения на языки прогаммирования. Возможно в иных условиях оказалось бы, что программа на Эрлэнге распула и равалилась, а Явская блестела и сверкала. Причем просто потому, что изменился состав команд.
Возможно-возможно, но тем не менее это единственная РЕАЛЬНО существующая методика сравнения различных платформ.
VD>Сравнивать можно только есть достоверные и объективные данные. Такими данными могут быть специльные сравнения в которых гарантируется, что качество проектирования одинаково высокое. Или статистика собранная по большому количеству проектов (где высчитывается среднее качество).
Ну, это уже какой-то идеализм. Даже солипизм, я бы сказал ! Ведь требования совершенно нереальные
VD>Я уверен, что объм эрлэнг-кода для многих задач будет существенно меньеш явского, но меня гложут большие сомения, что тут можно говорить о порядках.
Я говорил о конкретном случае. На других задачах действительно может быть несколько иначе
VD>Любое программное порождение кода — это метапрограммировиние. А лямбд-исчисления вообще невозможны на современных компьютерах. Тут скорее о машине Тюринга нужно говорить. И вообще это обастракный треп. Вы берете некую модель и получаете код для обработки нужных вам данных. Это ни что иное как метапрограммирование. Конечно Ява не лучшее средства для метапрогараммирования, но тем не мнее им можно заниматься и в нем. Только по сложнее.
Это не является метапрограммированием ! Иначе применение пары функциональных комбинаторов тоже будет им являться
Здравствуйте, VladD2, Вы писали:
VD>Скажем так. Для таких языков оно 100%-доказуемо корректно. В прочем, и тут можно найти свои "но". Скажем в C# есть unsafe-код, а в Немерле нет. Для кого-то это недостаток.
Тогда о чем речь, ежели in vivo такие сравнения бессмысленны ?
VD>Вторая проблема сравнения — это выбор предпочтений. Скажем кто-то может настолько верить в идею, что любая анотация типов — это вселенское зло, что кроме динамики ни во что не верить.
Это не про меня. Ну, пишу же я маленькие модульки на С++ для расширения Тикля...Да и D понемногу начинаю использовать
Здравствуйте, VladD2, Вы писали:
VD>Вообще ты меня извини за некоторый переход на личности, но твое неумение грамотно делать логические выводы просто напрягает.
Mea culpa ! Confiteor ! 8))
VD>Даже если отбросить ничем не подтвержденное заявление о том что Тикель выигрывать у чего-то абстрактного на статически типизированного, то как его выигрышь можно проецировать на весь класс динамических языков. Скажем QuickBasic динамический язык, но с чего он может дать какие-то приемущества?
О ничем не подтвержденном якобы утверждении : какие подтверждения надобны, кроме примеров из РЕАЛЬНОЙ жизни ? Сражу скажу — теоретических доводов не будет.
Ну, КвикБабсик мы пропустим, полагаю
VD>По правилам английской грамматики .
Английская грамматика здесь неприменима, ибо известный математик Агнер Краруп Ерланг, так же как и создатели языка Ерланг, названного в его честь, говорили на шведском.
Человек путает понятие надежности и скорости разработки.
