> Что тут доверять - взяли, язык подлатали: был long(*)(long) - т.е указатель на функцию, но для нужд буста сделали новый тип long(long), т.е тип "функция в натуре" и compile-time средства для анализа этого типа. Это скорее к вопросу о неограниченной расширяемости языка с помощью шаблонов: не получается шаблончег - пиши патч к g++.

Еще в С были вольности типа функция/указатель на функцию. Так что это не для буста сделали.

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

>Александреску изобретал телеги

потому, что и сейчас нет компилятора, который бы полностью поддерживал стандарт 98(2003) года. А в то время даже ограниченной поддержкой стандарта мало кто мог похвастаться.

>Loki::Functor<long, LOKI_TYPELIST_1(long)> видимо оттого что плохо знал Стандарт.

Или из-за того, что LOKI_TYPELIST_1 может быть заменен на LOKI_TYPELIST_2, 3 и т.д.

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

ЛОЛ детка, меня конечно очень волнует что ты там считаешь глупым. Просто спать ночью не смогу.

>Я хотел помягче сказать, но видимо придется выдать первоначальный вариант: это не я шифруюсь, это ты гуглить не умеешь.

Ну и что там такого нагуглилось? Ничего способного подкрепить такое непомерное ЧСВ не вижу...

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

>Ну вот как раз Лисп мультипарадигменый язык, и много нужной функциональности поддерживаются им напрямую. Да, я считаю, что функции должны быть ферст класс ситизенами и у тебя не получится меня переубедить :) А КЛОС входит в стандарт и никаких сторонних билиотек для использования ООП инклудить не требуется.

lisp функциональный язык ? функции являются ферст класс ситизенами?
сколько атомов содержится в функции 1 (представленной символом 1)?

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

Ну синтаксическое дерево по сути никому не сдалось. Синтаксис виден и в исходном тексте программы. Речь идёт именно о СЕМАНТИЧЕСКИХ средствах разработки, то есть тут важно понять не только, правильно ли компилятор обработал синтаксис, важно именно убедиться в семантике - что компилятор понял именно то что вы подразумевали.

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

>И ? Возразили ? Легче стало ? Хотите поговорить об этом ? Это что то вроде синонима - попердеть в лужу ?

Вы очень несдержаны. Пердите в лужу здесь именно Вы.

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

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

>Это желание от языка не зависит вообще.

Вы ещё забыли сказать "я гарантирую это". Откуда такая уверенность?

>Скорее всего ты тупишь и не догоняешь простейших вещей.

Скорее всего Вы не умеете аргументировать свои слова.

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

Ты это уже прочитал?

http://www.linux.org.ru/view-message.jsp?msgid=3076729&page=17#3096174

Код не только человеку обрабатывать надо, но и программно. Ты не понимаешь, зачем это надо?

> Вот-вот. То есть программисту приходится сверять своё понимание программы с пониманием программы компилятором. Это говорит о крайней сложности и неочевидности определённых средств языка.

Нет, блин, тупица. Не "сверять", а использовать эту информацию для обработки кода.

> Вы ещё забыли сказать "я гарантирую это". Откуда такая уверенность?

Оттуда, что ты дебил. Я же тебе сказал - всё это есть (и очень активно используется) в настоящих, правильных языках - в Лиспе, в Хаскелле, в ML. Это есть в C# и в Java. И польза от доступности синтаксиса и семантики в программночитаемом виде огромна. Ты, как дебильному недоумку и полагается, просто поскипал всё, что я написал (вероятно, ты этого даже и не понял, ибо кретин). Повторю - это полнотекстный анализ кода (как пример - построение графа вызовов, автоматическое доказательство, и т.п.), это внешние оптимизации, это умная поддержка разработки в IDE (тот же intellisence).

> Скорее всего Вы не умеете аргументировать свои слова.

Это говорит кретин, тупо проскипавший все аргументы...

А, дошло, ты не понял, что такое верификация кода...

Ну, сюда хотя бы сходи: http://why.lri.fr/

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

> Я же тебе сказал - всё это есть (и очень активно используется) в настоящих, правильных языках - в Лиспе, в Хаскелле, в ML. Это есть в C# и в Java. И польза от доступности синтаксиса и семантики в программночитаемом виде огромна. Ты, как дебильному недоумку и полагается, просто поскипал всё, что я написал (вероятно, ты этого даже и не понял, ибо кретин). Повторю - это полнотекстный анализ кода (как пример - построение графа вызовов, автоматическое доказательство, и т.п.), это внешние оптимизации, это умная поддержка разработки в IDE (тот же intellisence).

Мне очень нравится вот это высказывание анонимуса: http://www.lorquotes.ru/view-quote.php?id=2411 . Как раз на тему того, зачем нужна доступность синтаксиса и семантики в машинночитаемом виде.

> http://www.lorquotes.ru/view-quote.php?id=2411 . Как раз на тему того, зачем нужна доступность синтаксиса и семантики в машинночитаемом виде.

Ты крепко не прав, если экстраполируешь опыт Явы.

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

>> http://www.lorquotes.ru/view-quote.php?id=2411 . Как раз на тему того, зачем нужна доступность синтаксиса и семантики в машинночитаемом виде.

> Ты крепко не прав, если экстраполируешь опыт Явы.

Так прав или неправ?

>> Ты крепко не прав, если экстраполируешь опыт Явы.

> Так прав или неправ?

Не прав. Мощная IDE не помешает любому языку - как убогой Яве, так и могучему Хаскелю.

Ты, как обычно, проигнорировал всё, кроме поддержки IDE (что есть полезная, но далеко не самая важная фича). Наверное, ты дурак?

>Мне очень нравится вот это высказывание анонимуса: http://www.lorquotes.ru/view-quote.php?id=2411 . Как раз на тему того, зачем нужна доступность синтаксиса и семантики в машинночитаемом виде.

Это высказывание анонимуса по поводу "многословного раздутого говна", возможно даже в большей степени, относится и к С++. Только в С++ рефакторингов, автокомплишенов и код-инспекшена нет.

> Только в С++ рефакторингов, автокомплишенов и код-инспекшена нет.

"Поздравляю вас, гражданин, соврамши" (c)

>> Только в С++ рефакторингов, автокомплишенов и код-инспекшена нет.

>"Поздравляю вас, гражданин, соврамши" (c)

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

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

> Ты, как обычно, проигнорировал всё, кроме поддержки IDE (что есть полезная, но далеко не самая важная фича). Наверное, ты дурак?

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

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

> Оно тормозно/ненадежно/пропиеритарно/появилось слишком поздно/требует отдельного мэйнтейненса/итд.

У тебя есть цитатник типа этого: http://naxren.ru/read/3188-kakuju-mashinu-vybrat-.html ?

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

> Не прав. Мощная IDE не помешает любому языку - как убогой Яве, так и могучему Хаскелю.

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

> Назови мне такую фишку ide, которая

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

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

И вообще - что за максимализм? Тебе нужно обязательно 100%-решение, 80% не подходит?

> нужна гипотетическому всемогущему языку

Прежде всего, этому языку не нужен прогер :D

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

>> Назови мне такую фишку ide, которая

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

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

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

> И вообще - что за максимализм? Тебе нужно обязательно 100%-решение, 80% не подходит?

Не подходит. Потому что для всех восьмидесятипроцентных решений достаточно sed+grep.

>> Ну, например, переименование переменной в Яве можно корректно сделать всегда.

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

Причем тут рефлексия вообще? Речь шла о том, зачем необходим AST с типовой информацией.

>> И вообще - что за максимализм? Тебе нужно обязательно 100%-решение, 80% не подходит?

> Не подходит.

Тогда ой.

> Потому что для всех восьмидесятипроцентных решений достаточно sed+grep.

Ой, правда? Напиши CDT 3.x (типичное 80% решение) на sed и grep.

>> Оно тормозно/ненадежно/пропиеритарно/появилось слишком поздно/требует отдельного мэйнтейненса/итд.

>У тебя есть цитатник типа этого: http://naxren.ru/read/3188-kakuju-mashinu-vybrat-.html ?

Нет, по моему любой язык отличный от С++ в принципе можно считать неговном. Даже брейнфак неговно потому что что под него можно сделать интерпретатор длиной 400 байт и в коде можно рисовать сиське и попке.

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

>>> Ну, например, переименование переменной в Яве можно корректно сделать всегда.

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

> Причем тут рефлексия вообще? Речь шла о том, зачем необходим AST с типовой информацией.

При том, что если есть что-то вроде reflection.getField("prefix"+"Name"+"Suffix") , то переменную prefixNameSuffix ты не сможешь автоматически переименовать.

>> Потому что для всех восьмидесятипроцентных решений достаточно sed+grep.

> Ой, правда? Напиши CDT 3.x (типичное 80% решение) на sed и grep.

Я, видимо, непонятно выразился: Тот же эффект достигается грепаньем и седом. В любом случае чтобы не сделать фигню придётся применить мозг.

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

>>> Оно тормозно/ненадежно/пропиеритарно/появилось слишком поздно/требует отдельного мэйнтейненса/итд.

>>У тебя есть цитатник типа этого: http://naxren.ru/read/3188-kakuju-mashinu-vybrat-.html ?

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

То есть твой Цитатник сводится к нижеприведённому алгоритму?

govno = lang.getName().startsWith("C++");

Да легко - показывать тип любого выражения, выбранного пользователем. Рисовать dataflow - он может быть нетривиальным в любом языке. Семантический поиск - как регулярные выражения, но по конструкциям языка, а не по их текстовому отображению. Прыгать по определениям сущностей и получать список всех мест, где на сущность ссылаются. Изменение имени везде, где оно используется, изменение типа, и прочие типичные для рефакторинга действия. Это самое примитивное, есть ещё десятки других полезных вещей, которые можно делать при наличии доступа к типизированному AST.

>> Причем тут рефлексия вообще? Речь шла о том, зачем необходим AST с типовой информацией.

> При том, что если есть что-то вроде reflection.getField("prefix"+"Name"+"Suffix") , то переменную prefixNameSuffix ты не сможешь автоматически переименовать.

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

>>> Потому что для всех восьмидесятипроцентных решений достаточно sed+grep.

>> Ой, правда? Напиши CDT 3.x (типичное 80% решение) на sed и grep.

>Я, видимо, непонятно выразился: Тот же эффект достигается грепаньем и седом

Какой "тот же"? Ты будешь sed и grep искать тип символа "someptr", чтобы после "someptr->" выдать список полей?

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

>> При том, что если есть что-то вроде reflection.getField("prefix"+"Name"+"Suffix") , то переменную prefixNameSuffix ты не сможешь автоматически переименовать.

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

Ну то есть ты сам уже показал, что придётся использовать устройство /dev/brain, чтобы разобраться, входит изменяемый объект в API или нет. Т.е., возвращаясь вверх по ветке дискуссии: "нет, нельзя просто так переименовать любую переменную в жабе".

> Какой "тот же"? Ты будешь sed и grep искать тип символа "someptr", чтобы после "someptr->" выдать список полей?

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

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

> Да легко - показывать тип любого выражения, выбранного пользователем.

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

> Рисовать dataflow - он может быть нетривиальным в любом языке.

Это не разновидность ли той самой неразрешимой задачки с обоснованием корректности алгоритма?

> Семантический поиск - как регулярные выражения, но по конструкциям языка, а не по их текстовому отображению.

(i/2), (int)(i/2.0), i>>1 -- эквивалентные конструкции для целого i. Их семантический поиск найдёт?

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

с рефлексией не сработает.

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

Но не в 100% случаев. чтд.

> Ну то есть ты сам уже показал, что придётся использовать устройство /dev/brain

Вопрос в том, _для чего_ используется /dev/brain. Одно дело, когда он используется для вспоминания "является ли эта переменная частью API, к которой обращаются по рефлексии"; другое дело, когда он используется для управления пальцами при вводе диалога Search/Replace.

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

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

Впрочем, если тебе нужно официальное заявление о том, что статический анализ программ не всесилен, вот оно: "статический анализ программ не всесилен".

>> Какой "тот же"? Ты будешь sed и grep искать тип символа "someptr", чтобы после "someptr->" выдать список полей?

> Ну а как жили люди до intellisense?

А как они жили до компьютеров? А до канализации? А до огня? Без Intellisense можно обойтись, но если он есть - глупо им не пользоваться, потому что он облегчает жизнь.

> Поднимаешь глаза вверх до определения переменной, смотришь её тип, открываешь соответствующий хедер и достаёшь имена полей из него. На языке грепоседа, надеюсь, это переписывать не надо?

Не надо. Уже понятно, что специальная программа, обрабатывающая AST, справится намного лучше.

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

Это на каком языке ты заметил?

> Только для типизированных языков.

Нетипизированные не интересны.

> И, как я заметил, с увеличением мощности языка у него типизировалка потихоньку отсыхает.

Редкостная чушь. Ни хера ты про языки не знаешь. Почитывал бы LtU почаще, что ли.

> Это не разновидность ли той самой неразрешимой задачки с обоснованием корректности алгоритма?

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

> (i/2), (int)(i/2.0), i>>1 -- эквивалентные конструкции для целого i. Их семантический поиск найдёт?

Найдет, конечно же. Приведением к нормальной форме.

> с рефлексией не сработает.

Как ты надоел со своей быдлорефлексией. Рефлексия - только для API. Элементы API должны строго специфицироваться (в системе типов должны быть для этого возможности), тогда и IDE не даст тебе сделать глупость. В очередной раз убеждаюсь в невменяемости любителей динамических языков и прочих утководов.

> Но не в 100% случаев. чтд.

В 100% случаев, дурак. Для того и нужна строгая типизация.

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

В реальном мире всегда выигрывает язык типа похапе, жабы или пистона, позволяющем писать небрежно. На Си и Лиспе - гениально небрежно. На С++ была предпринята попытка заставить писать аккуратно с диаметрально противоположным результатом.

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

Рефлексия нарушает инкапсуляцию и поэтому должна быть жестко ограничена (хинт: примерно так же, как ограничено использование приватных членов). Конкретные правила следует придумать.

А подстановка поля abcd в myvar.abcd (или myptr->abcd) по первой букве a вещь безусловно полезная, sed+grep тут уже не помогут.

Дополнительно:

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

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

> На С++ была предпринята попытка заставить писать аккуратно с диаметрально противоположным результатом.

И она провалилась из-за 3 причин:

1. плохого синтаксиса

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

3. невозможности выделить из плюсов "безопасный урезанный язык", типа как в C# управляемый код, где указатели не видны.

"выделить" я имел в виду "выделить с помощью компилятора", а не просто дисциплины "низзя (void*)"

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

Жаба не позволяет писать небрежно -- она все же дисциплинирует, но достигается это офигенным пустым многословием:

Window window = new Window(...);

PHP и Python ИМХО популярны из-за отсутствия этого многословия, но зато и дисциплины нет.

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

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

Программа и внутри себя может сломаться.

> Впрочем, если тебе нужно официальное заявление о том, что статический анализ программ не всесилен, вот оно: "статический анализ программ не всесилен".

Отлично. Посему я предпочитаю язык с удобным синтаксисом языку с мощным косты^W IDE.

> Без Intellisense можно обойтись, но если он есть - глупо им не пользоваться, потому что он облегчает жизнь.

А если его нет -- то его отсутствие не настолько сильно портит жизнь, чтобы потребовалось его написать.

> Не надо. Уже понятно, что специальная программа, обрабатывающая AST, справится намного лучше.

Если она уже есть :)

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

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

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

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

Но увы, я уже натрахался с "революционными" подходами на триста лет вперёд, потому хотелось бы видеть обоснование.

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

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

> Это на каком языке ты заметил?

lisp(всё есть список), tcl(всё есть строка)

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

>> (i/2), (int)(i/2.0), i>>1 -- эквивалентные конструкции для целого i. Их семантический поиск найдёт?

> Найдет, конечно же. Приведением к нормальной форме.

Оп-ля, у нас уже появилась нормальная форма для кода? Ссылку!

>> с рефлексией не сработает.

> Как ты надоел со своей быдлорефлексией. Рефлексия - только для API. Элементы API должны строго специфицироваться (в системе типов должны быть для этого возможности), тогда и IDE не даст тебе сделать глупость.

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

Да, и ещё: это последний ответ, данный на хамский пост.

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

> Программа и внутри себя может сломаться.

Если программа внутри себя использует рефлексию - это 2 (или больше) программы в одной :)

>> Впрочем, если тебе нужно официальное заявление о том, что статический анализ программ не всесилен, вот оно: "статический анализ программ не всесилен".

>Отлично. Посему я предпочитаю язык с удобным синтаксисом языку с мощным косты^W IDE.

Ыыыы.... причемтутваще синтаксис?

>> Без Intellisense можно обойтись, но если он есть - глупо им не пользоваться, потому что он облегчает жизнь.

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

Ну да, его от безделья написали (причем много раз).

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

>> Это на каком языке ты заметил?

> lisp(всё есть список), tcl(всё есть строка)

Ну-ну, и когда последний раз увеличивалась мощь тикля как языка? А Лиспа - он увеличил свою мощь с появлением Qi? :D

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

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

> В реальном мире всегда выигрывает язык типа похапе, жабы или пистона, позволяющем писать небрежно. На Си и Лиспе - гениально небрежно. На С++ была предпринята попытка заставить писать аккуратно с диаметрально противоположным результатом.

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

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

> Если программа внутри себя использует рефлексию - это 2 (или больше) программы в одной :)

И что мне теперь, программу с ORM считать за n+1(n>=0) ? :)

>>Отлично. Посему я предпочитаю язык с удобным синтаксисом языку с мощным косты^W IDE.

> Ыыыы.... причемтутваще синтаксис?

Ладно, выражусь попроще: "удобный язык".

>>> Без Intellisense можно обойтись, но если он есть - глупо им не пользоваться, потому что он облегчает жизнь.

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

> Ну да, его от безделья написали (причем много раз).

Почему безделья? Как будто бы мало тулов на продажу пишут.

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

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

Так тебе надо в рамках эволюции одного языка? Увы, примеров ни этого, ни обратного, не знаю. Я взял все языки в кучу и ввёл там частичный порядок.

> Рефлексия -- она и для удобства написания dsl.

Чушь.

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

Говно твой гибернейт. Статическое метапрограммирование гораздо эффективнее любой сраной рефлексии в рантайме.

>> Если программа внутри себя использует рефлексию - это 2 (или больше) программы в одной :)

> И что мне теперь, программу с ORM считать за n+1(n>=0) ? :)

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

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

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

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

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

> Говно твой гибернейт. Статическое метапрограммирование гораздо эффективнее любой сраной рефлексии в рантайме.

Собственно рефлексия и класслоадер в яве -- это такое метапрограммирование в рантайме <flame>для бедных</flame>.

Мое мнение -- рефлексия тоже должна делаться через метапрограммирование.

> lisp(всё есть список), tcl(всё есть строка)

Я это ценю, называю консистентностью, и статической типизации это не противоречит.

(Причем лисповская консистентность мне нравится намного больше тиклевской)

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