Re[20]: почему в вебе распространены именно динамические язы
От: Воронков Василий Россия  
Дата: 14.10.10 14:48
Оценка: +3
Здравствуйте, VladD2, Вы писали:

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


ВВ>>Я думаю, что ускорение при компиляции все же будет значительное. Ну положим, интерпретируемый динамический язык на 2 порядка медленнее компилируемого. Компилируемый динамический будет на порядок медленнее. Да и то ИМХО в худшем случае.


VD>Это высасывание цифр из пальца. В среднем разница между хорошим скриптом и средненьким компилятором — 10-30 раз, т.е. ~ 1 порядок. Компиляция дает (опять же в среднем) двух-, трех-кратное ускорение. Но на отдельных (обычно вырожденных) задачах можно достичь и более серьезного ускорения.


Надо бы проверить и правда. Я вот помню, что JScript (к-й вместе с MSIE8 идет) сортирует массив из 1000 элементов пузырьком где-то за 0.35 сек. Руби, кстати, делает это где-то за 1.2 сек. Это на моем домашнем i5 750. При этом уже V8 выполняет эту задачу практически без времени. Могу просто уточнить цифры. V8 сойдет за компилируемый? Хотя что дадут эти измерения с другой стороны?

ВВ>>А скорость "как у Си" не особо-то и требуется на самом деле.

VD>Гы-гы. А нафиг тогда этот С (и особенно С++) сдался бы?

В бизнес-ориентированных приложениях? По большей части не сдался, да.

ВВ>>Типичные бизнес-приложения, много работы с БД, веб-сервисы, прочая хрень — на этом фоне, во-первых, практически весь код таких приложений идет под графом "клей", а во-вторых, и скорость особо и не требуется.

VD>Веб сервисы тоже время занимают. К тому же "типичными бизнес-приложениями" ПО не заканчивается.

Само собой. Не заканчивается. Есть задачи где и производительности дотнета мало.
Я не утверждал, что "скрипты" применимы всегда и везде.

VD>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.


Их пишут на том, что рекламируется "большими вендорами" (тм). Будут рекламировать скрипты — начнут писать на скриптах.
Ну вот сам посуди. Есть, скажем, Шарепоинт. У него в качестве бэкенда — SQL Server. Само собой структура базы универсальная, работать с ней напрямую нельзя. Данные в самом Шарепоинте хранятся в так называемых "списках", структура которых от структуры БД, естестественно, отличается. Т.е. уже присутствует нехилый оверхед по сравнению с рукописной базой.
Далее. Для исполнения запросов по спискам сделан свой специальный язык запросов — CAML. На СКЛ он похож слабо. Но транслируется, конечно, в СКЛ. Т.к. создавала этот КАМЛ какая-то охреневшая сволочь, то сделан он на основе ХМЛ-я, что, конечно же, неудобно — на ХМЛ-е то запросы писать.
Теперь вот до кого-то наконец дошло, что КАМЛ это вроде как "не айс" и надо что-то менять в консерватории. Естественно, открутить КАМЛ совсем нельзя — обратная совместимость понимаешь. Да и к тому же у нас уже теперь в языке встроенный ДСЛ для исполнения запросов. Так что решение вроде как очевидно.
В общем делаем еще один слой сверху — Linq2Caml. Как работает Линк, думаю, ты понимаешь куда лучше меня.

Короче, у меня возникает серьезное подозрение, что по большому счету уже пофиг какова там скорость кода на языке, на котором ты эти Linq2Caml запросы пишешь.

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

ВВ>>Кстати, как раз динамический люкап мне не очень нравится самому.
VD>Я имею в виду рантаймное определение типов значений хранимых в переменных.

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

VD>Поставим вопрос по другому. А зачем она вообще нужна — эта динамика? А вот быстродействие полезно всегда. Я вот не представляю себе парсер написанного динамическом языке. Те же реализации Лиспа все же обычно пользуются парсерами написанными на низкоуровневых языках или специальных расширениях лиспа позволяющих указывать типы и получать тем самым приемлемый по производительности код. Или взять к примеру PyPy-шный парсер. Он как раз реализован на RPython-е который по сути статически типизируемый сабсэт питона. Это позволяет добиться приемлемой производительности.


"Быстродействие полезно всегда" — это какое-то сомнительное утверждение. Зачем? Кому полезно? Почему же мы тогда жертвуем быстродействием, переходя на дотнет? Да и критерий странный — нельзя написать эффективный парсер — язык в помойку. Не так уж много парсеров мы тут пишем.

VD>Короче я дже не хочу обсуждать вопрос производительности динамики с ним давно все ясно. Реально высокая производительность достижима только в статике. Но если для ваших задач хватает и того что обеспечивает динамика (пусть даже с дижтом), то пользуйтесь ее. Я вот за что не возьмусь, так производительность почему-то становится одним из актуальнейших факторов.


Ну я так предполагаю, ты приложения под Шарепоинт не пишешь Да и сфера твоих интересов — компиляторы, парсеры и проч. — как-то действительно с динамикой не очень дружит. Но есть сферы, которые очень даже дружат. Зачем ее втаптывать в грязь-то?
Re[20]: почему в вебе распространены именно динамические язы
От: Mamut Швеция http://dmitriid.com
Дата: 14.10.10 14:49
Оценка:
VD>Короче я дже не хочу обсуждать вопрос производительности динамики с ним давно все ясно. Реально высокая производительность достижима только в статике. Но если для ваших задач хватает и того что обеспечивает динамика (пусть даже с дижтом), то пользуйтесь ее. Я вот за что не возьмусь, так производительность почему-то становится одним из актуальнейших факторов.

А можно примеры?


dmitriid.comGitHubLinkedIn
Re[19]: почему в вебе распространены именно динамические язы
От: Mr.Cat  
Дата: 14.10.10 14:52
Оценка:
Здравствуйте, Mamut, Вы писали:
M>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.
А пруфлинк есть?
Re[20]: почему в вебе распространены именно динамические язы
От: Mr.Cat  
Дата: 14.10.10 15:07
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.
Зато "нескрипты" в "Типичных бизнес-приложениях" (тм) быстро обрастают рефлексией, динамикой и "stringly"-типизацией.
Re[16]: почему в вебе распространены именно динамические язы
От: iZEN СССР  
Дата: 14.10.10 15:15
Оценка:
VD>>>То есть будучи транслированным на Яву код стал работать более чем в два раза быстрее нежели С/С++ версия.

N>>А дальше что? Нашли причину или так и остались в непонятках?


VD>Дык это не я же эту статью писал. Откуда я занаю. Но факт остается фактом даже не стремясь можно получить более быструю реализацию на яве нежели на С++.


VD>С++ хорош не тем что он просто позволяет генерировать быстрый машинный код, а тем, что он позовляет делать низкоуровневые оптимизации.


http://balancer.ru/tech/forum/2008/02/t60021--CHto,gospoda-surovye-S-plus-plus-program.html
Re[21]: почему в вебе распространены именно динамические язы
От: WolfHound  
Дата: 14.10.10 15:34
Оценка: +1
Здравствуйте, Mamut, Вы писали:

M>2. Куда еще более по сушеству? Людям, которые разрабатывают системы для телекома, важнее динамика, а не мифические бенефиты от статики.

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

Что еще "доказать" этим методом?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: почему в вебе распространены именно динамические язы
От: WolfHound  
Дата: 14.10.10 15:34
Оценка: :)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А объявления классов, вариантов и проч. это уже не код? Удобно.

А в динамически типизированых языках объявлений типов нет?

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

О! Пошли переходы на личности.
Верный признак того что аргументы кончились.

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

И огребать потом любые проблемы в продакшене.
А на полезном подмножестве всех програм динамика по сравнению с правильно сделанной статикой ничего не дает.

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

ВВ>Впрочем, что я спрашиваю "как объяснишь". Наверняка в ответ будет что-нибудь нецензурное.
Аппеляция к толпе ни разу не аргумент.
Ибо такими методами можно доказать что угодно.

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

Нет.
В случае с выводом типов у меня есть строгие правила которые позволяют точно вывести все типы всех переменных.
Разрешить все перегрузки.
Я точно знаю где и что.

В случае с динамикой полный бардак. Везде может быть все. Одна и тажа функция может быть вызвана с кучей разных типов.
Ты ссылки того же FR почтай. Там где он рекламирует "круть" IDE для питона...
Статический анализ тупит. Динамический (запуск программы) лучше но тоже далеко не айс. Особенно если запуск не исполняет 100%кода во всех возможных сочетаниях.

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

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


А если у тебя есть доступ к исходниками компилятора то компилятор немерла даст тебе всю информацию (собственно IDE для автокомплита и навигации компилятор и использует), а компилятор питона не даст тебе ничего.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: почему в вебе распространены именно динамические язык
От: WolfHound  
Дата: 14.10.10 15:36
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Ггг. Для веба нужны точно такие же языки, как и для любой другой области.

Ага... для веба нужен DSL как и для любой другой предметной области.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: почему в вебе распространены именно динамические язы
От: WolfHound  
Дата: 14.10.10 15:58
Оценка: :)
Здравствуйте, Mr.Cat, Вы писали:

VD>>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.

MC>Зато "нескрипты" в "Типичных бизнес-приложениях" (тм) быстро обрастают рефлексией, динамикой и "stringly"-типизацией.
Это по тому что "нескрипты" не той системы.
При налисии нормальных макросов не обрастают.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: почему в вебе распространены именно динамические язы
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.10 16:59
Оценка: 1 (1)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Надо бы проверить и правда. Я вот помню, что JScript (к-й вместе с MSIE8 идет) сортирует массив из 1000 элементов пузырьком где-то за 0.35 сек. Руби, кстати, делает это где-то за 1.2 сек. Это на моем домашнем i5 750. При этом уже V8 выполняет эту задачу практически без времени. Могу просто уточнить цифры. V8 сойдет за компилируемый? Хотя что дадут эти измерения с другой стороны?


Мало чего дадут. Хотя узнать кто такое V8 было бы все же интересно. Предполагаю что С++ из VS 2008. А там хрен его знает.

"В среднем" — означает, что какие-то задачи просядет сильнее, какие-то меньше.
Что до Руби, то это пожалуй один из худших интерпретаторов среди популярных скриптов. JScript от МС не худший, но и далеко не лучший.

ВВ>>>А скорость "как у Си" не особо-то и требуется на самом деле.

VD>>Гы-гы. А нафиг тогда этот С (и особенно С++) сдался бы?

ВВ>В бизнес-ориентированных приложениях? По большей части не сдался, да.


Нет. Вообще.

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

ВВ>Само собой. Не заканчивается. Есть задачи где и производительности дотнета мало.


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

Вот тут недавно появлялся орел и спрашивал на какую область разработки ориентирован Немерл
Автор:
Дата: 30.09.10
. Ответ что Немерл является языком общего назначения и применим много для чего его не удовлетворил. Эмпирически он сразу же сделал вывод, что Немерл не применим для математики и для веба ("Математика мимо как я понял. Веб тоже"). Его уверенность была подкреплена одним из ответов
Автор: Don Reba
Дата: 30.09.10
котором говорилось, что работа с матрицами в дотнете реализована не самым шустрым образом. И его не остановило даже то, что в этом же ответе было сказано, что она человек как раз этими самыми рассчетами на немреле и занимается, а работу с матрицами перекладывает на GPU (который по любому на таких задачах любой С++ и i7 порвет). Про веб аргумент было вообще потрясающий — "Немерли так же удобен как пхп?".

ВВ>Я не утверждал, что "скрипты" применимы всегда и везде.


Уже не плохо. Остается только вопрос, зачем ты пошел спорить с моими утверждениями? Точнее с чем не согласен то?
Я же тоже не утверждал, что скрипты не применимы нигде, и никогда.

VD>>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.


ВВ>Их пишут на том, что рекламируется "большими вендорами" (тм). Будут рекламировать скрипты — начнут писать на скриптах.


Ну, дык и все точно так же пишется. Людей со своей головй на плечах очень мало.

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

ВВ>Ну вот сам посуди. Есть, скажем, Шарепоинт. У него в качестве бэкенда — SQL Server. Само собой структура базы универсальная, работать с ней напрямую нельзя. Данные в самом Шарепоинте хранятся в так называемых "списках", структура которых от структуры БД, естестественно, отличается. Т.е. уже присутствует нехилый оверхед по сравнению с рукописной базой.

ВВ>Далее. Для исполнения запросов по спискам сделан свой специальный язык запросов — CAML. На СКЛ он похож слабо. Но транслируется, конечно, в СКЛ. Т.к. создавала этот КАМЛ какая-то охреневшая сволочь, то сделан он на основе ХМЛ-я, что, конечно же, неудобно — на ХМЛ-е то запросы писать.
ВВ>Теперь вот до кого-то наконец дошло, что КАМЛ это вроде как "не айс" и надо что-то менять в консерватории. Естественно, открутить КАМЛ совсем нельзя — обратная совместимость понимаешь. Да и к тому же у нас уже теперь в языке встроенный ДСЛ для исполнения запросов. Так что решение вроде как очевидно.
ВВ>В общем делаем еще один слой сверху — Linq2Caml. Как работает Линк, думаю, ты понимаешь куда лучше меня.

ВВ>Короче, у меня возникает серьезное подозрение, что по большому счету уже пофиг какова там скорость кода на языке, на котором ты эти Linq2Caml запросы пишешь.


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

Но это же не означает, что нет задач требующих хорошей производительности?

ВВ>Ну да, в этом суть динамической типизации. И *только* в этом. Больше ничего сюда примешивать не надо.


Это не совсем так. Просто динамика — это всего лишь "дешевое обобщение". Это конечно можно считать огромным плюсом. Но на самом деле современные сктипты популярны не столько из-за этого, сколько из-за поддержки ими "дешевого метапрограммирования". Дешевого — означает легко доступного, а не плохого (если что).

ВВ>И тут все просто на самом деле — тот факт, что все решения о типах принимаются в рантайме есть одновременно и главное преимущество, и главный недостаток динамически-типизированных языков.


Несомненно.

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


Такой же наверно не достичь. Но достичь приемлемой гибкости можно и относительно легко.

ВВ>но в динамике нельзя так хорошо проконтролировать программиста.


И получать такой же оптимизированный (читай быстырй) код.

VD>>Поставим вопрос по другому. А зачем она вообще нужна — эта динамика? А вот быстродействие полезно всегда. Я вот не представляю себе парсер написанного динамическом языке. Те же реализации Лиспа все же обычно пользуются парсерами написанными на низкоуровневых языках или специальных расширениях лиспа позволяющих указывать типы и получать тем самым приемлемый по производительности код. Или взять к примеру PyPy-шный парсер. Он как раз реализован на RPython-е который по сути статически типизируемый сабсэт питона. Это позволяет добиться приемлемой производительности.


ВВ>"Быстродействие полезно всегда" — это какое-то сомнительное утверждение.


Не более чем "динамика полезна".

ВВ>Зачем? Кому полезно?


В первую очередь пользователю.

ВВ>Почему же мы тогда жертвуем быстродействием, переходя на дотнет?


Зачем чушь то говорить? Ничем мы не жертвуем. На дотнете без проблем можно писать очень быстрый код. В него даже С++ можно компилировать почти без потерь производительности.

ВВ>Да и критерий странный — нельзя написать эффективный парсер — язык в помойку.


Я не говорил о помойке. Я говорил, что нельзя.

ВВ>Не так уж много парсеров мы тут пишем.


Это не важно. Я просто привел близкий и мне, и тебе пример. Ты же парсер для своего языка на Шарпе написал, а не на самом же твоем языке, не смотря на то, что сам считаешь свой язык более гибким и удобным. Так ведь?

VD>>Короче я дже не хочу обсуждать вопрос производительности динамики с ним давно все ясно. Реально высокая производительность достижима только в статике. Но если для ваших задач хватает и того что обеспечивает динамика (пусть даже с дижтом), то пользуйтесь ее. Я вот за что не возьмусь, так производительность почему-то становится одним из актуальнейших факторов.


ВВ>Ну я так предполагаю, ты приложения под Шарепоинт не пишешь


100%. И я уж лучше в таксисты пойду нежели буду заниматься этим (как бы не накаркать ).

ВВ>Да и сфера твоих интересов — компиляторы, парсеры и проч. — как-то действительно с динамикой не очень дружит.


Да нет тех сфер которые с ней дружат (или не дружат). Нееет! Для любой сферы можно с тем же успехом использовать подходящий статически-типизированный язык. Фактор "мне кажется удобнее" — это все же субективное мнение. Тебе кажется удобнее, а мне нет. А вот фактор достаточности производительности является весьма объективным.

ВВ>Но есть сферы, которые очень даже дружат. Зачем ее втаптывать в грязь-то?


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

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

Скажем разработка в стиле REPL действительно появилась в скриптовых языках, но тем не менее доступна и в статически типизированных. Другое дело что ее почти нет в мэйнстриме. А то что есть не всегда также функционально что и в динамических реализациях.

Полиморфизм всегда и везде уже не является таким уж однозначным плюсом. Плюсом является простота достижения этого самого полиморфизма. В скриптах полиморфизм достигается очень просто. Скажем в дотнете с этим есть проблемы, так как при наличии самих средств полиморфизма все же есть проблемы в реализации полиморфных методов. В основном они связаны с невозможностью полиморфного использования уже имеющихся типов (которые не были для этого предназначены). Проще говоря мы не можем в денерик-методах или типах использовать специфичные методы/операторы/свойства типов. Для этого нужно делать ряд телодвижений вроде введения и реализации интерфейсов, создания промежуточных объектов (вроде компараторов), использования лямбд для абстрагирования алгоритмов. Да — это создает неудобства. Но а) это не есть ограничение статики, это ограничение конкретной реализации, б) освоение небольшого набора приемов позволяет легко обходить эту проблему.

Еще одним (и возможно основным) "преимуществом" динамики является наличие метапрограммирования. Это мало кто афиширует (кроме, пожалуй, лисперов), но тем не менее — это так! Какие самые популярные языки программирования? Питон, Руби, Лиспы и ЯваСкрип (причем последний популярен в основном благодаря его доступности в браузерах). Все эти языки имеют весьма мощную (ну, за исключением ЯваСкрипа) подсистему метапрограммирования. Это позволяет создавать на их базе весьма выразительные и мощные решения.

Но как мы с вами знаем, метапрограммирование так же не является отличительной чертой скриптов. Просто его намного сложно качественно реализовать в статически-типизированном языке.

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

У статики тоже есть свои приемущества. И они не заканчиваются скоростью получаемого кода. Статика обеспечивает наличие исчерпывающей метаинформации еще на стадии разработки. А это и рефакторин, и навигация по коду, и подсказки, и контроль массы ошибок и много чего еще и все это в режиме разработки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: почему в вебе распространены именно динамические язы
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.10 17:02
Оценка:
Здравствуйте, Mamut, Вы писали:

VD>>Короче я дже не хочу обсуждать вопрос производительности динамики с ним давно все ясно. Реально высокая производительность достижима только в статике. Но если для ваших задач хватает и того что обеспечивает динамика (пусть даже с дижтом), то пользуйтесь ее. Я вот за что не возьмусь, так производительность почему-то становится одним из актуальнейших факторов.


M>А можно примеры?


Примеры задач требующих хорошей производительности? Ты сам их не знаешь? Текстовые редакторы, компиляторы, конвертеры которые должны работать в интерактивном режиме и много чего еще. Про конвертацию видео и т.п. я даже заикаться не хочу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: почему в вебе распространены именно динамические язы
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.10 17:05
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

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

VD>>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.
MC>Зато "нескрипты" в "Типичных бизнес-приложениях" (тм) быстро обрастают рефлексией, динамикой и "stringly"-типизацией.

Не знаю. Сейчас тенденция обратная. Вот SQL на LINQ заменяют.

Для динамики в статике же давно придумали отличное решение — компонентный подход. Его применение позволяет достичь многих вещей ради чего применяют к скриптам, но при этом оставаясь в рамках статической типизации. Конечно можно назвать это рефлексией — но это хорошая рефлексия.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: почему в вебе распространены именно динамические язы
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.10.10 17:07
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>http://balancer.ru/tech/forum/2008/02/t60021--CHto,gospoda-surovye-S-plus-plus-program.html

ZEN>

Сори, пенесометрии меня мало интересуют. Я знаю, что хорошие руки на С/С++ всегда могут оптимизировать решение задачи так, что никакие автоматические средства до этого решения не дотянут. Но я так же знаю цену таких оптимизаций.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: почему в вебе распространены именно динамические язы
От: Mamut Швеция http://dmitriid.com
Дата: 14.10.10 18:21
Оценка: 26 (3)
Здравствуйте, Mr.Cat, Вы писали:

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

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

сейчас лень искать далеко по рассылке, но есть пара ссылок в таком ключе:

http://article.gmane.org/gmane.comp.lang.erlang.general/19158

ericsson (who funds the OTP development) has reached the
conclusion that static typing would not improve the reliability of their
products. some ericsson people might even argue that static typing would lower
the quality of said products.


http://article.gmane.org/gmane.comp.lang.erlang.general/19165

...none of the attempts at
creating a static type system for Erlang were able to
attract enough users to become interesting in practice.

...there
is no formal acceptance or rejection process for Erlang.
If it had proven useful and enough people had started
using it, static typing might have made it into Erlang.



В догонку:
http://article.gmane.org/gmane.comp.lang.erlang.general/19182

a few years ago i did a study on erlang-related bug reports in our live
product. the conclusion was that once we get to system test, we find essentially
no more type-related bugs.

www.erlang.se/workshop/2004/matsbilder.pdf



dmitriid.comGitHubLinkedIn
Re[22]: почему в вебе распространены именно динамические язы
От: Mamut Швеция http://dmitriid.com
Дата: 14.10.10 18:25
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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


M>>2. Куда еще более по сушеству? Людям, которые разрабатывают системы для телекома, важнее динамика, а не мифические бенефиты от статики.

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

WH>Что еще "доказать" этим методом?


Нуну. От тебя, я вижу, «аргументы» еще более по существу. Тут еще надо внимательно приглядется, кто на наркотиках


dmitriid.comGitHubLinkedIn
Re[22]: почему в вебе распространены именно динамические язы
От: Mamut Швеция http://dmitriid.com
Дата: 14.10.10 18:40
Оценка:
VD>>>Короче я дже не хочу обсуждать вопрос производительности динамики с ним давно все ясно. Реально высокая производительность достижима только в статике. Но если для ваших задач хватает и того что обеспечивает динамика (пусть даже с дижтом), то пользуйтесь ее. Я вот за что не возьмусь, так производительность почему-то становится одним из актуальнейших факторов.

M>>А можно примеры?


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



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

VD>Про конвертацию видео и т.п. я даже заикаться не хочу.


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


dmitriid.comGitHubLinkedIn
Re[21]: почему в вебе распространены именно динамические язы
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.10.10 18:57
Оценка:
Здравствуйте, Mamut, Вы писали:

M>сейчас лень искать далеко по рассылке, но есть пара ссылок в таком ключе:


M>http://article.gmane.org/gmane.comp.lang.erlang.general/19158

M>http://article.gmane.org/gmane.comp.lang.erlang.general/19165
M>В догонку:
M>http://article.gmane.org/gmane.comp.lang.erlang.general/19182

Спасиб, Мамут, что напомнил тёрки 4-летней давности
Re[23]: почему в вебе распространены именно динамические язы
От: WolfHound  
Дата: 14.10.10 20:05
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Нуну. От тебя, я вижу, «аргументы» еще более по существу. Тут еще надо внимательно приглядется, кто на наркотиках

Мои аргументы объективны.
1)Скорость исполнения у динамически типизированных языков ниже.
2)Динамически типизированные языки не ловят ошибки на этапе компиляции.

Назови хоть одно преимущество динамической типизации.
Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
Метапрограммирование? Так оно прекрасно работает и в статически типизированных языках.
Кодогенерация в рантайме? Опять никаких проблем.

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

Все что у тебя есть это "Миллион леммионгов не может ошибаться." Ага...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: почему в вебе распространены именно динамические язы
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 14.10.10 20:22
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Назови хоть одно преимущество динамической типизации.

WH>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.
Re[25]: почему в вебе распространены именно динамические язы
От: -_*  
Дата: 14.10.10 22:13
Оценка:
Здравствуйте, gandjustas, Вы писали:

WH>>Назови хоть одно преимущество динамической типизации.

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

Да фигня этот тестовый код. Есть простое правило — чисто не там, где не гадят, а там, где убирают. В динамических языках при объеме кода больше определенного порога вобще невозможо даже теоретически привести код в порядок.
По этой причне динамика процветает именно там, где код проще выкинуть и написать заново. Веб это вобщем то именно такое место.
Тестовый, не тестовый код, если его можно упростить, причесать, преобразовать — то этим проблемы и решатся. Единственно, где у динамики преимущество, это перед С++. Там тоже принято не убирать за собой.
Материал из Википедии — свободной энциклопедии, -_*
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.