Здравствуйте, Sinclair, Вы писали:
СГ>>А вот шаблонов нет, то есть шаблоны не увеличивают возможностей программы. S>Вот это вообще бред. Все возможности программы были внятно описаны еще до второй мировой войны. Ты с тезисом Черча знаком? Так вот никакие техники программирования, известные на данный момент, ничего не добавляют к понятию вычислимости, введенному сто лет назад.
Я и говорю — не увеличивают! А Вы в ответ — "бред, хотя, впрочем, ничто не увеличивает...". И как Вас понимать? Вы согласны с тем, что не увеличивают, и одновременно говорите, что это бред!
Вот, например, циклы — возможности программы увеличивают. Уберите из императивного языка программирования все конструкции циклов — получите инвалида. Процедуры увеличивают возможности программы — уберите из языка программирования процедуры, и лишитесь рекурсии. Уберите из языка программирования указатели (ссылки), и Вы лишитесь динамических структур данных. Уберите из языка программирования процедурные переменные (указатели на процедуры) и Вы лишитесь того что называется (динамическим) полиморфизмом. А что далеко за примерами ходить — уберите из императивного языка программирования вообще все переменные, оставьте только константы, будет не язык, а не поймешь что. А вот шаблоны, что их в язык добавь, что их от туда удали — ничего не изменится, от них только программеру мешьше по клаве ботать. Что они в языке есть, что их нет, мощность языка от этого не меняется. От этого меняется отношение программиста к языку.
V>Ну а какие дополнительные возможности предоставляет команда call? Что мешает руками запихать адрес возврата в стек и сделать jmp? То есть нет никаких дополнительных возможностей. V>
Вы из своего любимого языка программирования мысленно удалите такое понятие как процедуры и подумайте что от этого изменится. А потом, верните их назад, и мысленно удалите шаблоны. От удаления/добавления шаблонов мощность языка не меняется, в отличие от удаления/добавления процедур.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вот, например, циклы — возможности программы увеличивают. Уберите из императивного языка программирования все конструкции циклов — получите инвалида. Процедуры увеличивают возможности программы — уберите из языка программирования процедуры, и лишитесь рекурсии. Уберите из языка программирования указатели (ссылки), и Вы лишитесь динамических структур данных. Уберите из языка программирования процедурные переменные (указатели на процедуры) и Вы лишитесь того что называется (динамическим) полиморфизмом. А что далеко за примерами ходить — уберите из императивного языка программирования вообще все переменные, оставьте только константы, будет не язык, а не поймешь что. А вот шаблоны, что их в язык добавь, что их от туда удали — ничего не изменится, от них только программеру мешьше по клаве ботать. Что они в языке есть, что их нет, мощность языка от этого не меняется. От этого меняется отношение программиста к языку.
Для тебя это ничего не меняется (может быть инвалид не язык, а человек его использующий? ), для меня убирание шаблонов выкинет из языка статический полиморфизм, вот C++ станет при этом инвалидом имхо...
Ну про стат. полиморфизм в ФЯ я вообще молчу — там без этого вообще делать нечего.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, prVovik, Вы писали:
V>>Ну а какие дополнительные возможности предоставляет команда call? Что мешает руками запихать адрес возврата в стек и сделать jmp? То есть нет никаких дополнительных возможностей. V>>
СГ>Вы из своего любимого языка программирования мысленно удалите такое понятие как процедуры и подумайте что от этого изменится. А потом, верните их назад, и мысленно удалите шаблоны. От удаления/добавления шаблонов мощность языка не меняется, в отличие от удаления/добавления процедур.
Это твоё мнение, а не общепризнанный факт, шаблоны — вещь очень мощная и полезная с т.зр. абстракции типов, хотя может быть тебе только процедур достаточно, тогда сорри
Здравствуйте, Kluev, Вы писали:
K>Когда у нас кодец вида: K>
K>if ( A *a = dynamic_cast<A*>(p)) return ...;
K>if ( B *b = dynamic_cast<B*>(p)) return ...;
K>
K>То компилер это не прооптимизирует. А встроенный свитч по типам наверное бы смог.
Может и смог бы. Но врял ли в Обероне — там (со слов СГ) все модули допускают линковку на рантайме, следовательно, на этапе разбора конструкции WITH, компилер не имеет права делать однозначные утверждения об иерархической принадлежности используемых в коде внешних классов.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Я и говорю — не увеличивают! А Вы в ответ — "бред, хотя, впрочем, ничто не увеличивает...". И как Вас понимать? Вы согласны с тем, что не увеличивают, и одновременно говорите, что это бред!
СГ>Вот, например, циклы — возможности программы увеличивают. Уберите из императивного языка программирования все конструкции циклов — получите инвалида. Процедуры увеличивают возможности программы — уберите из языка программирования процедуры, и лишитесь рекурсии. Уберите из языка программирования указатели (ссылки), и Вы лишитесь динамических структур данных. Уберите из языка программирования процедурные переменные (указатели на процедуры) и Вы лишитесь того что называется (динамическим) полиморфизмом. А что далеко за примерами ходить — уберите из императивного языка программирования вообще все переменные, оставьте только константы, будет не язык, а не поймешь что. А вот шаблоны, что их в язык добавь, что их от туда удали — ничего не изменится, от них только программеру мешьше по клаве ботать. Что они в языке есть, что их нет, мощность языка от этого не меняется. От этого меняется отношение программиста к языку.
Нет слов.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Сергей Губанов, Вы писали:
СГ>> А вот шаблоны, что их в язык добавь, что их от туда удали — ничего не изменится, от них только программеру мешьше по клаве ботать. Что они в языке есть, что их нет, мощность языка от этого не меняется. От этого меняется отношение программиста к языку. WH> WH> WH> WH> WH>Нет слов.
Не хочется быть грубым, но в голове возникает мысль — "а он сам понял что сказал?"
ДГ>>> потом наверняка войдут в обиход математически доказываемые системы, про которые упоминалось в статье-разборе полетов mission-critical глюков. Д>>очень узкая ниша — это максимум
ДГ>На ближайшее будущее — да. Но это самая важная ниша — в ней от глюков люди гибнут.
Где-то в интернете видел текст человека, работавшего то ли на ускорителе частиц то ли атомной электростанции где-то во Франции. Он там пишет, что представьте насколько тщательно писался и проверялся каждый код. Любая ошибка — и в радиусе пары десятков километров ни одного живого человека.
Здравствуйте, eugals, Вы писали:
E>Может и смог бы. Но врял ли в Обероне — там (со слов СГ) все модули допускают линковку на рантайме, следовательно, на этапе разбора конструкции WITH, компилер не имеет права делать однозначные утверждения об иерархической принадлежности используемых в коде внешних классов.
Не забывайте, что оберонистые модули — это не обычные DLL-ки. В них присутствует информация о типах. Например, в BlackBox, модуль программы физически представлен несколькими файлами
Mod - исходный текст модуля файл *.odc
Code - скомпилированный код для процессора файл *.ocf
Sym - скомпилированный символьный файл файл *.ocf (аналог скомпилированного header-файла)
Для компиляции модуля импортирующего другие модули нужно иметь все соответствующие символьные файлы тех модулей. Так что вся информация о иерархии наследования компилятору доступна.
Здравствуйте, Курилка, Вы писали:
К>для меня убирание шаблонов выкинет из языка статический полиморфизм, вот C++ станет при этом инвалидом имхо...
Можно ли эту фразу понимать в том смысле, что Вы держитесь двумя руками за Си++, не смотря на тщательно раскиданные в нем ровным слоем грабли, только потому, что в остальных языках (ну, если не считать Аду) нет шаблонов?
Если так, то как Вы отнесетесь к тому, если вдруг в будущем появится безупречный академически выверенный язык (совершенно без граблей) и тоже с шаблонами (Oberon + Templates)?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Курилка, Вы писали:
К>>для меня убирание шаблонов выкинет из языка статический полиморфизм, вот C++ станет при этом инвалидом имхо...
СГ>Можно ли эту фразу понимать в том смысле, что Вы держитесь двумя руками за Си++, не смотря на тщательно раскиданные в нем ровным слоем грабли, только потому, что в остальных языках (ну, если не считать Аду) нет шаблонов?
СГ>Если так, то как Вы отнесетесь к тому, если вдруг в будущем появится безупречный академически выверенный язык (совершенно без граблей) и тоже с шаблонами (Oberon + Templates)?
Очень положительно, если это будет не оторванный от жизни язык швейцарских академиков, а вещь, которую можно будет в жизни использовать.
Т.е. я согласен уже с несколькими мнениями о том, что C++ — вещь по сути очень хорошая, но имеющая много не очень хороших вещей, тянущихся от C или даже раньше того
З.Ы. Как бы это не было прискорбно, но вообще я сейчас на Delphi программлю , вот там периодически не хватает "плюсовых" вещей.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Для компиляции модуля импортирующего другие модули нужно иметь все соответствующие символьные файлы тех модулей.
Было бы странно, если бы нет.
СГ> Так что вся информация о иерархии наследования компилятору доступна.
Она ему доступна на момент компиляции. Но как он может быть уверен что она не изменится в дальнейшем?
Допустим у меня есть модуль A, который экспортирует класс сA.
Есть модуль B, с классом сB.
Есть третий, клиентский, модуль, в котором написано:
with
obj: cA do сделать_одно_действие |
obj: cB do сделать_другое_действие
end
Соответственно, если компилятор будет пытаться оптимизировать эту конструкцию, например строить хеш-таблицу, он может придти к тому, что изначально указанные выше проверки поменяются местами (так удобнее хеш вычислять окажется), то есть проверка на cB станет проходить до проверки на cA.
Проблема в том, что (ты сам говорил) ComponentPascal позволяет на рантайме отгружать/перегружать отдельные модули программы. Соответственно, никто не мешает мне в какой-то момент изменить, не трогая его внешний интерфейс, внутреннюю организацию модуля A. Именно, взять и назначить класс cA наследником класса cB.
Понятно, что, без перекомпиляции, приведенная выше оптимизированная конструкция "with" станет работать неверно (все полученные классы cA станет распознавать как cB).
Предполагаю следующие возможные решения этой проблемы:
1. Каждый раз, при рилоаде любого модуля, перекомпилировать и все он него зависящие.
2. Запещать на рантайме менять в модулях что-либо кроме внутренней реализации методов классов.
3. Не отптимизировать конструкцию WITH.
Я (впрочем, думаю как и Вы) не знаю внутренней реализации Оберона.
Тем не менее, позволю себе предположить, что выбран вариант №3, так как в первом нет ничего хорошего (уж лучше сразу всё приложение остановить и заново загрузить), а второй просто глупый и убивает на корню все выгоды от динамической загрузки модулей.
Повторю, всё выше написанное — в основном предположения, к тому же сделанные с чужих (тоих ) слов. Есть небольшая вероятность, что я не прав — буду раз услышать квалифицированное опровержение.
Здравствуйте, Сергей Губанов, Вы писали:
ГВ>>Перестаньте позорить чистое имя Вирта наглым пренебрежением к LSP!!! За подобные последовательности в нормальном промышленном коде нужно обрывать руки и предавать анафеме до конца семестра. СГ>Простите, Вы с чем-то не согласны?
Естественно. ИМХО — анализировать тип объекта в клиентском коде э... опасная практика. Хотя и применима иногда.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>Шаблоны позволяют меньше ручками по клавиатуре долбить. ГВ>>2. Процедуры, функции, и прочее подобное предназначены для того же. И что из этого следует? СГ>Процедуры и функции во время исполнения программы таки есть (помните такую команду call)? А вот шаблонов нет, то есть шаблоны не увеличивают возможностей программы.
Сформулируй понятие "возможности программы" в контексте нашей беседы вне привязки к конкретному языку программирования. Что это такое — "возможности программы"? И что на них влияет? А там и рассмотрим.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вот, например, циклы — возможности программы увеличивают. Уберите из императивного языка программирования все конструкции циклов — получите инвалида. Процедуры увеличивают возможности программы — уберите из языка программирования процедуры, и лишитесь рекурсии. Уберите из языка программирования указатели (ссылки), и Вы лишитесь динамических структур данных. Уберите из языка программирования процедурные переменные (указатели на процедуры) и Вы лишитесь того что называется (динамическим) полиморфизмом. А что далеко за примерами ходить — уберите из императивного языка программирования вообще все переменные, оставьте только константы, будет не язык, а не поймешь что. А вот шаблоны, что их в язык добавь, что их от туда удали — ничего не изменится, от них только программеру мешьше по клаве ботать. Что они в языке есть, что их нет, мощность языка от этого не меняется. От этого меняется отношение программиста к языку.
Не всё так просто. Говоря о языке мы всё-таки оцениваем язык как совокупность его возможностей. Выбрось одно или другое, и мы получим уже другой язык. С другой совокупностью фич и т.д. Согласен, что с "академической" точки зрения шаблоны, возможно, и не представляют особого интереса. А вот с практической — очень даже. Какой? А очень простой — уменьшить объёмы исходного кода, добавить надёжности за счёт статического полиморфизма и некоторым образом структурировать усилия по дальнейшему развитию программы. Поэтому твой пассаж насчёт "ничего не изменится" вызывает улыбку.
ИМХО, Вирт сейчас нацелен несколько на иное — он подбирает минимальный набор конструкций языка. Правда, почему-то при этом его несёт совсем в другою сторону... Почётное дело, надо сказать! Но практика, увы, она от теории всё-таки несколько отличается, как ни крути. Поэтому я, например, трудами Вирта до некоторой степени интересуюсь, но вот фетишизма и желания взять в руки флаг с надписью "Virth forever!" по этому поводу у меня не возникает. ИМХО, он всё-таки больше склонен к программизму, чем к синтезу из того комплекта, с которым нам приходится сталкиваться: психология, давление сроков и т.п. Я например, отказался от Паскалеподобных (и Java-подобных) языков, потому что они заставляли очень много писать. Гораздо больше, чем C++. И существенно дальше находились от "железного уровня", чем тот же C. А C++, ИМХО, не самый лучший, но вполне удачный синтез этих пожеланий (поменьше писать и спускаться поближе к железу).
ИМХО, C++ "страдает" как раз от большого количества нестыковок. Например, мне была бы интересна возможность сведения операторов к виду функций (я вкурсе, что любой оператор можно завернтуь в функцию!). Декларирование требований к интерфейсам аргументов шаблонов тоже не помешало бы. Хмм... что ещё. Интересно было бы иметь возможность из аргументов шаблонов определять как он будет использоваться — как родитель или как агрегируемый объект (не могу пока придумать толком — зачем, но любопытно...). Ещё хотелось бы определять шаблонами характеристики доступности элементов класса (public/protected/private). Ну, можно ещё что-то придумать...
PS. Ничего личного, разумеется.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
А вот у меня возник вопрос: а зачем вообще нужны языки программирования высокого уровня (ЯВУ)? Ведь никаких дополнительных "возможностей программы" по сравнению с ассемблером они не предоставляют, и не могут предоставить в принцепе! Более того, любая программа на ЯВУ, в конце концов, всеравно будет представлена в виде ассемблера. Если пользоваться вашей логикой, то получается, что ЯВУ, включая замечательный оберон, вообще не нужны. Имхо бред...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Я и говорю — не увеличивают! А Вы в ответ — "бред, хотя, впрочем, ничто не увеличивает...". И как Вас понимать? Вы согласны с тем, что не увеличивают, и одновременно говорите, что это бред!
С каждым разом это все забавнее... СГ>Вот, например, циклы — возможности программы увеличивают.
Ну конечно же не увеличивают! СГ>Уберите из императивного языка программирования все конструкции циклов — получите инвалида.
Ничего подобного. Если есть конструкция goto — можно организовать и цикл. СГ> Процедуры увеличивают возможности программы — уберите из языка программирования процедуры, и лишитесь рекурсии.
Ничего подобного. Вполне можно обойтись goto. СГ>Уберите из языка программирования указатели (ссылки), и Вы лишитесь динамических структур данных.
Согласен. Косвенная адресация — весчь необходимая. В императивных языках, ессно. СГ>Уберите из языка программирования процедурные переменные (указатели на процедуры) и Вы лишитесь того что называется (динамическим) полиморфизмом. А что далеко за примерами ходить — уберите из императивного языка программирования вообще все переменные, оставьте только константы, будет не язык, а не поймешь что.
Ну вот можно вообще очень много что убрать. Получим RISC-ассемблер. И что, вы думаете, на нем невозможно написать аналог Оберон-программы? Вот это-то и бред. Мощность языка останется той же самой. Только программисту колотить больше. СГ>А вот шаблоны, что их в язык добавь, что их от туда удали — ничего не изменится, от них только программеру мешьше по клаве ботать. Что они в языке есть, что их нет, мощность языка от этого не меняется.
В программировании рулит то и только то, что позволяет программисту ботать меньше. Потому что именно он — слабое звено. А сами по себе алгоритмы прекрасно реализуются и на машине Тьюринга.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, prVovik, Вы писали:
V> ... Если пользоваться вашей логикой ...
Логика заключалась в том, что мысленно убираются/добавляются конструкции языка высокого уровня и производится анализ того что это дает этому ЯВУ. Об ассемблерах в ЯВУ ничего не известно.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Так убери еще и goto. Что изменилась мощность языка?
на самом деле — нет
можно сделать push нужного адреса, а потом ret
еще можно сделать mov ip, <address> — если не ошибаюсь
или особо извращенный вариант — скопировать нужный кусок кода на место следующей по порядку инструкции
), для меня убирание шаблонов выкинет из языка статический полиморфизм, вот C++ станет при этом инвалидом имхо...
) слов. Есть небольшая вероятность, что я не прав — буду раз услышать квалифицированное опровержение. 
За подобные последовательности в нормальном промышленном коде нужно обрывать руки и предавать анафеме до конца семестра. 
Почётное дело, надо сказать! Но практика, увы, она от теории всё-таки несколько отличается, как ни крути. Поэтому я, например, трудами Вирта до некоторой степени интересуюсь, но вот фетишизма и желания взять в руки флаг с надписью "Virth forever!" по этому поводу у меня не возникает. ИМХО, он всё-таки больше склонен к программизму, чем к синтезу из того комплекта, с которым нам приходится сталкиваться: психология, давление сроков и т.п. Я например, отказался от Паскалеподобных (и Java-подобных) языков, потому что они заставляли очень много писать. Гораздо больше, чем C++. И существенно дальше находились от "железного уровня", чем тот же C. А C++, ИМХО, не самый лучший, но вполне удачный синтез этих пожеланий (поменьше писать и спускаться поближе к железу).
