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

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>А кто будет сторожить сторожей?

YKU>

YKU>$TestsResult = fasle; // or result of smthng or...

YKU>//
YKU>// ....
YKU>//

YKU>$TestResult = Security.IsAccessAllowed($fakeUser); // You cannot pass!
YKU>Assert.AreEqual(false, $TestsResult);
YKU>

YKU>Мы всё сделали правильно, обложились тестами, нам опечатки не страшны?

Примера не понял

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

AVK>>А если не нужен?
D>Не нужен, не используйте, в чем проблемма?

В динамике статического бидинга нет.

AVK>>Думаю, да. Миллионы леммингов и не такое вытворяют. Достаточно вспомнить, что основу динамики в вебе составляют не django и ror, а кривокосоглазый php.
D>Причина не в леммингах, а в том что php на десять лет старше

Уверен?

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

php был кривоглазым с рождения.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>Ты изначальную тему не забыл, если что? ASP.NET, как я помню, поддерживал эту самую динамическую компиляцию с версии 1.0. Только Visual Studio не поддерживала. И активно рекламировался code behind как "тру" путь.

Что и где рекламируется — нетехнический вопрос, и лично мне его обсуждать не интересно. Чем больше народа на подобную рекламу будут вестись, тем востребованее будет мой труд.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

Здравствуйте, Mamut, Вы писали:
S>>Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит.
M>Ну, люди, пишущие на Erlang'е с тобой не согласились бы

Кстати да. Раз уж речь зашла, в The Development of Erlang (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.5602) есть и страничка про типизацию (о способности системы типов ловить что-то серьезнее опечаток).

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

ВВ>Примера не понял

Из-за опечатки тест всегда будет passed. Пример иллюстрирует, так иногда тесты помогают в борьбе с опечатками.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

ВВ>>Примера не понял

YKU>Из-за опечатки тест всегда будет passed. Пример иллюстрирует, так иногда тесты помогают в борьбе с опечатками.

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

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

S>>Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит.
M>Ну, люди, пишущие на Erlang'е с тобой не согласились бы

Ну так эрланг слегка специфичная штука и не лезет в "нишу явы/шарпа".

*да-да, я издевательски придерживаюсь исходной темы.

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

D>Если вам нужен late binding, вам статика также не спасет.
Он не нужен, но как вы собираетесь добиться динамической типизации без позднего связывания?

S>>Необязательно. Вы ещё забыли вызовов метода с неверными параметрами/вызов недопустимого в данном состоянии метода. Вот имено их CodeContracts и ловят в основном.
D>А кто мешает их исользовать в динамике? Все равно подовляющее большенство падений происходит также в рантайме.
То, что для динамика code flow построить мягко говоря посложнее.

S>>Дык примеры, примеры!
D>90% интернета? Если бы от статики была бы существенная польза, акромя скорости которая в вэбе особо не нужна, думаете все бы продолжали есть кактусы?
Ну censored же! Следим за дискуссией, ок? Третьему человеку говорю: я ответил на

Тогда возникает вопрос...
почему все остальные области не перешли на такие языки?
все остальные = имеется в виду не ниша C++ и т п, а ниша C# и Java

А то так можно договориться до того, что я вообще против <подставить нужное>.

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

FR>Design by Contract вполне применим и применяется в динамике. Конечно чисто статической проверки как в NET'овском Code Contracts (там кстати тоже без прогона в общем не обойтись)
Не совсем так, используется "abstract interpretation", что бы это у MS Research не значило.
http://research.microsoft.com/apps/pubs/default.aspx?id=135669

FR> но в том же питоне (в Smalltalk тоже) например контракты оформляются в виде декораторов и метаклассов, которые отрабатывают в момент загрузки модуля (аналог compile-time для статики).

Гмм... а возможно организовать что-то аля code flow analysis — чтоб обнаруживать только действительные нарушения контрактов? Code Contracts именно этим и сильны — если у нас какое-то условие уже проверено, ложных сообщений о нарушении контракта не будет.

Я даже в теории не могу представить, как это можно сделать для динамики, когда в общем случае неизвестно что это у нас за "a.Foo 42";

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

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

AVK>>>Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

iZEN>>Да только эти, с позволения сказать, "околотехнологии" завязаны на одну платформу — Windows. И Microsoft пророк её.

AVK>Очень в тему топика

. И, да, MVC под Mono работает.

Mono на сервере? Только в страшном сне.

http://www.linux.org.ru/news/opensource/5414839/page-1

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

Accepted. У меня даже возразить по делу не получается —

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

S>Не совсем так, используется "abstract interpretation", что бы это у MS Research не значило.
S>http://research.microsoft.com/apps/pubs/default.aspx?id=135669

Ну по сути (как я это понимаю) это довольно просто вместо реального прогона байткода проводится его интерпретация с проверкой только некоторых аспектов, например типизации, эта же технология используется в одной из реализаций питона PyPy http://codespeak.net/pypy/dist/pypy/doc/theory.html#abstract-interpretation

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

FR>> но в том же питоне (в Smalltalk тоже) например контракты оформляются в виде декораторов и метаклассов, которые отрабатывают в момент загрузки модуля (аналог compile-time для статики).

S>Гмм... а возможно организовать что-то аля code flow analysis — чтоб обнаруживать только действительные нарушения контрактов? Code Contracts именно этим и сильны — если у нас какое-то условие уже проверено, ложных сообщений о нарушении контракта не будет.

В классическом питоне нет.
Но тот же PyPy по сути проводит анализ программы, вывод типов и перевод на статическое подмножество питона (R-Python) он как раз умеет строить статические control flow graph http://codespeak.net/pypy/dist/pypy/doc/architecture.html#the-translation-framework.
Аналогичные вещи были разработаны и для Smalltalk — Strongtalk и Self, от них кстати и пошли JIT для явы. Также компиляторы лиспа и схемы используют подобные технологии (как демонстрация http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)).

S>Я даже в теории не могу представить, как это можно сделать для динамики, когда в общем случае неизвестно что это у нас за "a.Foo 42";

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

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

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

D>>Если вам нужен late binding, вам статика также не спасет.
S>Он не нужен, но как вы собираетесь добиться динамической типизации без позднего связывания?
Я применяю термин познего связывания не к
class foo:
def bar(self):
return 1;
foo().bar

а к

get("http://something.com/getjson").bar

Или вы утверждаете что сейчас нет нормальных ide для дя?

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

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

FR>Но ни абстрактная интерпретация, ни статические проверки (без зависимых типов) не могут проверить все контракты, простейший пример функция получающая ограниченный диапазон целых чисел.

Вполне возможно, что я вас неправильно понял, но CC такие ассерты спокойнейше прожёвывают. Более того, они прожёвывают любую функцию без сайд-эффектов (помеченную атрибутом [Pure]). Так что не так всё просто

void A(int a)
{
  Contract.Requires(a>5);
  Contract.Requires(a<25);
}
void B()
{
  A(222);
}

Завтра конечно проверю, но я не вижу причин, по которым код выше не будет работать. Отпишусь.

FR>В классическом питоне нет...
Ок, покопаюсь. Спасибо!

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

R>>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

Л>Сваять очередной интерпретируемый язык банально проще и быстрей.

Замечание интересное, но — пусть и сваял кто-то новый язык, и что — он сразу становится популярным в вебе? К тому же не так уж и много разных интерпретируемых языков популярно в вебе.

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

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

ZEN>Mono на сервере? Только в страшном сне.

Знаю не одну работающую инсталляцию. ВРоде бы неизлечимых проблем нет. А что не так?

ZEN>http://www.linux.org.ru/news/opensource/5414839/page-1

И? Я должен просмотреть лоровский пердеж чтобы понять, что ты сказать хотел?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

S>Вполне возможно, что я вас неправильно понял, но CC такие ассерты спокойнейше прожёвывают. Более того, они прожёвывают любую функцию без сайд-эффектов (помеченную атрибутом [Pure]). Так что не так всё просто

S>void A(int a)
S>{
S>  Contract.Requires(a>5);
S>  Contract.Requires(a<25);
S>}
S>void B()
S>{
S>  A(222);
S>}
S>

S>Завтра конечно проверю, но я не вижу причин, по которым код выше не будет работать. Отпишусь.

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

pure int A(int a)
in
{
    assert(a > 5);
    assert(a < 25);
}
body
{
    return a + 1;
}

void main()
{
    static x = A(123);
}

Выдаст во время компиляции такую ошибку:

contr1.d(6): Error: assert(a < 25) failed
contr1.d(15): Error: cannot evaluate A(123) at compile time

Но если заменить static (это вычисляется в compile time) на auto, то ошибок компиляции не будет, но будет
исключение после запуска.

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

FR>Так на вход же может подаваться любая переменная свободно изменяющаяся в рантайме, без зависимых типов такое не разрулить,

Ну да. CC выдают предупреждение "contract unproven". Либо игнорировать (выпадет в рантайме, если включите соотв. опцию), либо добавлять проверки выше по стеку. Ложных срабатываний (пока) очень мало.

FR>Например D тоже может в compile time для констант разруливать такие контракты:
Интересный подход.

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

F>Замечание интересное, но — пусть и сваял кто-то новый язык, и что — он сразу становится популярным в вебе?
Конечно нет. Стать популярным — это все равно, что выиграть в лотерею.

F>К тому же не так уж и много разных интерпретируемых языков популярно в вебе.
Я подозреваю, что практически все они специально для веба и разрабатывались. Даже, наверное, для собственных нужд авторов в рамках тех или иных веб проектов. Так что получить результат по-быстрее для их создателей было очень актуальнео.

Вообще, потребность в Domain Specific Language для веба достаточно очевидна. Но я б ручонки всем авторам динамических языков поотрывал. Могли бы ограничиться трансляторами со своего языка в сишный или плюсовый код. На самом C++ могли бы с помощью перегрузки операторов сделать DSL. Да и вообще, для веба нужен не столько функциональный язык, сколько HTML-шаблонизатор с возможностью подстановки данных из баз, интеграцией с веб-сервером.

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

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

А почему ты так считашь? Вот на этом сайте все не так, например. И таких примеров море. Чем более отечественная разработка, тем реже там скрипты и тем чаще там компилируемые (но тоже безопасные и динамичные) языки.

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

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

	От:	Воронков Василий
	Дата:	12.10.10 11:44
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	12.10.10 11:49
Оценка:	+1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	12.10.10 11:49
Оценка:

	От:	Mr.Cat
	Дата:	12.10.10 11:52
	Оценка:

	От:	yoriсk.kiev.ua
	Дата:	12.10.10 12:10
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	12.10.10 16:56
Оценка:	+1