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

> Ложь. Ты говоришь об "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. И индустрия была бы гораздо более продвинутой, чем она есть, либо столь же продвинутой, но за меньшие деньги. Дальше я не буду говорить "а вот если бы вместо плюсов люди пользовались лиспом", т.к. история не имеет сослагательного наклонения, у лиспа есть свои недостатки, и есть ещё вопрос собственности на сорсы. Но, начиная любую крупную разработку на статическом языке, нужно понимать, что на будущее вы программируете себе задачу создания/привязывания динамического языка.

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

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

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

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

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

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

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

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

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

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

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

> Блин :(

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

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

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

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

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

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

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

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

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

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

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

А как же xmonad и yi?

> Значит, 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 сервер при этом продолжает работать), менять классы на сервере, перекомпилировать аппликухи, запускать аппликухи.

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

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

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

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

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

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

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

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

>Учи матчасть ... select table tbl (id integer, name varchar(5))

И что? Почему это разные классы с т.з. исходников сервера (выше говорилось про необходимость перекомпилить оный при alter table)?

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

Ээ нет!! Ты говорил, что "Никто не поймет, если нужно будет перезапускать". А вот же, перекомпилируют статический язык, перегружают целиком или модулями, и друг друга понимают :)

>В это время возможна работа С ОСТАЛЬНЫМИ ТАБЛИЦАМИ

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

Резюме -- в этом месте динамизм ни при чём -- нужно просто предусматривать правильную реакцию на разные внешние события -- будь то блокировка или перезапуск.

> Ээ нет!! Ты говорил, что "Никто не поймет, если нужно будет перезапускать". А вот же, перекомпилируют статический язык, перегружают целиком или модулями, и друг друга понимают :)

Во-первых, это просто один из миллиона других оконных менеджеров. Может быть, он вообще плохой. Откуда мне знать? Во-вторых, я не говорил, что динамизм нужен _всегда_. Я говорил, что он просто нужен, отвечая на вопрос темы. А вопрос был о том, нужен ли динамизм хоть когда-то. С моей точки зрения, я привёл достаточно хороший пример, когда он нужен.
Мы перебрали при этом не все возможные варианты использования динамизма в SQL и не все возможные варианты его реализации. Например, я почти уверен, что многие варианты alter table в реальных серверах можно делать одновременно с работающими на этой таблице запросами.

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

Ладно, на следующей неделе я на форумы не хожу, разве только доделаю одну тему на comp.lang.lisp.

Всего хорошего!

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

А я не говорил, что не нужен. Я говорил, что в приведенных примерах его "предпочтительность" не так уж очевидна. Может это просто примеры "плохие"?

>Если упереться рогом и снизить качество решения, затруднив при этом эксплуатацию

Вот же ж. Показано, что "затруднения эксплуатации" вызваны не "статичностью средств", а "непродуманностью особенностей". Можно сделать "полную перегрузку" с меньшими последствиями, чем "сброс кеша" (наблюдал), причём первое намного проще реализуется (YMMV). Кроме того, "остановка/апдейт/запуск" даёт только "несколько" _гарантированных_ отказов. IMO это намного лучше постоянного потока случайных отказов от "неблокирующего" режима. Не говоря уже об "неизвестном" состоянии в случае больших апдейтов в распреденённых системах c таймаутами. Начальство любит предсказуемость:)

> Учи матчасть. MS SQL: > select table tbl (id integer, name varchar(5))

create table

> declare @id int > select id from tbl into @id

select @id = id from tbl