Re^14: Страуструп о будущем семантических средств разработки с комментариями

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

Ну вот возьмём тот же гибернейт, на который так фростно среагирвал анонимный хам: гораздо нагляднее писать запросы в виде "from TableClass t where t.name = ?1", нежели "from "+TableClass.class.getSimpleName()+" t where t."+TableClass.class.t.class.getSimpleName()+" = ?1". А уж если вынести для красоты запрос в отдельный файл, то второй вариант вообще неприменим.

>> Так тебе надо в рамках эволюции одного языка?

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

Ну такого примера я не знаю. Кстати, а та типизировалка, отросшая у лиспа, весь лисп типизирует или только его объектную часть?

Re^12: Страуструп о будущем семантических средств разработки с комментариями

> * и статической типизации это не противоречит, несмотря на то, что используется чаще всего без таковой

А точно не противоречит? (опять возвращаюсь к тебе обоснования столь сладких для меня высказываний)

> гораздо нагляднее писать запросы в виде "from TableClass t where t.name = ?1", нежели "from "+TableClass.class.getSimpleName()+" t where t."+TableClass.class.t.class.getSimpleName()+" = ?1". А уж если вынести для красоты запрос в отдельный файл, то второй вариант вообще неприменим.

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

> та типизировалка, отросшая у лиспа, весь лисп типизирует или только его объектную часть?

Я не великий спец по CL, но, насколько я понимаю, весь Лисп. Т.е. в любой функции можно задать ограничения на тип аргументов.

Re^16: Страуструп о будущем семантических средств разработки с комментариями

>> гораздо нагляднее писать запросы в виде "from TableClass t where t.name = ?1", нежели "from "+TableClass.class.getSimpleName()+" t where t."+TableClass.class.t.class.getSimpleName()+" = ?1". А уж если вынести для красоты запрос в отдельный файл, то второй вариант вообще неприменим.

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

Ну вот ты видишь запрос в виде строки(java.lang.String)? Расскажи мне, как умный IDE должен поступать, дабы при переименовании класса он обновил и эту строку?

>> та типизировалка, отросшая у лиспа, весь лисп типизирует или только его объектную часть?

> Я не великий спец по CL, но, насколько я понимаю, весь Лисп. Т.е. в любой функции можно задать ограничения на тип аргументов.

Гуд. Осилить что ли лисп? ;)

> Гуд. Осилить что ли лисп? ;)

но tk-шный синтаксис все же поприятней, чем у лиспа :-) я понимаю, что это субъективно

> Ну вот ты видишь запрос в виде строки(java.lang.String)? Расскажи мне, как умный IDE должен поступать, дабы при переименовании класса он обновил и эту строку?

Тут имеется интересная гораздо более общая проблема -- в яве нет alter class, аналога sql ALTER TABLE.

>>> гораздо нагляднее писать запросы в виде "from TableClass t where t.name = ?1", нежели "from "+TableClass.class.getSimpleName()+" t where t."+TableClass.class.t.class.getSimpleName()+" = ?1". А уж если вынести для красоты запрос в отдельный файл, то второй вариант вообще неприменим.

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

> Ну вот ты видишь запрос в виде строки(java.lang.String)? Расскажи мне, как умный IDE должен поступать, дабы при переименовании класса он обновил и эту строку?

Ты задаешь вопросы, на которые должны отвечать специалисты :) Примерная схема такова: просматривается AST, и отыскивается, откуда искомые строки получают значения. Если все источники значений содеражтся в проекте (не программе - именно проекте, который может включать в себя БД, определения запросов, тесты API), задача решена. Ну а если нет, то нет :D

Ага, обращение к проекту делает наш AST чем-то большим, чем просто "AST программы на Яве".

> Гуд. Осилить что ли лисп? ;)

Лисп за пределами SICP или там Zen-style programming осиливать незачем - практической пользы всё равно не будет. ИМХО, осиливать лучше Haskell/Ocaml/F#. Ну или Scala.

Re^18: Страуструп о будущем семантических средств разработки с комментариями

>> Ну вот ты видишь запрос в виде строки(java.lang.String)? Расскажи мне, как умный IDE должен поступать, дабы при переименовании класса он обновил и эту строку?

> Ты задаешь вопросы, на которые должны отвечать специалисты :) Примерная схема такова: просматривается AST,

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

Собсно, вот это место мне нравится больше всего. Априори,это сделать нельзя.
Поэтому, наверно, программу с ORM всё же, согласно твоей логике, надо рассматривать как две различнцых программы :)

> Если все источники значений содеражтся в проекте (не программе - именно проекте, который может включать в себя БД, определения запросов, тесты API), задача решена. Ну а если нет, то нет :D

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

> Собсно, вот это место мне нравится больше всего. Априори,это сделать нельзя.

Если в программе достаточно тестов - можно.

> Поэтому, наверно, программу с ORM всё же, согласно твоей логике, надо рассматривать как две различнцых программы :)

И при объединении информации, полученной из двух этих программ, мы получаем искомое - переименование со 100% надежностью :)

> Лисп за пределами SICP или там Zen-style programming осиливать незачем - практической пользы всё равно не будет.

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

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

Так что, как минимум в объёме "Practical Common Lisp" его постичь надо каждому.

Re^20: Страуструп о будущем семантических средств разработки с комментариями

>> Собсно, вот это место мне нравится больше всего. Априори,это сделать нельзя.

> Если в программе достаточно тестов - можно.

Это уже подмена "сделать безошибочно" на "сделать и проверить, не поломалось ли".

>> Если в программе достаточно тестов - можно.

> Это уже подмена "сделать безошибочно" на "сделать и проверить, не поломалось ли".

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

Re^22: Страуструп о будущем семантических средств разработки с комментариями

>>> Если в программе достаточно тестов - можно.

>> Это уже подмена "сделать безошибочно" на "сделать и проверить, не поломалось ли".

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

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

>> Лисп за пределами SICP или там Zen-style programming осиливать незачем - практической пользы всё равно не будет.

> Вот это ты зря.

Может быть. Я не любитель Лиспа, мягко говоря.

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

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

> именно Лисп лучше всех подходит для первоначального ознакомления с этой важнейшей концепцией.

И чем для этого плоха Схема?

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

Мне не кажется, что можно выучить идиоматический Лисп, не программируя на нем, причем программировать нужно достаточно много.

> как минимум в объёме "Practical Common Lisp" его постичь надо каждому.

_Practical_ Common Lisp. Нет у меня практики на Лиспе, да и не хочу я учить CL - он типа для промышленного программирования, с кучей библиотек (из которых, по слухам 50% нужно выкинуть). Для меня Схема в роли учебного Лиспа - самое то.

> И чем для этого плоха Схема?

Тем, что книг и туториалов нет, а вот про CL - есть.

> Мне не кажется, что можно выучить идиоматический Лисп, не программируя на нем, причем программировать нужно достаточно много.

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

> _Practical_ Common Lisp.

Ну так это же хорошо - примеры не абстрактные, а вполне конкретные.

> Для меня Схема в роли учебного Лиспа - самое то.

Схема хороша. Если бы ещё хорошие книги для более продвинутого уровня были к ней.

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

> Ну тогда это замена шила на мыло :)

Замена динамической проверки на статическую.

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

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

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

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

Слишком "заплатное" решение. Но работать будет, да.

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

В общем, да, но достичь момента можно на Схеме или там Немерле. Проблема в том, что тащить концепцию некуда :(

Почему же? Решение как раз в духе жесткой статической типизации. Если что-то является элементом интерфейса, экспортируемым или как функция в библиотеке для других приложений, или через рефлексию - то, очевидно, к этому чему-то должно быть особое отношение со стороны IDE, компилятора, систем автодокументирования, программистов и пользователей. Более чем достаточно оснований для формального выделения этого дела в особую сущность.

Ну, во первых, никто не мешает и в практике программировать на Схеме или Лиспе. Во вторых, тащить можно даже в C++, поскольку внешние препроцессоры могут давать результаты не хуже, чем истинное метапрограммирование. Для той же Java есть тулкиты для метапрограммирования, для языков .NET, для Питона, для Руби...

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

Против "особого отношения" я и не возражаю, но запреты мне не нравятся (особенно необоснованные, ИМХО).

> Ну, во первых, никто не мешает и в практике программировать на Схеме или Лиспе.

Кому как.

> но запреты мне не нравятся

И этот человек поет диферамбы статически типизированным языкам?!?

Запрет на изменение интерфейса (пусть даже не запрет, а предупреждение) более чем обоснован.

> Кому как.

Ну вот, лично мне, например, ничто не мешает. А что мешает тебе?

>> но запреты мне не нравятся

> И этот человек поет диферамбы статически типизированным языкам?!?

Ога. Там же было про необоснованность запрета.

> Запрет на изменение интерфейса (пусть даже не запрет, а предупреждение) более чем обоснован.

Предупреждение - конечно, запрет - никоим образом.

> А что мешает тебе?

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

> Ога. Там же было про необоснованность запрета.

Скажем так, запрет должен сниматься определенными ритуальными действиями - например, сменой номера версии интерфейса, с автодокументированием изменений между двумя версиями.

Я вообще людям не доверяю. В том числе и себе.

> Отсуствие квалифицированных кадров

Места надо знать.

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

Если их использовать исключительно как макропроцессоры для языков статически типизированных - то это не беда.

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

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

>Запрет на изменение интерфейса (пусть даже не запрет, а предупреждение) более чем обоснован.

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

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

Это слишком жестко и не покатит. Рассмотрим Яву. Допустим, мы делаем свою систему сериализации любых объектов (ну, или подобъектов MyObject). Тогда нам нужна рефлексия на всех объектах. И значит -- полное отключение рефакторинга в самом интересном месте...

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

Или вообще, что нефиг метапрограммированием заниматься в ран-тайм.

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

Правильно:

При наличии конструкций языка, не отдающих значение (т.е. в не функциональных языках), дело МОЖЕТ усложниться необходимостью понимания структуры AST,

> И при объединении информации, полученной из двух этих программ, мы получаем искомое - переименование со 100% надежностью :)

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

> Слишком "заплатное" решение. Но работать будет, да.

Самый интересный случай будет, когда нам рефлексия нужна во всех классах :-)

> Для той же Java есть тулкиты для метапрограммирования, для языков .NET, для Питона, для Руби...

Кинь ссылки на наиболее популярные, если ты действительно этим интересовался. Если нет - то не надо.

Для Java:

http://www.kimbly.com/code/jatha/

http://www.eclipse.org/aspectj/

Питон и Руби - из коробки.

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

> Допустим, мы делаем свою систему сериализации любых объектов (ну, или подобъектов MyObject). Тогда нам нужна рефлексия на всех объектах.

Для сериализации рефлексия не нужна. Для сериализации нужно статическое метапрограммирование - то есть, конечно же, рефлексия атрибутов и структур (для генерации кода сериализации), но не рефлексия на инстансах объектов.

> Кстати, это можно рассматривать как аргумент того, что нужна ослабленная форма рефлексии -- без имен.

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

>> Допустим, мы делаем свою систему сериализации любых объектов (ну, или подобъектов MyObject). Тогда нам нужна рефлексия на всех объектах.

>Для сериализации рефлексия не нужна. Для сериализации нужно статическое метапрограммирование - то есть, конечно же, рефлексия атрибутов и структур (для генерации кода сериализации), но не рефлексия на инстансах объектов.

Ты в цитате убрал "Рассмотрим Яву.". А вообще мне хочется всю рефлексию заменить статическим метапрограммированием. Однако есть место, где могут потребоваться имена -- это встроенный отладчик...

> Если их использовать исключительно как макропроцессоры для языков статически типизированных - то это не беда.

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

> Ты в цитате убрал "Рассмотрим Яву."

Ну. Рассмотрим. Apache BCEL рулит и жжот.

> А вообще мне хочется всю рефлексию заменить статическим метапрограммированием.

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

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

Который тоже можно разворачивать статически во время компиляции, как я делаю всегда с Лиспом.

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

Пока что таких не наблюдается. Что Nemerle, что MetaOCaml, что Template Haskell, что Converge - все весьма сложны, в сравнении с тупым quasiquote в Лиспе.