Здравствуйте, jazzer, Вы писали:
J>У меня таких данных нет. У тебя есть? Я имею в виду, количество проектов на язык (а лучше — на методику, потому что тот же С++ можно использовать как С с классами, а можно — на полную катушку). Очень интересно посмотреть, в каком году в каком проценте проектов использовалось метапрограммирование (имхо, сейчас количество таких проектов быстро растет и почти не зависит от задачи, если только она не совсем уж тупая типа разбрасывания контролов по форме).
Я не Lisp-ер, поэтому не знаю, где поискать информацию аналогичную Common Lisp Success Stories для Lisp-а тех времен. Но думаю, что применения Lisp-а в реальной работе были. Ведь Common Lisp развился и начал использоваться отнюдь не на пустом месте.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Plague, Вы писали:
AF>>Но на С++ нельзя, верно?
P>Что-то Вы, уважаемый, преувеличиваете. Не надо думать, что все считают, что С++ можно запихнуть везде. Инструкции шейдеров довольно сложны, а учитывая, что требуется оптимизировать с учетом ТИПОВ и КОНВЕЙЕРОВ.
P>Шейдеры пишутся на DSL языках, т.к. их нельзя использовать для разработки других программ и в них встроены особенности работы с видеокартой.
На самом деле видеокарты проходят тот же путь повышения абстракции: сначала был NVasm, потом специализированные языки Cg, HLSL, GLSL, а теперь вот уже можно обычный C
(правда там хитро — часть работы производится на CPU, часть на GPU).
P>Скриптовые языки введены в разработку игр по одной причине — распределение разработки, т.е. те кто будет писать скрипты, т.е. это могут быть даже не высококвалифицированные программисты, т.е. язык должен быть проще и в нем должен быть доступ только к игровым объектам. При этом разработка может проходить параллельно и изменения не будут влиять на основной модуль.
Плохо то, что они (скрипты), как правило интерпретируются. В принципе перспективный подход — это их JIT компиляция. И некоторые уже так и делают — вот например в небезызвестной игре Second Life для скриптов потихоньку пытаются встроить рантайм Mono:здесь.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>У меня таких данных нет. У тебя есть? Я имею в виду, количество проектов на язык (а лучше — на методику, потому что тот же С++ можно использовать как С с классами, а можно — на полную катушку). Очень интересно посмотреть, в каком году в каком проценте проектов использовалось метапрограммирование (имхо, сейчас количество таких проектов быстро растет и почти не зависит от задачи, если только она не совсем уж тупая типа разбрасывания контролов по форме).
E>Я не Lisp-ер, поэтому не знаю, где поискать информацию аналогичную Common Lisp Success Stories для Lisp-а тех времен. Но думаю, что применения Lisp-а в реальной работе были. Ведь Common Lisp развился и начал использоваться отнюдь не на пустом месте.
Я сразу, понятное дело, ткнулся в музыку — ссылки не работают, вот облом
Понятно, что не на пустом месте. Понятно, что был Яху (не знаю, что там за лисп использовался, но это 90-е уже, если не позже), и Буч очень хорошо отзывался о CLOS, и я после прочтения его книжки страсть как захотел его изучить.
Так же как и функциональные языки — я вот считал диссер на Математике, там такая помесь функционального и императивного — и мне сильно не хватало в плюсах функциональных возможностей.
Но все равно в последнее время рулил ООП, а до него — структурщина. Естественно, были изыскания и эксперименты в стороне от мэйнстрима, если бы их не было, не было бы сейчас взлета функциональных языков и метапрограммирования.
В общем, я свое имхо озвучил
Заодно смотри мой ответ Трурлю.
В общем, я не могу сразу всем отвечать одно и то же, давайте я буду где-нть в одном месте
Прощу прохения заранее
Здравствуйте, AndreiF, Вы писали:
AF>Это уже отельный вопрос. А факт — это то, что универсальность плюсов сильно преувеличивают. И никакого Q4 "на чистом С++" никто не напишет.
Пардон, но ИМХО ты уже ушел не в ту степь. Сам Q4 на С++ написать реально. Кста он на нем то и написан. А вот все окружение — графику, шейдера, звук и прочее — это отдельно.
Кстати поскольку тобой был использован чуть ли не самый популярный прием демагогии — доведение до абсурда, то с чистой совестью вешаю ярлык: вы сударь — демагог!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, jazzer, Вы писали:
J>И потом, ну какой это промышленный язык? Когда количество проектов на нем хотя бы приближалось к количеству ООП-проектов на других ООП-языках?
Не надо подменять понятия. К чему эти впадения в среднетяжмаш? Речь шла не о промышленности а о новизне — и в этом смысле метапрограммирование скорее всего старее, чем ООП.
Первые пакеты символьной математики были написаны на Lisp, а значит, и с использованием метапрограммирования. Это как, серьезные проекты?
Софт для Space Shuttle — по некоторым данным самое надежное и дорогое ПО всех времен и народов — был написан в том числе и на DSL-диалекте PL/1. Это нормальный проект?
Или пока каждый комбайнер на селе не начнет без устали метапрограммировать, изобретение не засчитывается? Так тогда метапрограммирование не просто ново, а еще не изобретено.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, jazzer, Вы писали:
J>>И потом, ну какой это промышленный язык? Когда количество проектов на нем хотя бы приближалось к количеству ООП-проектов на других ООП-языках?
K>Не надо подменять понятия. К чему эти впадения в среднетяжмаш? Речь шла не о промышленности а о новизне — и в этом смысле метапрограммирование скорее всего старее, чем ООП.
нет, изначально речь не о новизне, а о том, что это была общеизвестная базовая вещь во времена создания С++.
K>Первые пакеты символьной математики были написаны на Lisp, а значит, и с использованием метапрограммирования. Это как, серьезные проекты? K>Софт для Space Shuttle — по некоторым данным самое надежное и дорогое ПО всех времен и народов — был написан в том числе и на DSL-диалекте PL/1. Это нормальный проект?
Вполне серьезные и нормальные. Но технология мейнстримовой не была.
K>Или пока каждый комбайнер на селе не начнет без устали метапрограммировать, изобретение не засчитывается? Так тогда метапрограммирование не просто ново, а еще не изобретено.
ну не надо извращать мой тезис. Я не хочу флейма. См. мой пост Трурлю.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, jazzer, Вы писали:
J>>В то время рулили всякие алголы и фортраны и прочие PL/1
Т>Кстати. Макросы PL/1 — чем не метапрограммирование?
Ну и макросы макроассемблера тоже
давайте все же разделим, что мы считаем метапрограммированием, а что — нет.
Иначе любой язык может служить примером метапрограммируемого, если он умеет писать на диск файлы и вызывать для них компилятор, а потом запускать скомпилированную программу (кто сказал, что программа — это только один бинарник?) или динамически загружать собранную таким образом библиотеку.
Для меня лично идеальный язык, поддерживающий метапрограммирование — это язык, в который встроен API к компилятору.
Т.е. который имеет доступ ко всему, что имеет компилятор, и, соответственно, может анализировать это как угодно, генерить на основе этого код (более общо — сущности, которыми оперирует компилятор, включая типы, код и еще чего-нть, атрибуты, скажем) и инжектировать его в любое место дерева инструкций, системы типов и т.п.
Чтобы можно было на самом языке определять, что такое — класс (скажем, что в нем генерится по умолчанию, а что — нет, как именно работает определенное отношение между классами, начиная с простейших — наследование, агрегация, делегирование и т.п.) и т.п.
Т.е. чтобы он, грубо говоря, торчал где-то между фронт-эндом и бэк-эндом компилятора и мог делать все, что только можно себе вообразить на этом месте и с этой информацией. Иными словами, язык программирования компилятора.
Вот в таком виде метапрограммирование, я считаю, дошло до промышленной кондиции только сейчас (вернее, еще не дошло, но необходимость этого ясно осознана). И сейчас есть четкое понимание, что любой язык в том или ином виде должен это содержать. Именно поэтому сейчас почти все языки движутся в этом направлении — и С++, и жава, и шарп.
Я считаю, что раньше (т.е. во времена создания С++, да и Java тоже) этого понимания не было. Тогда еще с ООП толком не разобрались (несмотря на то, что основополагающие работы был сделаны в 50-60х, типа Лисков и прочих). Развитие ООП, на мой взгляд, более-менее завершилось с формулировкой дизайн-паттернов.
В общем, изначальный тезис, к которому тут прицепились и раздули флейм, сводится к простой вещи — некорректно говорить, что в С++ нет такой базовой вещи, как рефлексия, ибо то, что это действительно базовая вещь (т.е. необходимая в _каждом_ промышленном языке, в том числе и в императивном), а не просто экзотика, осознано очень недавно. Если бы все промышленные языки того времени умели рефлексировать и это использовалось бы в почти каждой программе — тогда да, упрек был бы по адресу. Но так не было.
Вот если бы в С++ не было поддержки ООП — такой упрек был бы корректным. Потому что в то время было четкое понимание, что языки должны поддерживать ООП в том или ином виде.
Естественно, я говорю про индустрию программирования, а не про науку — она, понятное дело, всегда впереди и обычно немного не о том. С++ создавался для решения реальных задач и проблем, стоявших перед индустрией того времени. Имхо, рефлексия и заодно метапрограммирование тогда в списке насущных проблем не значились.
Здравствуйте, CreatorCray, Вы писали:
CC>Пардон, но ИМХО ты уже ушел не в ту степь. Сам Q4 на С++ написать реально. Кста он на нем то и написан. А вот все окружение — графику, шейдера, звук и прочее — это отдельно.
Мда. Бедный С++ — с одной стороны его притесняют совсем уж низкоуровневые языки, с другой скрипты. Но все равно кому-то еще хватает совести заявлять, что "на самом то деле бОльшая часть на С++ пишется"
CC>Кстати поскольку тобой был использован чуть ли не самый популярный прием демагогии — доведение до абсурда, то с чистой совестью вешаю ярлык: вы сударь — демагог!
Развешивание ярлыков — еще более популярный прием демагогии.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Gajdalager, Вы писали:
G>>Т.о. .Нет 1.1 все-таки кросплатформенный за небольшим исключением. CC>Нельзя быть немного беременной. Или кроссплатформ или нет.
Кроссплатформенный в рамках стандарта ISO на CLR. Т.е. MSIL код запустится везде, а вот набор библиотек в Mono (пока?) не соответствует полностью MS.NET. Более подробно Mono Migration Analyzer, Results — Miguel de Icaza.
CC>Иначе получается кросс только для негуевых прог.
Пользуй Gtk# и будет тебе кроссплатформенный GUI. Да и реализация WinForms в Mono уже не так плоха — вон Paint.NET запустили под Linux:
При этом основная проблема была в том, что Paint.NET пользовался Windows-specific функциями:
This Paint application despite its young age is quite sophisticated and calls into a number of Win32 libraries to use features not exposed directly by the .NET libraries. For example, it determines the number of CPUs to adjust its thread pool, it uses low-level heap routines from the OS and other things like that.
Вопрос в библиотеках. Дело в том что значительная часть библиотек .NET не стандартизована, а выпущена чисто MS.
Но это с любым языком/платформой так. Ты же не можешь использовать С++/COM/MFC программу в Линукс. А C++/Qt можешь и в Windows и в Linux.
G>>Думаю, если бы МС вложила в развитие Моно (или даже своего собственного порта .Нета под Линукс) хотя бы половину денег, которые вложила в разработку платформы под винду CC>Ага щаззз...
Java давит своей кроссплатформенностью, поэтому все возможно.
G>>В плюсах же ВМ и ГЦ нет CC>И это является плюсом плюсов.
Где плюс, а где и минус. В бизнес-приложениях Java вытеснила C++ на задворки.
Здравствуйте, Plague, Вы писали:
P>Хех, как Вы хитро сюда к разговору Вирта прикрутили, это намек на Оберон? Его простота в отсутствии "Синтаксического оверхеда"?
Не простота (simplicity), а чистота (purity) — отсутствие всего наносного, излишнего.
Нельзя сказать что оберон-системы сложные, но и нельзя сказать что они простые, они просто чистые.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Plague, Вы писали:
P>>Хех, как Вы хитро сюда к разговору Вирта прикрутили, это намек на Оберон? Его простота в отсутствии "Синтаксического оверхеда"?
СГ>Не простота (simplicity), а чистота (purity) — отсутствие всего наносного, излишнего. СГ>Нельзя сказать что оберон-системы сложные, но и нельзя сказать что они простые, они просто чистые.
Ассемблер тоже туда запишем? Зачем нам что-то "наносное" к тому, как оно "внутрях" работает?
Здравствуйте, dmz, Вы писали:
dmz>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, dmz, Вы писали:
J>>>>Когда метапрограммирование начало использоваться промышленно?
J>>Ну, я не помню там особого метапрограммирования. Рефлексия — да, была.
dmz>Согласно источникам, там еще были метаклассы.
Насколько я помню, они ничего не умели. В основном их функция сводилось к созданию новых объектов классов. Но могу и ошибаться.
J>>И потом, ну какой это промышленный язык? Когда количество проектов на нем хотя бы приближалось к количеству J>ООП-проектов на других ООП-языках?
dmz>А какие еще в 80-х были ООП языки? И каково было вообще количество проектов? Есть подозрение, что dmz>сильно меньше, чем сейчас.
А причем тут сейчас? Вспомни, на какой тезис я отвечал. Короче, см. ответ Трурлю рядом
dmz>>>В принципе, кодогенерация это тоже, в некотором роде, метапрограммирование. А лет кодогенерации лет наверное немногим меньше, чем программированию.
J>>Метапрограммирование — это руление кодом программы из самого кода на этом же языке в той же самой программе. J>>А кодогенерация — это кодогенерация, у нее свое место.
dmz>С тобой согласны не все:
dmz>
Metaprogramming is the writing of programs that write or manipulate other programs (or themselves) as their data or that do part of the work that is otherwise done at runtime during compile time. This allows programmers to produce a larger amount of code and get more done in the same amount of time as they would take to write all the code manually.
dmz>Да и из практических соображений, велика ли разница — сам язык предоставляет средства манипулирования порождаемым кодом, или внешний тул? Вот взять С — препроцессор, там, конечно, часть языка — но больших проблемах написать препроцессоров на чем угодно и использовать их — нет. Какая разница при этом? Родной препроцессор в принципе, сильно отличается от языка в целом. То же можно и сказать о шаблонах — они, согласно стандарту, часть языка — но при этом сильно отличаются от остального языка. Это целая новая концепция, с другими выразительными средствами и даже подходом.
Я объясню, в чем разница.
Препроцессор был тыщу лет, еще в Си.
Шаблоны — не тыщу, но для чего они использовались (и для чего были созданы)? Правильно, для обобщенных контейнеров и функций типа min/max. И не были они никакой "новой концепцией, с другими выразительными средствами и даже подходом".
C тех пор ничего эпохального в С++ (в язык) привнесено не было, все, что мы имеем сейчас, все эти навороты — в общих чертах были реализуемы и раньше, в основном происходила чистка от граблей, которые мешают реализовывать вдруг открывшиеся возможности, о которых никто и не подозревал.
Скажем, метапрограммирование с использованием препроцессора (Boost.Preprocessor) было возможно еще в Си.
И что, кто-то озаботился этим? Нет. Только в последнее время. Или, ты думаешь, шаблоны сразу разрабатывались как полный по Тьюрингу язык времени компиляции? Естественно, нет. Так почему же _сейчас_ все бросились использовать шаблоны и препроцессор для вещей, на которые они изначально не были рассчитаны? Ответ простой: потому что _сейчас_ стало ясно, что без этого не жить.
В чем, собственно, и состоял мой тезис. Не была тогда поддержка метапрограммирования и рефлексии базовой вещью, необходимой в каждом универсальном языке программирования. Иначе всю эту магию препроцессора открыли бы еще в сишные времена.
J>>А какая разница? И там, и там метапрограммирование. J>>И Александреску совсем не был первым извращенцем, кстати
dmz>Ну разница где-то в том, что вычисление факториала числа в компайл-тайме dmz>практически бесполезно, несмотря на то, что реализовано при помощи "метапрограммирования".
Это просто proof of concept. Поскольку вычисления ведутся на уровне типов, то результатом обычно являюются тоже типы.
Факториал — это просто демонстрация для тех, кто в жизни функционального программирования не видел. Сглаживание кривой обучения, так сказать — факториал рекурсивно считать умеют все. Реальное же использование всего этого дела — Boost.MPL.
J>>По количеству часов, отводимых на него, и количеству программистов, выпускавшихся специалистами по метаязыкам — J>что ,столько же ,сколько по С/С++/VB?
dmz>По количеству часов, честно говоря, не знаю. Знаю только, что в MIT CS учили с чего-то вроде схемы, по пути реализовав ее интерпретатор в рамках курса. А VB в штатах учат таксистов, на недельных курсах.
Я тоже видел пост об этом, но у меня сложилось впечатление, что речь шла о нынешнем времени, а не о времени создания С++. Опять же, могу ошибаться.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Gajdalager, Вы писали:
G>>Т.о. .Нет 1.1 все-таки кросплатформенный за небольшим исключением. CC>Нельзя быть немного беременной. Или кроссплатформ или нет. Иначе получается кросс только для негуевых прог. здесь
G>>С другой стороны, в Жавы есть реальная кросплатформенность, с этим, думаю, не поспоришь. CC>В те древние времена когда я работал в жабовом проекте с кроссплатформенностью там были проблемы. И это на чисто бизнес проекте где ничего HW specific не было. Правда давно это было ...
Ну С++ тоже не сразу писался За время моей очень скромной карьеры я с проблемами запуска моего кода под определенную платформу не сталкивался G>>В плюсах же ВМ и ГЦ нет CC>И это является плюсом плюсов.
Не знаю, мне пока ни то, ни другое совсем не мешало G>>На засыпочку. Сколько времени тебе нужно убить, чтобы скомпилировать и запустить код, отлично портируемый между Win-32 и Linux, на 64-битную архитектуру? CC>Чью 64 битную? Win/Lin?
А все равно.. Лучше бы, конечно и туда, и туда, поскольку жава и там и там: http://java.sun.com/javase/6/webnotes/install/system-configurations.html
.Net кстати тоже есть и под Win-32 и под Win-64.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Кроссплатформенный в рамках стандарта ISO на CLR. Т.е. MSIL код запустится везде, а вот набор библиотек в Mono (пока?) не соответствует полностью MS.NET.
Подытоживая: в более общем случае почти любая VM-based прога будет кроссплатформенной. И будет работать на любой платформе где под нее напишут VM. А если еще и JIT прикрутят то вапще гут.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Кроссплатформенный в рамках стандарта ISO на CLR. Т.е. MSIL код запустится везде, а вот набор библиотек в Mono (пока?) не соответствует полностью MS.NET. CC>Подытоживая: в более общем случае почти любая VM-based прога будет кроссплатформенной. И будет работать на любой платформе где под нее напишут VM. А если еще и JIT прикрутят то вапще гут.
Угу
Здравствуйте, Курилка, Вы писали:
К>Ассемблер тоже туда запишем? Зачем нам что-то "наносное" к тому, как оно "внутрях" работает?
Да! Вот именно! Но далеко не любой. Иные наборы машинных команд (к каковым относится и набор команд x86) при всём желании невозможно назвать чистыми. Придумать хороший набор команд не просто.
По сути язык Оберон и есть "ассемблер", только объектно-ориентированный и для "оберон-машины".
СГ>Не простота (simplicity), а чистота (purity) — отсутствие всего наносного, излишнего. СГ>Нельзя сказать что оберон-системы сложные, но и нельзя сказать что они простые, они просто чистые.
Здравствуйте, FR, Вы писали:
K>>Возмножно, но весьма сложно. В принципе, можно браться за любой сложности задачу, однако, когда сложность превышает все возможные пределы, можно сказать, что решить задачу невозможно (на самом деле, экономически невыгодно).
FR>В чем сложность то? Мне кажется ты сильно преувеличиваешь то упрощение которое дают для данного класса задач ML подобные языки. Если бы ты был прав, то компиляторя уже очень давно писались бы только на чем то ML подобном например на Ocaml.
Да, на ML-подобных языках компиляторы писать удобнее. Однако тут уж вступают в игру иные факторы. Например, сложность изучения ML. Чтобы на C++ писать, Вася Пупкин может прочитать книжку "C++ для идиота" и чего-нибудь да напишет (правда ему за такую писанину руки надо будет отрубить). Для того, чтобы тот же Вася выучил ML, нужно чтобы он имел некоторые фундаментальные знания и опыт. Отсюда следует непопулярность ML. А именно популярность (но никак не удобство), к сожалению, определяет, на чём пишется софт. Ну можно ещё привести аргументы. Например, есть GNU-ортодоксы, которые до сих пор предпочитают C с синтаксисом K&R для тех приложений, для которых он не очень подходит (например GUI).
Здравствуйте, Cyberax, Вы писали:
C>Напишешь Quake4 на Питоне?
Нафига? Вон, Цивилизация 4 на питоне фактически написана, только движок на C++. А в кваке нет ничего такого, что требовало бы четырёхэтажных скриптов. Фактически, почти вся игра состоит из одного движка. Движки действительно писать можно только на C++, а жаль . Может быть, в будущем что-то изменится.
. Может быть, в будущем что-то изменится.