Зачем нужны динамические языки?

> Попробуйте задействовать в Makefile функции для работы со строками и контейнерами, которые Вы написали в одной из своих C++ библиотек. Это в принципе невозможно. Отмазки типа "а это и не нужно" не примаются.

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

> > А это - один из самых тормознутых методов.

> На эту тему есть разные мнения...

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

> Обращаю внимание на то, что в гомогенной среде нет разнородных частей, поэтому с ними не могут быть траблы.

Ха! Три раза. Если ты не видел траблов с интеграцией различных частей, написанных на ОДНОМ языке - значит, не видел крупных проектов.

> Попробуйте задействовать в Makefile функции для работы со строками и контейнерами, которые Вы написали в одной из своих C++ библиотек. Это в принципе невозможно.

Ну уж и невозможно. В Makefile вполне нормальным приёмом является задействовать внешнюю утилиту, написанную на чём угодно - например, на плюсах. Лишь бы дёргалась через stdin/stdout.

>> Однако, конечно же, пересобрать всё с нуля - это в отдалённой перспективе более надёжно, чем править на лету

> О чем и речь. И даже в ближней перспективе это более надежно.

Но инкрементальная разработка - это очень удобно :)

> Это не мнение

Это именно мнение, одно из. Общего мнения среди разработчиков GC на эту тему еще нет.

> Достаточно подумать, и поймёшь

...что недостаточно квалифицирован, чтобы рассуждать на эту тему.

> при подсчёте ссылок могут возникать совершенно произвольные временные лаги

Разработчики Recycler так не думают: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.1065. Или http://portal.acm.org/citation.cfm?id=1111596.1111597 Короче, it ain't over till it's over

>> То есть совершенно безнадежное (по твоим словам) средство используется на практике

> Если бы ты был внимателен, то обратил бы внимание, что я упираю на динамизм SQL

То есть фразу "в статическом языке всё безнадёжно" следует понимать как "если бы SQL был статическим, в нем было бы всё безнадежно"?

>> Я говорил о статической проверке типов (type inference может использоваться не только для нее).

> Я также и не против проверки типов

Вот и славно.

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

Альтернативой этому было бы оставление системы в гарантированно неработоспособном виде. Учитывая корни Firebird в околовоенных разработках, их решение понятно.

>> Слушай (вернемся к примеру Greck с изменением схемы БД) - ты бы правда изменил схему именно на рабочем сервере, и перезапустил приложение прямо в работу?

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

То есть ты тоже надеваешь трусы через голову? :)

> Тем не менее, факт состоит в том, что я не останавливаю и не пересобираю сервер СУБД, когда делаю alter table. Именно это я и хочу подчеркнуть, т.к. это проявление динамичной системы.

Это пример reflection. Более чем возможна в статически типизированных языках.

> То есть фразу "в статическом языке всё безнадёжно" следует понимать как "если бы SQL был статическим, в нем было бы всё безнадежно"?

Именно. Если бы SQL был статическим, то для alter table нужно было бы выгрузить все данные, изменить структуру где-то в *.h, пересобрать сервер, перезапустить его, загрузить данные по-новой. Вот что такое "статический типизированный язык". Язык/среда, позволяющий/ая менять структуру данных во время исполнения - динамическая. И кстати, alter table - это не reflection.

> Учитывая корни Firebird в околовоенных разработках, их решение понятно
Надёжность Firebird оставляет желать много лучшего, даже не смотря на то, что со времён Interbase, видимо, исправлено больше багов, чем добавлено новых. Это и хорошо, т.к. Interbase находится на вооружении потенциального противника :)

TWIMC:

http://lambda-the-ultimate.org/node/3261

Для Ъ: команда разработчиков Twitter перешла с динамического Ruby на статический Scala, потому что RoR не выдерживает трафик.

> Для Ъ: команда разработчиков Twitter перешла с динамического Ruby на статический Scala

"I'm a System Engineer at Twitter and also a long-time LtU reader.

To clarify, we haven't replaced RoR with Scala, we've augmented our Rails system with Scala where we think it fits better."

> О сложности реализации spaghetti stack и эффективности - это отдельный разговор. А вот полезно ли? Оказывается, иногда полезно.

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

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

Я твои кю посмотрел, но так и не понял этого. Ладно, метавопрос:

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

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

1. О какой *вообще* гомогенности среды идет речь, если у нас как минимум есть язык Х и SQL?

2. Никакая реклама гомогенности, особенно после п.1, не заставит меня не писать скрипт из 20 строк, если он удобно (и особенно -- предположительно навсегда) решает мои проблемы.

На тему perl vs. ruby -- вполне возможно, падающая популярность перла объясняется именно тем, что руби более аккуратно делает то же самое.

Но для написания скриптов из 20 строк разница я думаю будет не ощутима.

>> Че-то мне не понятно, как лениво менять все объекты без жутких тормозов. Ведь это надо вставлять проверку "а не поменялось ли определение класса" на каждый вызов метода этого объекта, или как?

> Нет, такие проверки не вставляются. Все работает и без проверок. В динамических языках у классов нет строго заданного API -- не фиксированны ни instance-variables, ни methods, ни class method -- в общем, ничего. Единственное, что определяет класс -- это его имя. Смена API класса в рантайме не повод для того, чтобы что-то перестало работать. Это совсем другой мир.

Хорошо, объясняю более подробно. Ключевое слово -- "лениво".

Допустим, у нас в старой версии объекта есть поле "персона", а в новой -- 2 поля -- имя и фамилия. Старые функции юзают одно поле, новые -- 2 других. Допустим, мы сменили реализацию объекта, заменили старые функции новыми, но тогда нам надо НЕ ЛЕНИВО прогнать конвертер, либо (тогда это будет лениво) при вызове новых функций постоянно проверять версию объекта, и в случае старой версии вызывать конвертер, что я и назвал жуткими тормозами.

> Но инкрементальная разработка - это очень удобно

И никто не мешает в статических языках такому же финту, как (кажется ден73 писал) подгрузка новых функций на ходу, как делает жцц-шный лисп.

Да кстати, тебя тоже вопрос про ленивость (см. мой пост выше) касается.

> {-# LANGUAGE FlexibleInstances, UndecidableInstances, OverlappingInstances #-}

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

Еще минорное замечание -- вместо foo надо писать, чтобы было понятнее.

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

template<class T> Num
{
Num<T> operator + (Num<T>& a, Num<T>& b) { compile_time_error("not implemented"); }
};

(в ж++ есть такой compile_time_error, но я его забыл и не могу найти)

Еще минорное замечание -- вместо foo надо писать maxbound, чтобы было понятнее.

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

Ещё как укажет. Регулярно приходится натыкаться на "invalid object" после изменений в ораклёвой БД. Именно по такому критерию -- табличка изменилась -- всё процедуры, с ней несовместимые, не компилятся.

Т.ч. извини, уже лет надцать как наглая ложь.

>Если говорить конкретно про клиент-серверные SQL приложения

>можно править на лету.

Многие ли SQL БД поддерживают таблицы типа 32% новой структуры (уже сконвертировали), 67 - старой, 1% сейчас в работе, заблокирован? Т.ч. аптейт "большой" бд всё равно бутет с большой остановкой, маленькой -- всё равно перезагрузка будет быстрой, а

>не всегда есть возможность остановить систему

-- плохой дизайн. Возможность должна быть всегда, т.к. shit happens.

>ошибку в раздаче прав пользователям иначе как тестами не отловить и я не думаю

А нужно думать:). Тот же oracle отлавливает proc и pl/sql компиляторами. По крайней мере так выглядит со стороны -- программы не собираются без нужных прав.

> И никто не мешает в статических языках такому же финту, как (кажется ден73 писал) подгрузка новых функций на ходу, как делает жцц-шный лисп.

Давай ты не будешь уподобляться Miguel'ю, и не будешь говорить про то, не знаешь/не пробовал/не понимаешь? :)

> Да кстати, тебя тоже вопрос про ленивость (см. мой пост выше) касается.

Я вашу перепалку не читаю. Скучно-с...

>Если бы SQL был статическим, то для alter table нужно было бы выгрузить все данные, изменить структуру где-то в *.h, пересобрать сервер, перезапустить его, загрузить данные по-новой.

Ложь. Ты говоришь об "SQL", а не о языке исходников сервера. Т.ч. перекомпилировать нужно не сервер, а sql-запросы. И некоторые это таки делают, т.ч. sql ни разу не динамический (сам по себе, возможно у кого-то есть динамическая реализация -- но я бы удивился).

> Ложь. Ты говоришь об "SQL", а не о языке исходников сервера.
Не тупи. Уже 5-й раз объясняю, неужели непонятно? То, что в обычном языке является классами, в SQL является таблицами. Значит, alter table - это изменение класса в рантайме. Тут люди утверждают, что динамические языки не нужны и изменение классов в рантайме не нужно, а нужна статическая проверка типов. Которая подразумевает, что мы останавливаем сервер, перекомпилируем его и запускаем заново. Т.е., если бы вместо SQL мы пользовались бы для хранения данных, к примеру, Хаскелем или плюсами со слоем persistency для родных типов/классов, нам нужно было бы перекомпилировать наш сервер для alter table. Или делать какие-то более гибкие виртуальные классы, которые можно менять в рантайме. Что тянет за собой много последствий.

> Т.ч. перекомпилировать нужно не сервер, а sql-запросы
Начнём с того, что любой динамический sql-запрос перед выполнением компилируется в некий "план", который может быть либо байт-кодом для какой-то машины, либо нативным кодом (не знаю, как это реализовано, но думаю, что в Firebird это - байт-код). То же происходит с хранимыми процедурами при их обновлении. Как именно это происходит - зависит от сервера. В любом случае, есть таблица зависимостей между процедурами, таблицами и т.п. В Firebird видимо, они не перекомилируются, но зато ты ничего и не поменяешь, что могло бы нарушить зависимости. Поэтому в Firebird, можно сказать, реализована инкрементная статическая линковка. В MS SQL процедура помечается как протухшая, если поменялось что-то, от чего она зависит. И процедура перекомилируется лениво, при первом вызове. Соответственно, можно нарушить зависимости и возможны ошибки несоответствия типов в рантайме. Зато гораздо удобнее менять серверный код, не нужно распутывать клубок зависимостей. Что кстати, служит примером, когда ослабление проверки типов полезно. Т.е., в MS SQL реализована ленивая инкрементная динамическая линковка. При этом в MS SQL можно сделать и как в Firebird, там есть что-то вроде with schema binding, когда ты уже не можешь поменять то, от чего зависит данный объект. При этом, повторюсь, и MS SQL, и Firebird динамичны с точки зрения возможности менять код в рантайме и при этом строго типизированы.

> И некоторые это таки делают
И я тоже это раньше делал, когда работал с MS SQL. Но я перекомпилировал не весь серверный код, а только затронутый,согласно вручную написанному makefile.

Так вот, мы видим, что для того, чтобы написать SQL сервер на статическом языке, нам нужно всё равно реализовать динамический язык на этом статическом языке. Динамический alter table - это требование самой жизни, а не чья-то прихоть. Таким образом, те, кто с пеной у рта кричат, что нужны только статические языки, на самом деле, просто видят только какой-то крайне ограниченный круг задач (в лучшем случае), или хотят изуродовать жизнь всем остальным в угоду своему религиозному фанатизму (в худшем случае, но такое тоже бывает...)

А если, к примеру,писать SQL сервер на лиспе, то там можно сделать таблицу классом самого лиспа, т.к. классы лиспа можно менять в рантайме. Хотя это, на самом деле, только нулевое приближение и всё не так уж просто из-за многопользовательского доступа, как верно отметил предыдущий оратор. Тем не менее, если встанет задача написать SQL сервер, то на лиспе его можно будет написать гораздо быстрее, т.к. не нужно создавать новую динамическую инфраструктуру, а можно воспользоваться уже существующей. Также не нужно создавать байт-машину, формат байт-кода и компилятор в него. Нужно всего лишь написать транслятор с SQL на лисп, а дальше откомпилировать полученную функцию компилятором лиспа. Сразу получится нативный код.
Другое дело, что в лиспе всё же есть ограничения производительности, связанные со сборкой мусора и с тем, что не всегда можно избавиться от динамической типизации. Но это уже слабо связано с его динамической природой. Это скорее особенности дизайна. Но я уверен, что если сейчас начать с нуля писать новый SQL сервер на лиспе с хранением данных в памяти, то он будет написан быстро и будет очень неплохо смотреться на фоне аналогов.

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

Текстовые редакторы (Emacs, MS Word)
КАДы (автокад)
Музыкальные редакторы (cakewalk)
Программы для научных расчётов (noname, но со мной обсуждали такую потребность)
Банковские/Бухгалтерские системы (1C, КВОРУМ)
Веб-браузеры (почти все)
Операционная системы (в юниксе - шелл)

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

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

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

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

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

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

>>> Че-то мне не понятно, как лениво менять все объекты без жутких тормозов. Ведь это надо вставлять проверку "а не поменялось ли определение класса" на каждый вызов метода этого объекта, или как?

>> Нет, такие проверки не вставляются. Все работает и без проверок. В динамических языках у классов нет строго заданного API -- не фиксированны ни instance-variables, ни methods, ни class method -- в общем, ничего. Единственное, что определяет класс -- это его имя. Смена API класса в рантайме не повод для того, чтобы что-то перестало работать. Это совсем другой мир.

> Хорошо, объясняю более подробно. Ключевое слово -- "лениво".

> Допустим, у нас в старой версии объекта есть поле "персона", а в новой -- 2 поля -- имя и фамилия. Старые функции юзают одно поле, новые -- 2 других. Допустим, мы сменили реализацию объекта, заменили старые функции новыми, но тогда нам надо НЕ ЛЕНИВО прогнать конвертер, либо (тогда это будет лениво) при вызове новых функций постоянно проверять версию объекта, и в случае старой версии вызывать конвертер, что я и назвал жуткими тормозами.

Хорошо, теперь я попробую объяснить более подробно: Нет, так не делается ни в RoR, ни в Django, ни в Symfony, ни ... Ни в одном из известных мне языков программирования нет встроеной в язык возможности маркировать методы/классы меткой старый/новый. Изменил класс -- всё, он сменился. Старый канул в лету. И, как не странно, объекты этого класса после смены не нужно конвертировать вообще. И я попытался объяснить почему -- потому что можно думать про объект любого класса как про хеш (в языке Lua так сделали явно и не пошли дальше этого), грубо говоря {:class=>"User", :login => "root", :email=> ...}. Зачем хеши конвертировать? Там ничего не должно измениться. Сами прекомпилированные методы в объект включать не нужно, так как они определяются по имени класса. Если у класса в режиме рантайт появились новые методы, то все объекты смогут эти новые методы использовать. Всё что описано тобой есть действительно жуткая фантазия на тему "как бы затормозить систему". Ни отложенных, ни каких других преобразований объектов не делается при модификации классов.

Преобразования таблиц данных делается. В RoR они называются миграциями и тоже пишутся на Ruby, а не на SQL (уточню -- в подавляющем большинстве случаев; но иногда некоторые в миграциях пишут что-то хитрое свое на SQL - но это черевато тем, что будет более сложный переход к другой MSDB, если он понадобится).

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

> 1. О какой *вообще* гомогенности среды идет речь, если у нас как минимум есть язык Х и SQL?

Сюрприз!! Разработчики RoR могут абстрагироваться от существования SQL и писать все на Ruby
* как при написании миграций: (http://www.oracle.com/technology/pub/articles/kern-rails-migrations.html, http://dizzy.co.uk/ruby_on_rails/cheatsheets/rails-migrations)
* так и для CRUDE операций: http://docs.huihoo.com/api/ruby-on-rails/classes/ActiveRecord/Base.html

Я вспоминаю SQL лишь иногда, когда вижу, что ActiveRecord не справляется с написанием эффективного запроса (но это обычно касается запросов, в котором задействовано 3 таблицы или более). Вообще ситуация, когда пишуться SQL запросы в RoR не считается нормальной, точнее, такие места нужно внимательно смотреть и чётко объяснять себе, почему я не воспользовался здесь конвенциальными средствами. SQL стараются не использовать, потому что
1) хочется, чтобы потенциально всё работало на разных драйверах БД (mysql, sqlite, postrgesql, oracle, ..), а себе в этом доверия нет
2) в ActiveRecord методы для CRUDE операций потенциально можно зашить разные модели масштабирования (master + N slaves, переключение между базами данных, кеширование, ..) и так и делают
3) потому вставки одного языка внутрь другого выглядят некрасиво, а красота, чёрт возьми, это страшная сила.

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

Когда-нибудь ты поймешь, что статическая типизация не мешает ни одному из приведенных тобой usecase'ов.

>> база --- как раз место, где статика очень слабо помогает. Переименовал одну таблицу --- и всё, никакой статический компилятор тебе не укажет
> Ещё как укажет. Регулярно приходится натыкаться на "invalid object" после изменений в ораклёвой БД. Именно по такому критерию -- табличка изменилась -- всё процедуры, с ней несовместимые, не компилятся.

Какие процедуры? Хранимые процедуры базы, написанные на pl/sql?

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

> Дай определение того, что ты понимаешь под статической типизацией.

Проверка типов на этапе компиляции.

> > Дай определение того, что ты понимаешь под статической типизацией.
> Проверка типов на этапе компиляции.
Блин :(

>>> Дай определение того, что ты понимаешь под статической типизацией.

>> Проверка типов на этапе компиляции.

> Блин :(

А что ты понимаешь под статической типизацией? O_o

> А что ты понимаешь под статической типизацией? O_o
В общем, примерно то же, что и ты. И что дальше? У любой типизации есть плюсы и минусы. А тема у нас про динамические и статические языки. Статический язык <> статическая типизация, вот это я и пытаюсь сказать. Видимо, без особого успеха. Поэтому и блин :(

> Статический язык <> статическая типизация

И что такое "статический язык" (или "динамический")?

>> Обращаю внимание на то, что в гомогенной среде нет разнородных частей, поэтому с ними не могут быть траблы.

> Ха! Три раза. Если ты не видел траблов с интеграцией различных частей, написанных на ОДНОМ языке - значит, не видел крупных проектов.

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

>> Попробуйте задействовать в Makefile функции для работы со строками и контейнерами, которые Вы написали в одной из своих C++ библиотек. Это в принципе невозможно.

> Ну уж и невозможно. В Makefile вполне нормальным приёмом является задействовать внешнюю утилиту, написанную на чём угодно - например, на плюсах. Лишь бы дёргалась через stdin/stdout.

Я писал про _функции_ из _библиотеки_. Я бы не хотел для каждой функции делать консольную утилитку. Например, гипотетическая библиотека string предоставляет функции -- downcase, strip, split, substr, gsub (глобальная замена по регулярному выражению), scan (поиск всех подстрок удолетворяющих регулярному выражению), ... Вы будете для каждой функции делать утилитку? Конечно нет! Вместо этого пробуете использовать cat, cut, awk, grep, ... Но иногда эти утилитки напрягают своей ограниченностью. Кроме того программист может не захотеть их использовать, потому что 1) не очень хорошо их все знает - их много, а он один, 2) код использующий эти таски будет нечитабельный, 3) ему нужна надёжная поддержка Unicode, 4) они OS-dependent, ...

Огромное количество виденных мной rake-tasks активно используют стандартную библиотку Ruby (классы String, Array, Time, ..). Я писал rake-таски и чувствовал выгоду от того, что не нужно писать как в Makefile цель, для которой вызывается внешний скрипт из 4-строчек на perl, - я эти 4 строки писал на Ruby прямо в описании цели и не было никакого разрыва "ткани кода", не нужно было превращать имеющиеся данные в удобный для (консольного приложения|внешнего скрипта) вид.

>Хранимые процедуры базы, написанные на pl/sql

В основном эти. Подозреваю, что то же с "view"ами -- не уверен, они "тут" реже используются. Могу завтра спросить подробности (не я натыкаюсь, а сосед:)

>> Хранимые процедуры базы, написанные на pl/sql
> В основном эти. Подозреваю, что то же с "view"ами -- не уверен, они "тут" реже используются. Могу завтра спросить подробности (не я натыкаюсь, а сосед:)

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

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

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

>Значит, alter table - это изменение класса в рантайме

Да ну! Приведёшь пример SQL-ориентированной БД, в которой класс(он же таблица) (number(4), varchar(5),...) обрабатывается кодом отличным от обрабатывающего (varchar(15), number(5),...)? Конечно, ничего невозможного, но скорее всего с т.з. сервера обе "таблицы" -- объекты одного и того же "типа". Разных было бы, если бы ты делал из таблицы индекс, например, или хотя бы "материализованное представление".

>Которая подразумевает, что мы останавливаем сервер, перекомпилируем его и запускаем заново

Думаешь, этого не происходит при "alter table"? Даю половину волос на отсечение, что на время "alter table" работа с изменяемой таблицей невозможна, по крайней мере при изменениях используемых полей. И наверняка после неё все запросы "перекомпилируются" и, возможно, перезапускаются. А если этого не происходит, то только потому, что "компилятор" достаточно умён, чтобы _доказать_ отсутствие влияния изменения на результаты выполнявшихся одновременно запросов.

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

Это называется "10е правило Гринспуна".

>Естественно, во всех этих случаях годятся только динамические языки.

А как же xmonad и yi?

>Я же подразумевал языки по другую сторону базы

Интересно, зачем proc/c++ конектится к БД (с этой стороны)?

>невозможно определить те строчки, в которых лежит sql-запрос

Это всего лишь означает проблемы с запросами, склеиваемыми из произвольных "строк", как, например, делают авторы сайтов, поддерживающих функциональность по имени "sql injection" :) Если же твои запросы формируются по более формальным правилам, то уже можно. Не вижу причин, по которым запросы, формируемые, например, HaskellDB не могут быть проверены на соответствие структуре БД во время сборки.

Итого, это не "невозможно" а "несовместимо с используемым API БД".

> Давай ты не будешь уподобляться Miguel'ю, и не будешь говорить про то, не знаешь/не пробовал/не понимаешь?

Нет, я буду об этом говорить, но аккуратно, со словами "кажется/..."

> Я вашу перепалку не читаю. Скучно-с...

Прочти именно тот пост.

> Значит, alter table - это изменение класса в рантайме.

да

> Тут люди утверждают, что динамические языки не нужны

да

> и изменение классов в рантайме не нужно,

нужно в редких случаях, о них мы сейчас и поговорим!

> а нужна статическая проверка типов.

да

> Которая подразумевает, что мы останавливаем сервер, перекомпилируем его и запускаем заново.

нет

1. Можно провернуть с классами тот же финт, который проворачивают в ФП с переменными, допуская их "изменять".

2. Даже сейчас можно спокойно менять класс на его наследник.

> Да ну! Приведёшь пример SQL-ориентированной БД, в которой класс(он же таблица) (number(4), varchar(5),...) обрабатывается кодом отличным от обрабатывающего (varchar(15), number(5),...)?

Учи матчасть. MS SQL:
select table tbl (id integer, name varchar(5))
....
declare @id int
select id from tbl into @id
...

В файрбёрде и оркале - примерно то же самое.
Ещё вопросы по этой теме есть?

> А как же xmonad и yi?
Loading your configuration

To get xmonad to use your new settings, type mod-q. (Remember, the mod key is 'alt' by default, but you can configure it to be something else, such as your Windows key if you have one.) xmonad will attempt to compile this file, and run it. If everything goes well, xmonad will seamlessly restart itself with the new settings, keeping all your windows, layouts, etc. intact.

Т.е., без перезапуска не обойтись. Именно то, о чём я и говорил.

> Даю половину волос на отсечение, что на время "alter table" работа с изменяемой таблицей невозможна, по крайней мере при изменениях используемых полей. И наверняка после неё все запросы "перекомпилируются" и, возможно, перезапускаются

Только вот не надо двойных стандартов. В это время возможна работа С ОСТАЛЬНЫМИ ТАБЛИЦАМИ. Выполняющиеся в данный момент запросы, не затронутые изменением, не прерываются.
А если запрос может быть затронут, то возможны варианты:

- либо выполнение alter встанет в очередь и "подвиснет" до того момента, как мешающий запрос завершится;

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

Это я писал о том, как сделать "параллельно лиспу", однако все же более мейнстрим -- тормозить аппликухи (а SQL сервер при этом продолжает работать), менять классы на сервере, перекомпилировать аппликухи, запускать аппликухи.

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

Менять -- это бред. Вот если написать "расширить", то это да, полезно.

> Зачем хеши конвертировать? Там ничего не должно измениться.

Ты явно не понял моего вопроса. Был хэш {... person=>'Vasya Pupkin' ...}, стал хэш {... name=>'Vasya', fname=>'Pupkin' ...}, так что конвертация нужна.

> Менять -- это бред. Вот если написать "расширить", то это да, полезно.
А с тебя я всё ещё жду пример, как разбоксить в С++

> Только вот не надо двойных стандартов. В это время возможна работа С ОСТАЛЬНЫМИ ТАБЛИЦАМИ. Выполняющиеся в данный момент запросы, не затронутые изменением, не прерываются.

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

> А с тебя я всё ещё жду пример, как разбоксить в С++

Потом как-нибудь. Там все ясно, и мне скучно.

А вот сейчас ты поднял интересный вопрос совместимости статики с MOP -- за MOP, для простоты, примем sql-евский alter table. Мой пойнт в том, что статическая проверка типов совместима с МОР, вопреки тому, что ты доказываешь.

> Я писал rake-таски и чувствовал выгоду от того, что не нужно писать как в Makefile цель, для которой вызывается внешний скрипт из 4-строчек на perl, - я эти 4 строки писал на Ruby прямо в описании цели и не было никакого разрыва "ткани кода",

и это прямо сильно удобнее makefile-тасков, для которых вызывается внешний скрипт из 4-строчек на руби?

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

> Читай, пожалуйста внимательнее.

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

> разнородных частей в гомогенном софте нет.

Да ну??? В любом крупном проекте есть разнородные части. Или у тебя "разнородность" подразумевает исключительно языковую? Тогда объясняй, почему это вызывает дополнительные проблемы. Ключевое слово "дополнительные" - т. е., проблемы, которых в случае, когда используется один язык, не было бы.

> Я писал rake-таски и чувствовал выгоду от того, что не нужно писать как в Makefile цель, для которой вызывается внешний скрипт из 4-строчек на perl

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

Впрочем, это всё говорильня. Я пока не видел ни одного крупного проекта, который был бы полностью гомогенным. ВЕЗДЕ используются разные языки для разных задач.

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

> (E)DSL-подход (а я бы это рекомендовал всем), то гетерогенным проект станет просто по определению.

Именно Edsl меня больше всего интересует.

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