почему в вебе распространены именно динамические языки? - Философия программирования

Здравствуйте, dotneter, Вы писали:

D>Очевидно что будет какой то дополнительный код, из контекста которого можно понять что к чему.
Контекстом я тебе еще больше все запутаю...

D>Да, но завтра Владу на голово упадет кирпич или например микрософт таки сделает мп у шарпа, и Немерле уйдет в небытье. Риски большие и доказать мифическую выгоду сложно.
Ну там далеко не только Влад все делает.
А что касается МП в C# не смешите мои тапочки.
МП без сравнения с образцом, алгебраических типов и квазицитирования настолько убого что аж жуть.
Думаешь МС пойдет на столь радикальные изменения в C#?
Да ни в жизнь.
Это язык для индусов.
А они это не поймут.

D>Вы поставте себя на место новичка. Каждую лишнюю конструкцию нужно держать в голове.
Давай определимся.
Либо новичек. Либо база данных уже есть.
А раз базы нет то эту строчку придется написать как ни крути.

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

D>На порог вхождение это влияет конечно положительно. Но у нас всетаки динамика вс статика.
Ну так покажи как с этим динамика справится.
Начни с того как она определит какой код нужно скомпилировать в С, какой в жабаскрипт, а какой и так и так.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, WolfHound, Вы писали:

N>>Пункт 1 — проблемы твоего восприятия, ты бы такое же рассказывал про Erlang.
WH>А что в эрланге у нас уже можно шарить изменяемые данные?

Да в общем-то давно можно.

init_globals() ->
  ets:new(globals, [named_table, set, public]).

set_foo(X) ->
  ets:insert(globals, {foo, X}).

get_foo() ->
  [{_, X}] = ets:lookup(globals, foo),
  X.

Главное здесь — слово public. Если protected, посторонний процесс сможет только читать, а private — не сможет даже читать.

Некоторые приложения, как стандартный application, принципиально опираются на этот механизм.

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

N>>У тебя явные проблемы с логикой, если ты один частный пример воспринимаешь как правило и ограничение.
WH>Если уж вводишь термины то делай их как следует.

Мы всё-таки пока не монографии пишем. Это не отмазка, но факт.

Термины будут отработаны по ходу.

N>>И что? Расскажи подробнее. Ах да, я с тобой спорю и осмеливаюсь с тобой не соглашаться...\
WH>Про естественность/искуственность ограничений начал ты

Верно. Потому что ты смешал совершенно разные классы ограничений, пришлось вмешаться.

N>>Я не смог понять этот абзац — даже после исправления описок он не приобретает смысла. Объясни другими словами, plz.
WH>Да все просто. Нет теста. И еще не скоро будет. Но я и так знаю что все впорядке.

Святым духом знаешь? Мне бы такую уверенность...

N>>Я не ищу заговоры, но тенденция использовать наиболее показательные примеры настолько очевидна, что предполагать обратное бессмысленно.
WH>Ну так я и показал первый попавшейся пример где статика помогла мне отвефакторить кучу кода.
WH>Могу еще комиты с подобным действом найти но смысл?

Смысл ровно тот же, с которым ты вообще сюда что-то пишешь: хочешь высказать свою точку зрения, кого-то убедить, от кого-то получить полезные комментарии. Но если ты будешь приводить примеры школьного уровня, это ни для кого не будет убедительным, скорее наоборот.

N>>Если да, тогда они мне просто неинтересны — у тебя другой мир, в котором, возможно, статическая типизация и способна сыграть настолько важную роль.
WH>А может я просто использую правильные языки и грамотно подхожу к тому чтобы уложить задачу в типы?

Ну покажи более интересный пример. Сейчас в твоих примерах и высказываниях просто не за что зацепиться — всё предельно плоское, школьное и суконное.

N>>Зато это полностью живой, настоящий пример, из которого ничего не упрощено. И да, он приведен для того, чтобы показать, насколько сложности ТЗ и спецификации преобладают над проблемами кодирования.
WH>Я не могу на этот твой пример ничего ответить просто по тому что я не понял половину слов.
WH>Сленг который ты использовал для меня ничего не значит.

А он тут и не сильно важен (хотя может быть освоен за 5 минут). Если ты просто нарисуешь по квадратику для каждой названной сущности и протянешь стрелки связей — уже увидишь сложность ситуации.

N>>Вот относительно свежий пример — исправление одного долго тянущегося бага свелось к перестановке одной команды (отцепить UA от контроллера) на строку выше, чтобы UA успел получить штатный сигнал дисконнекта. Никакие _типы_ этому не помогут, если в функционирование типа не вложишь полную FSM работы UA.
WH>Вот! Сам же знаешь ответ.

Нет, не знаю. Видимо, потому, что ситуация таки сложнее, чем это кажется со стороны.

WH>И заложить в тип FSM это очень просто. Для этого даже зависимые типы не нужны.
WH>Можно даже LL(1) закатать не особо напрягаясь.

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

WH>>>Так держать. Авось чтонибудь да докажешь.
N>>Ещё один переход на личности. Сливаешь?
WH>Где?
WH>Я просто говорю про ущербность подобной аргументации.

Она значительно менее ущербна, чем твоя позиция "что бы ты не делал — если делаешь на динамике, делаешь это неправильно".

N>>Так попытайся хотя бы навскидку предложить мне такое различие, которое бы помогло отловить все эти вещи на компиляции. А что ты думал — покажешь пару школьных примеров и этим кого-то убедишь?
WH>Что значит выделенное?
WH>И чем тот пример с изменением кучи кода школьный?

Тем, что показывает наиболее примитивное применение типа и компилятора.

WH>Если ты о том что нужно в протокол добавить поддержку расширения это ни разу не проблема.

Ну расскажи, как ты это будешь делать.

N>>подумай о некоторых других вопросах: например, ограничениях на вложение тегов по их типам,
WH>И в чем проблема?

Ну и как ты это будешь решать?

N>>или отображение твоего кода в чужом фрейме.
WH>Почему это должно меня волновать?

Потому, что понятие valid HTML может иметь достаточно тонкие зависимости от такого вложения.

N>>Что неполный — верю. Остальное — сомнительно. Например, пункт 5 — сознательные ограничения и если тебя они не устраивают, это только вопрос вкусовщины.
WH>Исли мне каждый раз явно придется писать привидения от потомка к базе то я прокляну все на свете.

По-моему, именно такие приведения там не нужны.

WH>А что касается перегрузки операторов то мне и этого мало.
WH>Я сейчас работаю над парсером для немерле2 там можно будет вообще как угодно над синтаксисом издеваться.
WH>Что позволит сделать произвольный ДСЛ.

Y A C C по новой, да?

N>>Tutorial просто не успели выправить. Так можно долго продолжать, истинно здесь только одно: ты настолько односторонне хочешь видеть мир, что отказываешься принимать запросы других.
WH>Ну да. Использование глобальных переменных это конечно правильно.
WH>А я один кому это категорически не нравится.

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

WH>Вот как это надо делать:
WH>

WH>[CommandLineParser]
WH>class Options
WH>{
WH>    [HelpMessage("don't print final newline")]
WH>    [Name("n")]
WH>    public OmitNewline : bool = false;
WH>}
WH>

WH>Может чуть больше слов за то понятно даже не зная как это все работает.

Мне в общем-то пофиг, как ты назовёшь аналог getopt в твоей среде. Вопрос в том, как ты будешь потом эти данные использовать. Глобальные данные класса — это хак ровно того же уровня, что и просто глобальные переменные.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить. Так вот — лечить динамику выводом типов не надо. Динамика — это не болезнь

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

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

Еще динамика — это чудовищное количество ошибок порождающее чудовищное количество тестов.

Так что плата очень даже зримая.

Что же касается позднего связывания и вытекающих из этого какой-то "просто чудовищной гибкости", то не надо ля-ля. Динамика дает два бенефита:
* Повсеместный динамический полиморфизм. Не факт что это преимущество. Для меня — человека делающего не мало ошибок — это скорее зло. Аналог этого свойства в статике виртуальные методы, интерфейсы и вариантные типы с паттерн-матчингом. Все перечисленное конечно требует несколько большего применения мозга для использования, но при наличии незначительных зачатков образования не так уж сложны в применении.
* Динамическое метапрограммирование. Я уже не говорю, что это фича реализуется далеко не в каждом скрипте. Но там где она реализуется кроме гибкости она создает не мало проблем. Это и дичайшие тормоза. И невозможность эффективной джит-компиляции или пре-компиляции такого кода. И трудно-уловимые ошибки. Ну, а замена этому делу в статике — это макросы. Мы просто переносим все это дело во время компиляции и делаем процесс детерминированным и проверяемым.

Здравствуйте, WolfHound, Вы писали:

WH>Автоматический рефакторинг для динамики сделать нельзя. Вообще никак. В лучшем случае получится что-то типа текстовой замены когда одно имя заменяется сразу во всей программе.

Дык есть языки вроде Эрланга которые спроектированы так, что контекстная замена позволяет спокойно производить большую часть рефакторинга, так как имена уникальны.

Здравствуйте, lomeo, Вы писали:

L>Тесты же.

Они выявляют наличие ошибки (если повезет), но не указывают на места ошибок. Если после рефакторинга появляются тысячи ошибок, то в динамически-типизированном языке проще откатиться и повторить рефакторинг с нуля.

Здравствуйте, netch80, Вы писали:

N>В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции?

Ошибка будет выявлена когда твой код будет использован в функциональном тесте. Он просто даст неверный результат.

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

Но даже при наличии юнит-тестов их будет нужно намного меньше. Это тоже практика.

Здравствуйте, Mamut, Вы писали:

M>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.

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

.

Другими словами, какова аудитория, таковы и ответы.

Спросили бы они у меня, и я бы ответил утвердительно. Хотя как они это сделали бы я понять не могу.

Здравствуйте, gandjustas, Вы писали:

G>Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
G>Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.

Тесты нужны и для статики. Но таки — да — объем тестов для динамики нужен существенно больший.
А вот с тем, что динамика дает существенный выигрышь в объеме кода вообще не соглашусь. Язык с паттерн-матчингом, вводом типов и макрами позволяет иметь приблизительно такой же объем кода что и у динамики. Иногда больше, а иногда и меньше (причем существенно).

Тут существенными фичами сокращающими объем кода становятся наличие метапрограммировния и паттерн-матчинга. Если в скрипте их нет (как например в Визуал Васике), то такой скрипт сосет по полной программе.

Здравствуйте, netch80, Вы писали:

N>С другой стороны, есть достаточно мало ситуаций (по моему опыту), которые требуют специфических тестов именно для динамики: если тест прошёл — то код работает правильно, и все операции с типами выполнены правильно.

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

Здравствуйте, netch80, Вы писали:

N>Конечно, если статически типизированному добавить рефлексию, оно заработает. Только вот не кажется ли благородному дону, что это лицемерие?

) Если ты пользуешься только теми возможностями, которые обычно ассоциируются со статическими языками, то у тебя даже простейший duck typing не будет работать.

Не кажется. Статика != старье и убогость. Статика не менее динамична за счет компонентного подхода и динамического полиморфизма (но контролируемого во время компиляции).

N>"Никаких проблем", если ты фактически принесёшь с собой компилятор (может, ещё и с JIT).

А в чем проблема то? Компилятор — это мелка длл-ка (от 100 КБ, до 3 МБ).

N> Во многих случаях это удовольствие сильно дороже, чем просто интерпретатор.

Это вопрос реализации и задач. Потом статику всегда можно интерпретировать, а вот обратное не верно.

WH>>И таки да. Вы все знаете о каком языке я говорю.

N>Неужели Algol 68?

Ах да, он на дотнете не работает...

Точно! В дырочку! Разбегаемся.

N>P.S[2]. А расскажите мне, каким образом в ASP.NET (я не перепутал название?) делается смена кода на ходу. Интересны именно механизмы и их ограничения.

За счет динамической компиляции и компонентного подхода. Я заработал пятерку?

Здравствуйте, WolfHound, Вы писали:

WH>И этот движок разбирает C# со скоростью более 2х мегабайт в секунду на моей машине.
WH>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser

На моей ~ 3.

Здравствуйте, VladD2, Вы писали:

N>>P.S[2]. А расскажите мне, каким образом в ASP.NET (я не перепутал название?) делается смена кода на ходу. Интересны именно механизмы и их ограничения.

VD>За счет динамической компиляции и компонентного подхода. Я заработал пятерку?

Не-а, потому что это ответ уровня "Как едет машина? — на энергии сгорания". Он годится только для того, чтобы отличить от других подходов на ресурсном уровне, но не для сколь-нибудь внятного описания и внутренних процессов, и процессов управления.

В частности, не раскрыты следующие вопросы:
1. Срок жизни скомпилированного кода.
2. Пределы возможностей параллельного существования версий одинаково названного кода.
3. Принципы обновления данных долгоживущего кода, включая сгенерированные функции.

Без этих данных ответ годится только на двойку, не выше.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, netch80, Вы писали:

N>>В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции?

VD>Ошибка будет выявлена когда твой код будет использован в функциональном тесте. Он просто даст неверный результат.

Спасибо за подтверждение, что никто и не пытается предложить ловить такие вещи на этапе компиляции.

VD>Но даже при наличии юнит-тестов их будет нужно намного меньше. Это тоже практика.

Верю. Хотя для моих задач практической разницы нет.

M>>Гарантирует не язык, а описаные ручками типы из стандартной библиотеки. То есть, они гаранируют до тех пор, пока нет ошибок в реализации этих типов.
WH>Ну так разумеется никто не будет в язык конкретные типы хардкодить.
WH>Но сами то типы проверяет компилятор.

Где и когда он их проверяет? При генерации SQL'я на основе данных, полученных от пользователя во время работы программы? При генерации HTML'я на основе данных, вытягиваемых из базы данных? Не смешите мои тапочки. Runtime Exception в случае неверных данных там гарантировано.

M>>Что так он «гарантирует»...
WH>Чтение у тебя как всегда изберательное. Осилил жа 2 пункта из 7.

Ко всему остальному там точно так же.

M>>Хм... Вот тут есть то же самое, практически, только для Erlang'а: http://code.google.com/p/erlyweb/source/browse/#svn/trunk/src/erlydb
WH>Послал так послал.
WH>Ты мне прикладной код покажи.

примеры по досаточно старой версии тут: http://yarivsblog.com/articles/2006/08/29/introducing-erlydb-the-erlang-twist-on-database-abstraction/

поновее тут: http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/

везде гарантируется валидность SQL-кода.

M>>Что тут дает статика? А ничего она не дает.
WH>Ну так если упорно игнорировать факты то...

Ну и расскажи мне, что она там делает в http://www.impredicative.com/ur/demo/sql.ur.html в случае, если в row.T.A невалидный XML. Только не надо мне рассказывать, что это известно на момент компиляции.

M>>Наверное или не скомпилируется? В указаном примере виден только вручную написаный xml, в который еще и вставляются какие-то данные из базы данных, которые на этапе выполнения программы могут быть вообще чем угодно, даже невалидным xml-ем.
WH>То что ты не видешь проверок валидности кода не значит что их нет.
WH>То что ты не видешь код для того чтобы заэскепить все строки не значит что его нет.
WH>В том то и кайф. Оно все само работает.

Ну и расскажи мне, что как оно само работает в случае, если в row.T.A невалидный XML. Только не надо мне рассказывать, что это известно на момент компиляции.

Здравствуйте, VladD2, Вы писали:

VD>Динамика еще обладает чудовищной тормознутостью, а в тех случаях когда ее удается джитнуть она чудесным образом становится похода на статику с выводом типов.

Тормознута в основном не динамика, тормознуты интерпретаторы по вполне очевидным причинам. Я тебе приводил разницу между V8 и JScript по производительности. При этом ECMAScript весьма беспредельный язык, в котором характеристика "динамичный" относится далеко не только к типизации.

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

VD>Еще динамика — это чудовищное количество ошибок порождающее чудовищное количество тестов.

Много ли ты писал на языках с динамической типизацией? Это "детский страх", не более того. Заметь сейчас многие крупные компании активно используют динамические языки — тот же Гугл и Питон. Их может не устраивать производительность, но вот динамичность почему-то устраивает всех. В противном случае, зачем бы он был нужен. От того, что на RSDN-е теоретизируют о "чудовищном количестве ошибок" и "чудовищном количестве тестов" эти языки не станут менее удобными.

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

VD>Так что плата очень даже зримая.

Бесспорно. Точно так же, как и за статику.

VD>Что же касается позднего связывания и вытекающих из этого какой-то "просто чудовищной гибкости", то не надо ля-ля. Динамика дает два бенефита:
VD>* Повсеместный динамический полиморфизм. Не факт что это преимущество. Для меня — человека делающего не мало ошибок — это скорее зло. Аналог этого свойства в статике виртуальные методы, интерфейсы и вариантные типы с паттерн-матчингом. Все перечисленное конечно требует несколько большего применения мозга для использования, но при наличии незначительных зачатков образования не так уж сложны в применении.

Вообще-то все несколько интереснее, чем ты тут пытаешь представить. Простая, так сказать, наивная статика засовывает программиста в жесткие тиски прямой как известная кишка системы типов — ни вправо, ни влево, ни даже развернуться не получается. Зато все достаточно просто, понятно, и все под контролем у компилятора. *Естественно*, что такое положение дел не устраивает никакого.
И тут начинается — притягиваем параметрический полиморфизм, экзистенциальные типы, row type полиморфизм и прочая и прочая. В итоге языки концептуально дико усложняются, компиляторы усложняются с соответствующими последствиями, изучать все это добро становится непросто, еще немного и впору будет диссертации по этим языкам писать.
А это, к чему приходим-то в итоге? Посмотри вот на полиморфные варианты в том же ОКамл — это ж та же динамика, вид сбоку, со всеми своими недостатками.

И возникает вопрос — а за что тут рвать-то всех на британский флаг? Сложившая ситуация явно показывает, что у этой вашей статики где-то имеется весьма серьезный концептуальный баг.

VD>* Динамическое метапрограммирование. Я уже не говорю, что это фича реализуется далеко не в каждом скрипте. Но там где она реализуется кроме гибкости она создает не мало проблем. Это и дичайшие тормоза. И невозможность эффективной джит-компиляции или пре-компиляции такого кода. И трудно-уловимые ошибки. Ну, а замена этому делу в статике — это макросы. Мы просто переносим все это дело во время компиляции и делаем процесс детерминированным и проверяемым.

А каким образом Гугл умудряется Джитить ECMAScript?

Здравствуйте, FR, Вы писали:

ВВ>>С библиотеками все понятно, но тут человек утверждает, что у него print "Hello, world!" будет законченным веб-приложением на питоне "без всяких фреймворков".
FR>Ну в общем так и есть питон из коробки дает возможность очень легко делать простенькие веб приложения.

Из коробки "с батарейками"? Ну в самом деле, что значит "из коробки"?
Без библиотек и фреймворков ни Питон, ни какой-нибудь Си-шарп веб-приложения писать не позволяют. А сделать в дотнете специальный "модуль", благодаря которому Console.WriteLine("Hello, world!") предвратится в веб-приложение тоже проблем не составляет.

Здравствуйте, FR, Вы писали:

ВВ>>По поводу Perl не знаю, но то, что Ruby и Python ниже порого вхождения, чем, скажем, у C#... Эта мысль мне кажется несколько сомнительной. Ну начнем хотя бы с того, что там вообще-то тоже надо знать, что такое "класс".
FR>В питоне необязательно, помню поддерживал довольно объемный код чистейшая процедурщина в стиле старого паскаля.

Ну вот мне интересно. Сейчас вот вполне серьезно обсуждается возможность сделать С# более "scripty". Т.е. появится возможность писать код без всякого объявления классов (как уже можно, кстати, в Немерле). Если эту возможность добавят, то порог вхождения сразу снизится что ли?

А с процедурным стилем и так все вроде отлично обстоит.

M>>Нет, ты мне не показал, как ее решить быстро. Ты решил, что ты — единственный, который знает такие умные термины, как ДКА, НДКА и т.п.
WH>Ты похоже их не знаешь.

О да, все тупые, один Wolfhound д'артаньян.

M>>Подходи. Мы уперлись в то, что нам даром не нужна сферовакуумная скорость какого-то там языка. Потому что скорость генерации данных и так высока — доли секунды. Все упирается в запись этих данных. Но нет.
WH>Тут ты вполне однозначно говоришь что тебе нужен быстрый поиск.
WH>Re[2]: Поможите. Одна комната, много детей :)
WH>Я тебе сказал как сделать предельно быстрый поиск.

К сожалению, он не учитывает тонны мелких нюансов.

WH>Но ты похоже уперся в то что искать должна БД.
WH>Но все что вы на пару с Синклером придумали это линейный поиск.
WH>Что и не удивительно. Ибо БД на подобную работу не затачивалась.

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

M>>Ах. Да, действительно. Вах. некий эксперимаентальный язык, который действительно, в случае системы типов, более строгой, чем в Хаскелле, позволяет это сделать.
WH>Те ты признал что статика таки это может.
WH>Уже хорошо.

Не может она. Ты не знаешь, что у тебя за данные будут на этапе компиляции.

M>>Только строгая типизация != статическая типизация.
M>>Итак. Что ты хотел сказать-то?
WH>Ну да. Я могу сделать эти проверки в динамике.
WH>Но нахрена мне такое счастье если вместо ошибок компиляции все эти проверки будут делаться рантаймом.
WH>Что мне это даст?
WH>Где профит?

Оно так или иначе будет делаться рантаймом. Ты не знаешь, что у тебя будет в row.T.A когда программа будет работать.

M>>Веб сам по себе — это сплошная слабоструктурированная информация. Из недавнего. http://www.janrain.com/ позволяет унифицировать логин на сайте через всякие твиттеры, фейсбуки и т.п. В возвращаемых значениях из 16 полей они могут гарантировать наличие аж 2-х.
WH>Гы.
WH>Там есть имена и типы всех данных.
WH>А то что данные могут отсутствовать так на то у нас option есть...

Я тебе пример с JanRain приводил. Заманаешься на все option'ы ставить.

M>>Если не нужен, мы его не пишем. Делов-то ЖчяЖ
WH>В том то и дело что в динамике оно всегда нужно.

Не всегда.

WH>>>С тормозами, без помощи компилятора и IDE...
M>>Опять начинаются какие-то сферовакуумные кони.
M>>Ты можешь написать генератор кода для получения данных на макросах на Немерле.
M>>Ты можешь написать генератор кода для получения данных на макросах на Лиспе.
WH>Но ты всеравно не получишь ни автокомплита ни проверок компилятора.

Которые, судя даже по рекламируемому тобой Ur'у все равно тебя не спасут.

M>>Не включаю. Вообще не понимаю, что ты имеешь под декларативной проверкой структуры.
WH>Описал структуру и оно само все проверилось.

Код в студию или не было.

M>>Скачал IDEA для Java. В пяти попытках рефакторинга она мне предложила такой же ломающий рефакторинг. И это — на статистически типизированом языке, в котором это должно быть раз плюнуть, не?
WH>Сколько пользовался ReSharper'ом ни разу такого небыло.

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

WH>>>И это коммерческая IDE которую люди пишут полный рабочий день.
M>>И не парятся. Потому что
WH>Почему?

Сорри, отвлекли, пока отвечал. Потом учто пробелмы типизации — это наименьшее из проблем, с которой сталкиваешься.

M>>Ты или эта — одинаковые стандарты используй или вообще никакие. Для Немерле, значит, рефакторинг не нужен, а для любого сравниваемого с ним языка — ВНЕЗАПНО нужен?
WH>Рефакторинга нет ибо автокомплит более приоритетен, а ресурсов мало. По этому автокомплит сделали, а до рефакторинга просто руки не дошли. Но вся нужная информация у нас уже есть.
WH>Вот собственно все что я хотел сказать.

Так не очень надо или нед ресурсов? Ты уже определись, да?

WH>Но PyCharm даже автокомплит и навигацию не умеет.
WH>И я об этом уже писал:
WH>

WH>>>За то автокомплит, навигация и подсветка ошибок работают как часы.
WH>>>И это при том что ее делают в свободное от работы время.

WH>>>Так что IDE для динамики больше не вспоминай. Это блокноты с раскраской синтаксиса.

WH>Но ты включил избирательное чтение.
WH>То что тебе не нравится игнорируешь.

Это взаимное.

M>>У меня ошибки сводятся к алгоритмическим. Может, потому что часть мозга, которая у тебя занята поисками нужных типов для задачи, выделяется для собственно решения задачи?
WH>Нет. Я просто пишу код так что алгоритмические ошибки почти всегда сводятся к ошибкам типизации.

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

M>>Есть у меня сайтец один. На HYH/ Два раза были проблемы с производительностью. Первый раз — с Апачем, замена на nginx помогла. Второй раз — с MySQL, тюнинг MySQL'я помог. Ни разу проблема с производительностью не упиралась в HYH/
WH>HYH? Что это?
WH>Может PHP?

PHP. PuntoSwitcher шаоит.

WH>Ну от того что с твоей карликовой нагрузкой у тебя с ним нет проблем это не значит что у других нет.

именно об этом я и говорю
СФЕРОВАКУУМНАЯ. СКОРОСТЬ. В. ОТРЫВЕ. ОТ. ЗАДАЧИ. НИКОГО. НЕ. ИНТЕРЕСУЕТ.

Сколько раз это еще сказать?

M>>Хотя ты там все равно ни хрена не увидишь.
WH>Что сразу слив засчитываем?

Твой? Безусловно.

M>>А умные люди увидят, что:
WH>Что сравниваются куча не понятных реализаций.
WH>Бенчмарки без исходников фуфло полное.
WH>Всегда.

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

СФЕРОВАКУУМНАЯ. СКОРОСТЬ. В. ОТРЫВЕ. ОТ. ЗАДАЧИ. НИКОГО. НЕ. ИНТЕРЕСУЕТ.

M>>СКОРАСТЬ!!!!!!одинодинодинодинодин
M>>!!!!!!одинодинодинодинодинодин).
WH>Тебя заклинило?

Заклинило именно тебя.

M>>Я их не отрицаю. Я тебе тупо твержу одну вещь: никого не интересует сферовакуумная скорость
WH>У тебя похоже все сферовакуумное.
WH>И скорость. И надежность.

Нет. Для тупых повторяю в нцатый раз: никого не интересует сферовакуумная скорость.

M>>>>Профит у людей, которые не думают о языках в терминах сферовакуумности того или иного языка.
WH>>>В воображении.
M>>исключительно в твоем. исключительно в твоем.
WH>Это разве я тут твержу о профите динамики?
WH>Я наоборот говорю что его нет.

Нет, именно ты твердишь о сферовакуумных понятиях. Сказочник.

	От:	WolfHound
	Дата:	18.10.10 20:34
	Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	18.10.10 22:10
Оценка:

От:	VladD2	www.nemerle.org
Дата:	18.10.10 23:06
Оценка:

От:	VladD2	www.nemerle.org
Дата:	18.10.10 23:19
Оценка:

От:	VladD2	www.nemerle.org
Дата:	18.10.10 23:20
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	19.10.10 06:55
Оценка:

	От:	Воронков Василий
	Дата:	19.10.10 07:04
	Оценка:	+1