N>>С другой стороны, есть достаточно мало ситуаций (по моему опыту), которые требуют специфических тестов именно для динамики: если тест прошёл — то код работает правильно, и все операции с типами выполнены правильно.
VD>Тут такое дело... Если код прошел тесты, то мы можем гарантировать, что он будет работать в таких же условиях. В статике не так трудно проверить граничные условия параметров и тем самым покрыть большую часть случаев использования. В динамике же любая функция полиморфна, что означает, что написать тесты покрывающие все возможные граничные случаи невозможно. Так что использование кода в "непривычных для него" условиях неминуемо приведет к появления рантайм-ошибок которые не отловят тесты.
Со строгой типизацией можно отловить и это. При программировании в Erlang-овском стиле тем более.
M>>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.
VD>Им надо было прийти к продавцам на рынок и спросить куда надо засунуть Элнанг. Думаю им тоже подходящее местечко подсказали бы .
VD>Другими словами, какова аудитория, таковы и ответы.
VD>Спросили бы они у меня, и я бы ответил утвердительно. Хотя как они это сделали бы я понять не могу.
Вывод. В отрыве от задач говорить о каких-либо преимуществах чего-либо над чем-либо как минимум не стоит.
Здравствуйте, netch80, Вы писали:
N>В частности, не раскрыты следующие вопросы: N>1. Срок жизни скомпилированного кода. N>2. Пределы возможностей параллельного существования версий одинаково названного кода. N>3. Принципы обновления данных долгоживущего кода, включая сгенерированные функции.
При замене кода ASP.NET перегружает домен приложения. Осюда — ответы на твои вопросы тривиальны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, netch80, Вы писали:
N>Я не видел, чтобы люди думали, например, "uint32", а не "целое число"
Я тоже не видел, бо томограф с собой не таскаю.
N>Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации.
Не начинает. Но заканчивает. В итоге пока что любая программа обязана быть четкой и на 100% формальной спецификацией. Хоть в динамике, хоть в статике.
N> Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают.
Ничего подобного. Ограничения применяют всегда, если хотят чтобы это имело практический смысл не только в стране эльфов. Фантазии без сильных ограничений в технических вещах не нужны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, netch80, Вы писали:
N>>В частности, не раскрыты следующие вопросы: N>>1. Срок жизни скомпилированного кода. N>>2. Пределы возможностей параллельного существования версий одинаково названного кода. N>>3. Принципы обновления данных долгоживущего кода, включая сгенерированные функции.
AVK>При замене кода ASP.NET перегружает домен приложения. Осюда — ответы на твои вопросы тривиальны.
В .NET 4 научились выгружать динамически генерируемые сборки
Re[21]: почему в вебе распространены именно динамические язы
M>>Вывод. В отрыве от задач говорить о каких-либо преимуществах чего-либо над чем-либо как минимум не стоит.
VD>Ну, почему прозиводительноть вычислений у эранга и других скриптов явно ниже.
1. Вычисления вычислению рознь.
2. Сферовакуумная скрость и сферовакуумная производительность никого не интересуют.
Здравствуйте, Mamut, Вы писали:
M>>>Гарантирует не язык, а описаные ручками типы из стандартной библиотеки. То есть, они гаранируют до тех пор, пока нет ошибок в реализации этих типов. WH>>Ну так разумеется никто не будет в язык конкретные типы хардкодить. WH>>Но сами то типы проверяет компилятор.
M>Где и когда он их проверяет? При генерации SQL'я на основе данных, полученных от пользователя во время работы программы? При генерации HTML'я на основе данных, вытягиваемых из базы данных? Не смешите мои тапочки. Runtime Exception в случае неверных данных там гарантировано.
Я начинаю сомневатся что я вообще с программистом разговариваю.
Типы в статически типизированном языке проверяет компилятор на этапе компиляции.
Твой к.о.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: почему в вебе распространены именно динамические язы
Здравствуйте, Mamut, Вы писали:
M>Ну и расскажи мне, что как оно само работает в случае, если в row.T.A невалидный XML. Только не надо мне рассказывать, что это известно на момент компиляции.
Она его ескепит.
Твой к.о.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>>>Гарантирует не язык, а описаные ручками типы из стандартной библиотеки. То есть, они гаранируют до тех пор, пока нет ошибок в реализации этих типов. WH>>>Ну так разумеется никто не будет в язык конкретные типы хардкодить. WH>>>Но сами то типы проверяет компилятор.
M>>Где и когда он их проверяет? При генерации SQL'я на основе данных, полученных от пользователя во время работы программы? При генерации HTML'я на основе данных, вытягиваемых из базы данных? Не смешите мои тапочки. Runtime Exception в случае неверных данных там гарантировано. WH>Я начинаю сомневатся что я вообще с программистом разговариваю.
WH>Типы в статически типизированном языке проверяет компилятор на этапе компиляции. WH>Твой к.о.
Еще раз. Что тебе дадут эти типы в процессе работы приложения?
Объясняю на пальцах, раз до тебя не доходит:
fun list () =
rows <- queryX (SELECT * FROM t)
(fn row => <xml><tr>
<td>{[row.T.A]}</td> <td>{[row.T.B]}</td> <td>{[row.T.C]}</td> <td>{[row.T.D]}</td>
<td><form><submit action={delete row.T.A} value="Delete"/></form></td>
</tr></xml>);
Запустили программу на следующих данных:
A B C D
-- -- -- --
/> <j <x = "a" <a=a=a===>
Чем тебе помогло то, что компилятор уверен, что вернется правильный XML? Ничем. Потому что — сюрприз! сюрприз! — данные ВНЕЗАПНО появляются не на этапе компиляции, а на этапе работы программы.
Более того, валидность возвращаемых данных гарантируется всего лишь человеком, который реализовал этот тип. Точно так же, как и в любом динамическом языке.
M>>Ну и расскажи мне, что как оно само работает в случае, если в row.T.A невалидный XML. Только не надо мне рассказывать, что это известно на момент компиляции. WH>Она его ескепит WH>Твой к.о.
Ничем не отличается от динамики. Твой генералиссимус о.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, netch80, Вы писали:
N>>В частности, не раскрыты следующие вопросы: N>>1. Срок жизни скомпилированного кода. N>>2. Пределы возможностей параллельного существования версий одинаково названного кода. N>>3. Принципы обновления данных долгоживущего кода, включая сгенерированные функции.
AVK>При замене кода ASP.NET перегружает домен приложения. Осюда — ответы на твои вопросы тривиальны.
"Последняя страница книги оказалась написана по-китайски" (tm). Что такое домен приложения? Догадка навскидку — это весь код в пределах какой-то логической группировки ("приложение"). Так?
The God is real, unless declared integer.
Re[29]: почему в вебе распространены именно динамические язы
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, netch80, Вы писали:
N>>>В частности, не раскрыты следующие вопросы: N>>>1. Срок жизни скомпилированного кода. N>>>2. Пределы возможностей параллельного существования версий одинаково названного кода. N>>>3. Принципы обновления данных долгоживущего кода, включая сгенерированные функции.
AVK>>При замене кода ASP.NET перегружает домен приложения. Осюда — ответы на твои вопросы тривиальны.
N>"Последняя страница книги оказалась написана по-китайски" (tm). Что такое домен приложения? Догадка навскидку — это весь код в пределах какой-то логической группировки ("приложение"). Так?
Нет.
С уважением, Анатолий Попов.
ICQ: 995-908
Re[38]: почему в вебе распространены именно динамические язы
Здравствуйте, netch80, Вы писали:
N>Да в общем-то давно можно.
жуть N>Главное здесь — слово public. Если protected, посторонний процесс сможет только читать, а private — не сможет даже читать. N>Некоторые приложения, как стандартный application, принципиально опираются на этот механизм.
Но тут по крайне мере можно эту таблице залочить.
В go же данные никак и ничем не контролируются.
Те несколько потоков могут корежить один и тотже объект без какой либо синхронизации.
А это уже ужос ужос.
N>Мы всё-таки пока не монографии пишем. Это не отмазка, но факт. Термины будут отработаны по ходу.
Просто из за косах терминов которые никто толком не понимает случается тупой флуд ибо испорченый телефон.
N>Верно. Потому что ты смешал совершенно разные классы ограничений, пришлось вмешаться.
Я всетки не вижу разници.
У нас есть задача.
У нас есть решатель.
Решение будет ограничено ограничениями и задачи и решателя.
И так как решатель у нас один и других не предвидится и не вижу смысла разделять эти понятия.
N>>>Я не смог понять этот абзац — даже после исправления описок он не приобретает смысла. Объясни другими словами, plz. WH>>Да все просто. Нет теста. И еще не скоро будет. Но я и так знаю что все впорядке. N>Святым духом знаешь? Мне бы такую уверенность...
Существующая функциональность не сломалась. На это тест есть.
N>Смысл ровно тот же, с которым ты вообще сюда что-то пишешь: хочешь высказать свою точку зрения, кого-то убедить, от кого-то получить полезные комментарии. Но если ты будешь приводить примеры школьного уровня, это ни для кого не будет убедительным, скорее наоборот.
Почему ты считаешь этот пример школьным?
Реальный комит. В реальном проекте. Причем я бы сказал весьма не простом проекте.
N>Ну покажи более интересный пример. Сейчас в твоих примерах и высказываниях просто не за что зацепиться — всё предельно плоское, школьное и суконное.
Вышел я из возроста когда мне было в кайф наворотить веселые мегашаблоны на С++.
Теперь у меня весь код скучный. Даже тот который решает очень сложные задачи.
N>А он тут и не сильно важен (хотя может быть освоен за 5 минут). Если ты просто нарисуешь по квадратику для каждой названной сущности и протянешь стрелки связей — уже увидишь сложность ситуации.
Не увижу.
У меня мозг работает по другому.
N>Нет, не знаю. Видимо, потому, что ситуация таки сложнее, чем это кажется со стороны.
Но ты же его написал.
Вводим FSM на уровень системы типов. И все.
N>Во-первых, я говорил о необходимом условии, а не достаточном. Во-вторых, тут получается хитрая корреляция состояний разных автоматов... впрочем, что я это рассказываю, если ты всё равно смотреть не будешь?
Чтобы мне это все осознать мне нужно понять предметную область.
N>Она значительно менее ущербна, чем твоя позиция "что бы ты не делал — если делаешь на динамике, делаешь это неправильно".
Я тут уже который раз задаю вопрос: Где профит?
И ответа по существу нет.
Ни одного.
Повторю еще раз свои аргументы против динамики:
1)Скорость исполнения всегда ниже.
2)Компилятор не ловит ошибки. Совсем.
3)IDE фундаментально убогие.
А что у нас в плюсе?
Меньше кода?
По сравнению с С++, C# и Java? Да!
По сравнению с немерле? Нет!
Метапрограммирование? Так в немерле оно есть.
В чем профит?
Ну хоть что-то?
А если есть очевидные недостатки но не видно достоинств то зачем оно нужно?
Ответь хотябы ты.
На Мамута я уже не расчитываю.
N>Тем, что показывает наиболее примитивное применение типа и компилятора.
А оно всегда примитивное.
Но из кучи такого примитива строятся тучи контрактов за которыми невозможно следить без помощи роботов.
WH>>Если ты о том что нужно в протокол добавить поддержку расширения это ни разу не проблема. N>Ну расскажи, как ты это будешь делать.
Ты действительно хочешь чтобы я тебе тут чиста ради флема спроектировал расширяемый протокол?
Причем под что-то сферовакуумное?
Это слишком большой объем работы.
N>>>подумай о некоторых других вопросах: например, ограничениях на вложение тегов по их типам, WH>>И в чем проблема? N>Ну и как ты это будешь решать?
Что решать?
Пример проблемы пожилуста.
N>>>или отображение твоего кода в чужом фрейме. WH>>Почему это должно меня волновать? N>Потому, что понятие valid HTML может иметь достаточно тонкие зависимости от такого вложения.
Ты не понял. Почему меня должно волновать что кто-то засунет мой сайт в фрейм?
Это не мои проблемы.
Моя задача как разработчика сайта чтобы сайт в правильно работал в популярных браузерах. Не более того.
WH>>А что касается перегрузки операторов то мне и этого мало. WH>>Я сейчас работаю над парсером для немерле2 там можно будет вообще как угодно над синтаксисом издеваться. WH>>Что позволит сделать произвольный ДСЛ. N>Y A C C по новой, да?
А что уже позволяет сделать так:
SomeFunction() : ...
{
using XMLDsl;//Тут мы расширяем грамматику XML литералами
def xml = <asd>$someVar</asd>;
}//А тут эта грамматика отключается
Причем вместе с ДСЛ подключаются автокомплит, подсветка и навигация по коду.
Так что як нервно курит в углу.
Благодоря статическо типизации если someVar будет иметь тип XML ее значение будет вставлено без изменений иначе оно будет сконвертировано в строку и заэскеплено.
Имея в руках подобное колдунство я любую динамику по объему кода уделаю...
N>Мне в общем-то пофиг, как ты назовёшь аналог getopt в твоей среде. Вопрос в том, как ты будешь потом эти данные использовать. Глобальные данные класса — это хак ровно того же уровня, что и просто глобальные переменные.
Ты имеешь в виду статические переменные класса?
Если да то полностью согласен.
Я уже давно пришол к выводу что их нужно запретить.
Пользы нет, а вред существенный.
Кстати с запретом глобальных переменных нужно запрещать всякие CreateFile ибо они по сути маскируют глобальные переменные.
Проблемы из-за них вполне конкретные.
Например я не могу взять и запустить какой попало код. Ибо злобный хацкер сможет сотворить что попало.
Чтобы с этим бороться мелкософт наворотил мега костыль по имени code access security который больше мешает чем помогает.
А всего то надо было при старте программы передавать в процесс сервис имен через который можно все что можно процессу.
В таком случае можно будет выполнить что попало. Все что нужно сделать для того чтобы это что попало не сделало гадость это не давать ему сервис имен.
Получаем http://en.wikipedia.org/wiki/Capability-based_security
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
ВВ>Из коробки "с батарейками"? Ну в самом деле, что значит "из коробки"?
Это значит используя только стандартную библиотеку, которая обязательно идет с дистрибутивом питона.
ВВ>Без библиотек и фреймворков ни Питон, ни какой-нибудь Си-шарп веб-приложения писать не позволяют. А сделать в дотнете специальный "модуль", благодаря которому Console.WriteLine("Hello, world!") предвратится в веб-приложение тоже проблем не составляет.
Наверно, но насколько я понимаю в отличии от питона в коробку не положили.
Re[9]: почему в вебе распространены именно динамические язык
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну вот мне интересно. Сейчас вот вполне серьезно обсуждается возможность сделать С# более "scripty". Т.е. появится возможность писать код без всякого объявления классов (как уже можно, кстати, в Немерле). Если эту возможность добавят, то порог вхождения сразу снизится что ли?
По моему да.
ВВ>А с процедурным стилем и так все вроде отлично обстоит.
N>>Она значительно менее ущербна, чем твоя позиция "что бы ты не делал — если делаешь на динамике, делаешь это неправильно". WH>Я тут уже который раз задаю вопрос: Где профит? WH>И ответа по существу нет. WH>Ни одного. WH>Повторю еще раз свои аргументы против динамики: WH>1)Скорость исполнения всегда ниже. WH>2)Компилятор не ловит ошибки. Совсем. WH>3)IDE фундаментально убогие. WH>А что у нас в плюсе? WH>Меньше кода? WH>По сравнению с С++, C# и Java? Да! WH>По сравнению с немерле? Нет! WH>Метапрограммирование? Так в немерле оно есть. WH>В чем профит? WH>Ну хоть что-то?
ВНЕЗАПНО.
Было вся динамика против всей статики. Стало динамика против одного только Немерле.
А на немерле уже есть веб-сервер, который по производительности приближается или равен nginx'у? А то тут голимая динамика, которая всегда медленне статики (тм) ВНЕЗАПНО равна ему по производительности. Бида-бида. Как с таким парадоксом жить.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я тоже раньше к динамике относился весьма негативно. По ровно тем же причинам, которые ты сейчас высказываешь. А потом действительно попробовал использовать. И оказалось, что разница между теорией и практикой весьма существенная.
Я ту же эволюцию проделал, тем кто не прошел бесполезно объяснять, любимый парадокс Влада в действии.
.
Термины будут отработаны по ходу.
