Здравствуйте, eao197, Вы писали:
AVK>>В данном конкретном случае это не задача компилятора, а задача библиотеки для конкретных типов. Потому что за этим select совсем не обязательно стоит IL-код.
E>Жаль. Тогда это всего лишь синтаксический сахар.
Почему жаль? Какие возможности при этом теряются?
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Да вроде никому не было надо. А вобще, при желании, сделать можно. Другое дело, что надо понимать, что скорость вызова при этом существенно замедлится.
Замедлится. А асинхронный делегат что, работает с такой же скоростью, как обычный вызов.
А если никому не нужно было, нафига асинхронные делегаты вообще сделали?
AVK>Да, любишь ты простыни кода.
Твоя простыня не намного короче.
AVK>>>Ты вобще когда нибудь с ASP.NET или JSP сталкивался? Там эта возможность сто лет как реализована.
E>>C JSP сталкивался года четыре назад, некоторые application-сервера такую возможность поддерживали. Но хотелось бы отметить два момента: E>>-- во-первых, это не C++.
AVK>Т.е. изменение кода на лету будет прорывом, только если будет реализовано в С++?
Да, если в C++, то это будет прорывом из прорывов.
E>>-- во-вторых, не все задачи можно сделать на JSP.
AVK>А почему обязательно JSP. Я тебе просто привел пример того, что подобное, при наличии на то необходимости, на управляемых средах делается. Ну а то что С++ такого не умеет это личные проблемы С++, к проблемам индустрии в целом имеющие весьма отдаленное отношение.
С++ и индустрия уже никак не связаны?
E>> И если такой задачей приходится заниматься, то придется самому повторять то, что JSP было сделано.
AVK>Там на эту тему совсем не много кода, не переживай. В любом случае тебе придется проектировать приложение в рассчете на то, что код будет меняться.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>В данном конкретном случае это не задача компилятора, а задача библиотеки для конкретных типов. Потому что за этим select совсем не обязательно стоит IL-код.
E>>Жаль. Тогда это всего лишь синтаксический сахар.
AVK>Почему жаль? Какие возможности при этом теряются?
Возможность выбора и оптимизации плана выполнения запроса. Библиотека может знать, как распаралеллить одну операцию, но как оптимизировать весь select в целом, имхо, будет знать компилятор.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>Да вроде никому не было надо. А вобще, при желании, сделать можно. Другое дело, что надо понимать, что скорость вызова при этом существенно замедлится.
E>Замедлится. А асинхронный делегат что, работает с такой же скоростью, как обычный вызов.
На фоне тормозов с вызовом через сообщение практически с такой же.
E>А если никому не нужно было, нафига асинхронные делегаты вообще сделали?
А вот потому и не нужно, что при помощи асинхронных делегатов значительно быстрее и почти так же удобно.
AVK>>Да, любишь ты простыни кода.
E>Твоя простыня не намного короче.
Потому что твою имитировал.
AVK>>Т.е. изменение кода на лету будет прорывом, только если будет реализовано в С++?
E>Да, если в C++, то это будет прорывом из прорывов.
Забавное у тебя видение.
AVK>>А почему обязательно JSP. Я тебе просто привел пример того, что подобное, при наличии на то необходимости, на управляемых средах делается. Ну а то что С++ такого не умеет это личные проблемы С++, к проблемам индустрии в целом имеющие весьма отдаленное отношение.
E>С++ и индустрия уже никак не связаны?
В плане дальнейшего развития? Почти никак.
AVK>>Там на эту тему совсем не много кода, не переживай. В любом случае тебе придется проектировать приложение в рассчете на то, что код будет меняться.
E>Блин, забабахался уже объяснять, что есть языки, в которых не нужно его специально проектировать.
Языки тут не при чем. Вот скажи, ты в реальных проектах это применял? А вот я применял и не раз. Проблемм (чисто логических) масса.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, eao197, Вы писали:
AVK>>Почему жаль? Какие возможности при этом теряются?
E>Возможность выбора и оптимизации плана выполнения запроса.
Такие возможности там есть.
E> Библиотека может знать, как распаралеллить одну операцию, но как оптимизировать весь select в целом, имхо, будет знать компилятор.
Лучше почитай про LINQ поподробнее. В частности про Deffered query evaluation.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
E>>Замедлится. А асинхронный делегат что, работает с такой же скоростью, как обычный вызов.
AVK>На фоне тормозов с вызовом через сообщение практически с такой же.
Через какое сообщение?
E>>А если никому не нужно было, нафига асинхронные делегаты вообще сделали?
AVK>А вот потому и не нужно, что при помощи асинхронных делегатов значительно быстрее и почти так же удобно.
AVK>>>Да, любишь ты простыни кода.
E>>Твоя простыня не намного короче.
AVK>Потому что твою имитировал.
Ну дык в чем дело? Предложи решение этого примера "как надо".
AVK>>>А почему обязательно JSP. Я тебе просто привел пример того, что подобное, при наличии на то необходимости, на управляемых средах делается. Ну а то что С++ такого не умеет это личные проблемы С++, к проблемам индустрии в целом имеющие весьма отдаленное отношение.
E>>С++ и индустрия уже никак не связаны?
AVK>В плане дальнейшего развития? Почти никак.
Насколько я помню, проблема 2000 года была спровоцирована решениями, которые, как казалось, не имели никакой связи с дальнейшим развитием индустрии. На C++ уже написано и будет написано еще столько реально работающего кода, что вытеснение C++ из индустрии будет равносильно переводу всего железнодорожного транспорта в мире на единый стандарт колеи. Или даже на глобальный переход к монорельсовым дорогам.
AVK>>>Там на эту тему совсем не много кода, не переживай. В любом случае тебе придется проектировать приложение в рассчете на то, что код будет меняться.
E>>Блин, забабахался уже объяснять, что есть языки, в которых не нужно его специально проектировать.
AVK>Языки тут не при чем. Вот скажи, ты в реальных проектах это применял?
На C++ у меня такой возможности даже нет. Проблема горячей замены решается наличием master и slave процессов -- сначала перезапуском обновляется slave процесс, затем master.
AVK> А вот я применял и не раз. Проблемм (чисто логических) масса.
На ASP.NET и JSP?
Ивини, но это твой субъективный опыт.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>На фоне тормозов с вызовом через сообщение практически с такой же.
E>Через какое сообщение?
TP/RP работает как ты предлагаешь, т.е. на самом деле реально пересылает сообщение от одного объекта к другому.
E>>>Твоя простыня не намного короче.
AVK>>Потому что твою имитировал.
E>Ну дык в чем дело? Предложи решение этого примера "как надо".
Да хотя бы просто половину выкинуть — смысл ничуть не пострадает.
AVK>>В плане дальнейшего развития? Почти никак.
E>Насколько я помню, проблема 2000 года была спровоцирована решениями, которые, как казалось, не имели никакой связи с дальнейшим развитием индустрии. На C++ уже написано и будет написано еще столько реально работающего кода, что вытеснение C++ из индустрии будет равносильно переводу всего железнодорожного транспорта в мире на единый стандарт колеи. Или даже на глобальный переход к монорельсовым дорогам.
Тем не менее считать, что только изменения в С++ способны привести к революции, несколько самонадеянно.
AVK>>Языки тут не при чем. Вот скажи, ты в реальных проектах это применял?
E>На C++ у меня такой возможности даже нет.
Значит не применял.
AVK>> А вот я применял и не раз. Проблемм (чисто логических) масса.
E>На ASP.NET и JSP?
Не только.
E>Ивини, но это твой субъективный опыт.
Разумеется. Но у тебя то и такого нет.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
E>>Ну дык в чем дело? Предложи решение этого примера "как надо".
AVK>Да хотя бы просто половину выкинуть — смысл ничуть не пострадает.
Извини, это все из области bla-bla-bla.
AVK>Тем не менее считать, что только изменения в С++ способны привести к революции, несколько самонадеянно.
Цитату в студию, пожалуйста, где я утверждал подобные вещи.
E>>На C++ у меня такой возможности даже нет.
AVK>Значит не применял.
Нет, не применял. А разве эту мою фразу можно истолковать иначе?
E>>Ивини, но это твой субъективный опыт.
AVK>Разумеется. Но у тебя то и такого нет.
Здорово получается. Мудрый и искушенный AndrewVK на основании собственного субъективного опыта заявляет, что обновления кода приложения на лету -- это масса чисто логических проблем. Остается только трепетно внимать словам мастера.
Точка. Приехали. Вместо того, чтобы опытом поделиться, мол на таком-то языке пытались сделать так и так, наткнулись на то и то, решили больше так не делать, потому что... Вместо этого получается:
В слова "Поверьте мне как министру" не верю именно как министру.
((с) М.Жванецкий).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>>Ну дык в чем дело? Предложи решение этого примера "как надо".
AVK>>Да хотя бы просто половину выкинуть — смысл ничуть не пострадает.
E>Извини, это все из области bla-bla-bla.
Что из области bla-bla-bla? Твой пример не пострадает, если выкинуть любой из классов — Printer или Writer. А код сократится вдвое.
AVK>>Тем не менее считать, что только изменения в С++ способны привести к революции, несколько самонадеянно.
E>Цитату в студию, пожалуйста, где я утверждал подобные вещи.
AVK>Т.е. изменение кода на лету будет прорывом, только если будет реализовано в С++?
E>Да, если в C++, то это будет прорывом из прорывов.
Напоминаю, все это происходило в контексте разговора о том, какие технологии станут прорывом в программировании, сопоставимом с переходом от структурного программирования к ООП.
E>>>Ивини, но это твой субъективный опыт.
AVK>>Разумеется. Но у тебя то и такого нет.
E>Здорово получается. Мудрый и искушенный AndrewVK на основании собственного субъективного опыта заявляет, что обновления кода приложения на лету -- это масса чисто логических проблем. Остается только трепетно внимать словам мастера.
E>Точка. Приехали. Вместо того, чтобы опытом поделиться, мол на таком-то языке пытались сделать так и так, наткнулись на то и то, решили больше так не делать, потому что...
А ты просил меня опытом поделиться? Цитату в студию.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Зверёк Харьковский, Вы писали:
E>>>Ну да бог с ним. Меня ты не переубедил, а правду пускай историки ищут.
ЗХ>>Вот спасибо. Вот уж спасибочки...
E>Может тебе, как историку, интересна будет приведенная вот здесь схема эволюции языков
О! Первая схема языков где вижу более менее натуральный взгляд на появление и развите шарпа с явой. Особо прикольно наследование C# 2.0 от C# и Руби. Но в общем-то верно подмечено, хотя конечно тут и другие языки можно было подставить.
Интересно что подставят для C# 3.0. Никак ML/OKaml. А то и Лисп.
E>Так вот получается, что Java произошла от Oak, который вобрал в себя: Ada 83, Objective C, C++, Cedar, Smalltalk-80, Scheme. Не хилая солянка, однако (но синтаксис-то C++ный ).
А как же! О том и речь. А вопли про происхождение только от Оберона, как в прочем и от Оберан/Дельфи и т.п. просто бред фанатов этих языков видяхих сходные фичи и концепции.
E>А у C# было всего три прародителя: Deplhi 5, C++, Java. (Но ведь и Java имеет в родителях C++, так что у C# с C++ довольно тесные родственные связи ).
Я думаю, что родители транзитивны. Так что если Ц произошло от Б, а то в свою очередь, от А, то Ц автоматом произо и от А.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>2. Семантика Б расширяет семантику А ЗХ>Именно это зачастую подразумевается.
Думаю, что в этой схеме прямые линии — это "почти чистое расширение", а линии сверху/снизу — это наследование отдельных фич.
Заметь! Ява неимеет ни одного прямого родителя. Только вбирает фичи. C# 1.0 тоже. А вот С++ и С# 2.0 имеют одного прямого предка, то есть расширяют его, а не принимают из него отдельные фичи.
И по крайней мере для случаев Явы и Шарпа я с этой схемой в общем согласен. Если учесть, что схема огномна, то мелочи можно списать на банальный уровень абстракции.
ЗХ>Тут все далеко не так однозначно: во-первых, в некотором смысле тяжело провести разграничение между синтаксисом и семантикой; во-вторых, тяжело провести разграничения между "Б расширяет семантику А" и "Б изменяет сематику А".
И все же, похоже, это сделано. Прямые линии явное расшинерие.
ЗХ>По этому признаку, скажем (имхо!), Java и C# не только не являются наследниками C++, но в некотором роде не являются и наследниками C.
В схеме так и указано. Но надо признать, что С все же поглащен почти полностью. Вот только запихнут в ансэйф.
ЗХ>3. Б использует некоторое концепции, [впервые] появившиеся в А ЗХ>Именно это подразумевается в вышеприведенной схеме и во фразе "Oak, который вобрал в себя: Ada 83, Objective C, C++, Cedar, Smalltalk-80, Scheme". Можно ли назвать это "происхождением" — вопрос, в общем, довольно спорный. Который, к тому же, требует определения "первого появления" концепции.
+1
ЗХ>4. Б в некотором роде наследует "дух" А ЗХ>Тоже очень сложный вопрос. Хотя и часто используется в быту. Когда Гослинг говорит
: "Для разработчика, язык выглядел совершенно как C++. Но в душе Java взяла очень много от Smalltalk, Lisp и Pascal." — он, скорее всего, имеет в виду это.
+1 Однако дух определяется концепциями. Ведь концепции вроде одиночного наследования с единм корнем и определяют дух разработки как скорее ООП, чем С-подобный процедруный стиль, или С++-подобный шаблонно-множественно-наследованный .
ЗЫ
Кстати, забвано что Оберон в родители Явы не включен. И по-моему это правильно.
Но вот точно ошибкой является то что у Дельфи нет в папах (пусть и косвенных) Пасклая. Это же безобразие!
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
D>Согласен. Однако, imho, разница синтаксиса Паскаля и C в том, что Паскаль — ориентирован на быстрое обучение начинающих и с этой позиции begin лучше {,
Вообще-то даже сам Вирт признал begin ошибочным шагом и принял идею бэйсиков (оператор сам является началом блока). И тут я с ним согласен. Хотя это уже теперь в половине языков используется (погляди тот же руби).
D>секции лучше чем их отсутствие, = — это привычный значок "равно", а не "присвоить" и т.п.
И чем он привычен тем кто никогда не программировал на Паскале. Для меня := было дико непривычно, так как начинал писать я на С, но я прекрасно понимаю, что такова семантика языка.
А весь бред который несут Вирт и его поклонники легко разбивается примером BNF где := было использовано для задания правил, которые ну, никак присвоением не обозвать. Это именно что равенство (имени правила его тлу).
D>Правда с позиции предложенной классификации, это рассуждение больше относится к духу языка, чем непосредственно к синтаксису.
Это относится к мелким частностям. Иначе от чего тогда Руби происходит? В нем как и в Паскле нельзя присваивать выражения в if-ах, но как в С присваение идет знаком =.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Просто когда выйдет C++09 старых компиляторов скорее всего не останется C> Точнее, там где они останутся — новый С++ не нужен будет.
Правильнее называть этот стандарт C++0x, а еще правильнее С++ 0x0XXX. Тогде не будет проблем с переносом дат.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>К сожалению, скорее всего, никакие: deadline для языковых предложений уже позади, а предложений lambda так и не было видно. Теперь надежда на разработчиков компиляторов...
Хрен ли там надеяться? Саттер комуниздит все что попало из C# х.х и правильно делает. Так что вопрос за тем пойдут за ним или получится еще большая каша, что есть сейчас.
В общем, чем ждать у моря погоды проще надеяться, что в ближайшее время выдут хорошо оптимизирующие компиляторы для МСИЛ-а и про C++ можно будет забыть как про страшный сон перепрыгнув на C#/OCaml/Boo и им подобные языки у которых нет маньякального наследия С/С++. Я уже тама.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>К сожалению, скорее всего, никакие: deadline для языковых предложений уже позади, а предложений lambda так и не было видно. Теперь надежда на разработчиков компиляторов...
Кстаит, Паш, а ты смотрел ОКамл и другие МЛ-подобные языки? Ведь то что тебе нравится в С++ там реализовано несравннено лучше. По скорости некоторые компиляторы ОКамла не хуже VC7. Что мешает перейти?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Ну дык почему же не сделать такую же возможность для обычных вызовов в рамках одного многопоточного процесса?
VD>На то есть две причины: VD>1. Дико не эффективно!
+1. Но ведь многопоточным приложениям нужно как-то обмениваться данными между потоками. В любом случае здесь будет не эффективность по сравнению с обычными вызовами (и даже виртуальными).
VD>2. На фиг не упало.
-1. Здесь у меня другой опыт.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Что из области bla-bla-bla? Твой пример не пострадает, если выкинуть любой из классов — Printer или Writer. А код сократится вдвое.
Т.е. возражения по оформлению, а не по сути?
Я специально указал и Printer и Writer, чтобы посмотреть, насколько вырастет общий листинг, если будут использованы асинхронные делегаты. Ведь для одного класса (Printer или Writer) увеличение кода с 2-х строк до 4-х не так заметно. А вот для двух классов увеличение кода с 4-х строк до 8-ми уже гораздо заметнее.
AVK>>>Тем не менее считать, что только изменения в С++ способны привести к революции, несколько самонадеянно.
E>>Цитату в студию, пожалуйста, где я утверждал подобные вещи.
AVK>
AVK>>Т.е. изменение кода на лету будет прорывом, только если будет реализовано в С++?
E>>Да, если в C++, то это будет прорывом из прорывов.
AVK>Напоминаю, все это происходило в контексте разговора о том, какие технологии станут прорывом в программировании, сопоставимом с переходом от структурного программирования к ООП.
Ну контекстов там было затронуто множество. А по существу вопроса:
-- я не сказал "Да, только если в C++" и не упомянул всю индустрию;
-- моя фраза -- это только ирония (жаль, что ты не заметил);
-- а ты сам подумай, если C++ станет настолько управляемым языком, что в production системе, средствами самого языка можно будет менять код какого-то метода на лету, то его роль в индустрии (по отношению к C#/Java) существенно изменится, тебе не кажется? Хотя это из области фантазии. Отсюда и ирония.
Ну а если серьезно? Можно ли сейчас в мейнстримовых языках менять реализацию классов на лету, не уничтожая уже созданных объектов? Не через ручную "двойную" диспетчеризации + рефлекшен, а штатными средствами. Мне кажется, что это только увеличит для разработчиков свободу выбора и, как следствие, может привести к очень значительным изменениям при разработке ПО.
AVK>А ты просил меня опытом поделиться? Цитату в студию.
Про измерение опыта ты сам заговорил. А потом стал утверждать что-то на основании твоего опыта (про который я вообще ничего не знаю). Вот эти утверждения уже в серьез не воспринимаются.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
А то и Лисп. 