Вышла новая статья о закономерностях в программировании. Приведу несколько выдержек из нее:
"При этом каждое следующее серьезное изобретение в области программирования — это почти всегда изобретение следующего интерфейса (это и есть «этаж») между системными «слоями»:
Изобретение операционной системы — это изобретение интерфейса между машиной и приложениями. Операционная система инкапсулирует в себе соотв. функции.
Изобретение языков программирования (например, ассемблера) — это изобретение интерфейса между кодом и человеком. Язык инкапсулирует в себе код.
Изобретение языков более высокого уровня – то же самое на следующей стадии.
Изобретение объектно-ориентированного программирования – это попытка создать интерфейс между функциями ("методами") и разработчиком.
Поэтому нынешнее явление миру «шаблонно-ориентированного программирования» [12, стр 163] — совершенно закономерный надсистемный переход от «объектов» и «классов» к их готовым контекстным сочетаниям.
Наверное, закономерен и дальнейший переход от «мышления отдельными шаблонами» к мышлению их готовыми сочетаниями (готовыми надсистемами из шаблонов). Давайте назовем эти готовые сочетания шаблонов «стилями». И тогда будет переход к «стильному программированию»".
"Вспомним «эволюцию языков программирования»:
Вначале были «нули и единицы»
Позже произошел первый надсистемный переход: «нули и единицы» сгруппировались в «мнемоники» — часто повторяющиеся готовые сочетания «нулей и единиц», например, для команды пересылки данных – MOV, для команды сложения – ADD и т.п. Т.е. появились «ассемблеры» [8].
Заметим: мнемоники, как бы сказали теперь, «инкапсулировали» (закрыли) «нули и единицы» от программиста. Стали «интерфейсом» между программистом и «нулями».
Затем произошел второй надсистемный переход: «простые ассемблеры» заместились «макроассемблерами», которые могли оперировать уже «группой мнемоник». И в этом смысле их стали называть «более мощными» [9].
Затем произошел третий надсистемный переход: «языки высокого уровня» вытеснили в узкую нишу «ассемблеры» и «макроассемблеры».
И здесь надо отметить сразу два «надсистемных эффекта»:
Каждая инструкция языка высокого уровня стала «еще мощней», т.е. компилировалась «сразу в десятки машинных команд».
Инструкция языка высокого уровня понималась целиком, а операторы, входящие в инструкцию сами по себе (вне ее контекста), не имели смысла. Подобно тому, как в литературе обладают своим смыслом целиком фраза или стихотворение, а слова, их образующие, этим смыслом не обладают [9].
В результате исчезло соответствие между теми командами, которые пишет программист, и теми командами, которые исполняет процессор.
Как известно, это позволило создавать языки, «заточенные» под предметную область:
Фортран – для решения инженерных задач и научных расчетов.
Кобол – для решения экономических задач.
Алгол-68, Паскаль – для обучения студентов программированию.
Бейсик – для написания диалогов пользователя с ЭВМ.
Си – для написания операционных систем, трансляторов, баз данных и других системных и прикладных программ.
Пролог – для методов автоматического доказательства теорем.
Ада – для моделирования параллельного решения задач. [7]
Изобретение языков высокого уровня позволило осуществлять перенос программы с машины на машину. И это позволило программисту (пишущему на высоком уровне) «не знать» или «знать минимально» устройство машины. Как бы сказали теперь, эти языки «инкапсулировали» (закрыли) «устройство машины» от программиста. Стали «интерфейсом» между программистом и компьютером.
Затем произошел четвертый надсистемный переход: «структурное программирование» вытеснило «линейное». Программа стала пониматься как группа (читай: «надсистема») модулей, которые можно писать отдельно, а проектирование в значительной степени стало пониматься как проектирование интерфейсов для общения модулей.
Затем произошел пятый надсистемный переход: … впрочем, дальнейшую логику вдумчивый Читатель продолжит сам."
У меня были похожие мысли. Сейчас можно выделить несколько слоев абстракции для программирования
1. Машинный код
2. Ассемблер
3. Языки среднего уровня (модульное программирование (си), процедурное программирование (pascal))
4. Языки высокого уровня (ООП, функциональное программирование etc.)
5. Паттерны проектирования, UML – диаграммы классов, взаимодействия, состояний
6. Паттерны предметной области (?) (более сложные UML диаграммы ? диаграммы пакетов?)
7. UML – диаграммы вариантов использования, различные Mind Maps, описания из предметной области
Сейчас наименее формализован уровень 6. (хотя чувствуется что там должен быть какой-то уровень)
очень хотелось бы чтобы все эти слои были доступны в IDE. Т.е. я ставлю квадратик "программа", и от него могу постепенной детализацией спуститься вниз вплоть до машинного кода.
Здравствуйте, x-code, Вы писали:
XC>У меня были похожие мысли. Сейчас можно выделить несколько слоев абстракции для программирования XC>
XC>1. Машинный код
XC>2. Ассемблер
XC>3. Языки среднего уровня (модульное программирование (си), процедурное программирование (pascal))
XC>4. Языки высокого уровня (ООП, функциональное программирование etc.)
XC>5. Паттерны проектирования, UML – диаграммы классов, взаимодействия, состояний
XC>6. Паттерны предметной области (?) (более сложные UML диаграммы ? диаграммы пакетов?)
XC>7. UML – диаграммы вариантов использования, различные Mind Maps, описания из предметной области
XC>
XC>Сейчас наименее формализован уровень 6. (хотя чувствуется что там должен быть какой-то уровень)
XC>очень хотелось бы чтобы все эти слои были доступны в IDE. Т.е. я ставлю квадратик "программа",
Графическое и текстовое представления — это всего лишь два представления (интерфейса к, если угодно) одной семантической сущности — программы. Блок-схемы можно иметь и для машинных кодов.
XC> и от него могу постепенной детализацией спуститься вниз вплоть до машинного кода.
Согласен, тут вопрос формализации. Если на каком-то уровне у тебя есть полная формализация программы — т.е. что должно быть на выходе, что на входе и компьютер может вывести (возможно, с подсказкой) как это надо делать, то тебе в принципе не нужно спускаться на более низкие уровни, поскольку там уже за тебя решено все автоматически. Сейчас большинство программ пишутся на уровне 4, все что выше слабо формализовано, от этого определенные проблемы в том числе с обратной связью, т.к. модель нижнего уровня может начать расходиться с моделью верхнего, но у нас есть мало инструментов для автоматического приведения их в соответствие, а также на задание constraints сверху вниз.
Здравствуйте, Андрей Хропов, Вы писали:
XC>>очень хотелось бы чтобы все эти слои были доступны в IDE. Т.е. я ставлю квадратик "программа", АХ>Графическое и текстовое представления — это всего лишь два представления (интерфейса к, если угодно) одной семантической сущности — программы. Блок-схемы можно иметь и для машинных кодов. XC>> и от него могу постепенной детализацией спуститься вниз вплоть до машинного кода. АХ>Согласен, тут вопрос формализации. Если на каком-то уровне у тебя есть полная формализация программы — т.е. что должно быть на выходе, что на входе и компьютер может вывести (возможно, с подсказкой) как это надо делать, то тебе в принципе не нужно спускаться на более низкие уровни, поскольку там уже за тебя решено все автоматически. Сейчас большинство программ пишутся на уровне 4, все что выше слабо формализовано, от этого определенные проблемы в том числе с обратной связью, т.к. модель нижнего уровня может начать расходиться с моделью верхнего, но у нас есть мало инструментов для автоматического приведения их в соответствие, а также на задание constraints сверху вниз.
Я скорее имел в виду представление не на уровне данных, а представление для самой IDE. UML тоже можно создавать в текством редакторе. Так сложилось, что для классического программирования текст — наиболее удобный формат. Наиболее компактный (на экране больше всего влезает именнт текстовой информации, в сравнении например с любыми диаграммами), и наиболее удобный для редактирования.
Вообще, для дальнейшего продвижения по уровням IDE становится не менее важной частью программирования чем ЯП.
Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST. А текстовый редактор можно вызывать если программисту "по старинке" заходелось написать кусок кода (причем именно ограниченный кусок кода — метод или блок в методе), и сразу же когда программист закончит вводить код, этот код нужно преобразовать в AST. А если там ошибки — сразу же указать на них в окне редактора.
Тогда полностью исчезнет проблема синхронизации уровней, а заодно и куча других проблем.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>"При этом каждое следующее серьезное изобретение в области программирования — это почти всегда изобретение следующего интерфейса (это и есть «этаж») между системными «слоями»:
Я бы сказал, что важнее всего — это развитие железа и инструментов оптимизации, которые делают возможным применение новых уровней абстракции на практике. К примеру, в те времена, когда повсеместно писали макаронный код, было прекрасно известно что такое функция, но их редко использовали, "потому что вызов функции — это слишком дорого"
x-code,
XC>Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST.
То что ты предлагаешь некоторые люди давно прошли. Читаем Пола Грэхема:
If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them...
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
XC>>Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST.
LCR>То что ты предлагаешь некоторые люди давно прошли. Читаем Пола Грэхема: LCR>
LCR>If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them...
Читаем внимательно и понимаем, что Грэхем писал о совсем другом.
Здравствуйте, x-code, Вы писали:
XC>Вообще, для дальнейшего продвижения по уровням IDE становится не менее важной частью программирования чем ЯП. XC>Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST. А текстовый редактор можно вызывать если программисту "по старинке" заходелось написать кусок кода (причем именно ограниченный кусок кода — метод или блок в методе), и сразу же когда программист закончит вводить код, этот код нужно преобразовать в AST. А если там ошибки — сразу же указать на них в окне редактора. XC>Тогда полностью исчезнет проблема синхронизации уровней, а заодно и куча других проблем.
Может я опять путаю, но по-моему это(см. выше) является частью концепций DSL.
Все привыкли, что программа хранится в виде текста – потока символов. Почему бы и нет? В конце концов, существует огромное количество инструментов для редактирования, отображения и манипуляции текстом.
...
При компиляции исходного кода компилятор представляет текст в виде древовидного графа, называемого «абстрактным синтаксическим деревом». Ту же самую операцию программист выполняет в уме, читая исходники.
...
...
Если мы хотим сделать создание языков легким, нужно отделить представление и хранение программы от самой программы. Мы должны хранить программы прямо в виде структурированного графа, что дает возможность вносить любые дополнения в язык. Временами текстовое хранилище вообще не нужно.
...
Проблема в том, что текстовый редактор глуп и не умеет работать с графом, лежащим в основе программы. Но при помощи соответствующих инструментов редактор сможет напрямую взаимодействовать с графом программы, что даст свободу выбора визуального представления.
Здравствуйте, x-code, Вы писали:
XC>Вообще, для дальнейшего продвижения по уровням IDE становится не менее важной частью программирования чем ЯП. XC>Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST.
На самом деле так и делается в хороших IDE для хороших языков (читай не С++).
Так как сам работаю над этим могу сказать, что IDE оперирует именно с AST. Только вот от ткста отказываться не стоит. Это ошибка. В свое время был продукт (он наверно и сейчас существует) Gupta SqlWindows. Потом его вроде как переименовывали в Centura SqlWindows или SqlBuilder... давно было, уже не помню. Так вот у него как раз вместо радактора код был АСТ-редактор. Не могу сказать, что это было совсем неудобно, но реально плоский текст с поддержкой IDE все же удобнее... по-моему.
Забавно, что современные IDE уже не обходятся просто AST. Они практически полностью компилируют программу и вынимают из нее всю информацию от положения лексем, до типов (как объявленных в программе, так и импортируемых из внешних длл-ей). Так что они куда интеллектуальнее чем многие думают.
XC> А текстовый редактор можно вызывать если программисту "по старинке" заходелось написать кусок кода (причем именно ограниченный кусок кода — метод или блок в методе), и сразу же когда программист закончит вводить код, этот код нужно преобразовать в AST.
Как не странно "по старинке" писать удобнее. И банально удобнее работать с файлом или даже целым проектом, нежели с одельным методом, к примеру.
И ты уж совсем удивишся, но разработчикам IDE в сто раз было бы проще давать редактировать только один метод. Но они поступают сложнее. Они дают тебе править код где угодно и уже сами отслеживают что ты там на редактировал чтобы соотвествующим образом изменить внутренние структуры данных (в том числе и AST).
XC> А если там ошибки — сразу же указать на них в окне редактора.
Дык так и делают лучшие IDE. РеШарпер практически в риалтайме отображает ошибки. Мы в Интеграции для Немрла делаем это когда после небольшой паузы после того как программист закончил ввод. А когда кто-то пытается посмореть хинт или воспользоваться автодополнением, то обновление внутринних структур фарсируется. Так что фактически прогараммист всегда имеет возможность получить помощь от IDE.
XC>Тогда полностью исчезнет проблема синхронизации уровней, а заодно и куча других проблем.
К сожалению, тогда появится другая проблема. Дело в том, что очень сложно ввести сразу полностью корректный код. А такая IDE обязана будет отвергать некорректный ввод. В итоге программист попросту не сможет ввести код программы, или будет вынужден ужасно мучиться.
Современная IDE разрешает вводить любую фигню и в теневом режиме контролирует то что вводит программист. Если в коде появлются ошибки IDE их подсвечивает. Если код становится верным подсветка ошибок убирается.
Ну, а чтобы программисту было удобно ползать по коду IDE предоставляет такие вещи как список классов и фукнций вверху редактируемого файла. Возможности навигации по коду, поиску вхождений, контекстной подсветки, броузеров и т.п.
Так что вы просто плохо понимаете как устроена современная IDE и почему все сделано именно так, а не иначе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>То что ты предлагаешь некоторые люди давно прошли. Читаем Пола Грэхема: LCR>
LCR>If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them...
Скажи ты что вообще современных IDE не видел? Или просто сообщение прочел по диаганали?
Какое отношение твоя цитата имеет к поддержке IDE?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > К сожалению, тогда появится другая проблема. Дело в том, что очень > сложно ввести сразу полностью корректный код. А такая IDE обязана будет > отвергать некорректный ввод. В итоге программист попросту не сможет > ввести код программы, или будет вынужден ужасно мучиться.
Так когда-то разные Бэйсики работали, на Спектруме точно так было
VladD2,
VD>Или просто сообщение прочел по диаганали?
Да, действительно, речь шла об главным образом об IDE, а не о AST. А я то сначала подумал, что человеку хочется просто писать в синтаксических деревьях...
Прочитал ещё раз: X>> А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST.
То есть я так понимаю, что человек хочет иметь что-то типа редактора реестра, только вместо реестра там будет AST?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>То есть я так понимаю, что человек хочет иметь что-то типа редактора реестра, только вместо реестра там будет AST?
Turtle.BAZON.Group,
LCR>>То есть я так понимаю, что человек хочет иметь что-то типа редактора реестра, только вместо реестра там будет AST?
TBG>Я так понял, что типа того, что сам же и показывал.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, x-code, Вы писали:
VD>На самом деле так и делается в хороших IDE для хороших языков (читай не С++).
к сожалению, для меня пока языки типа C# непреемлемы, т.к. разрабатываю системы реального времени. Со временем, конечно, когда количество процессорных ядер будут измеряться десятками, а поддержка кода MSIL наверняка будет аппаратной (?), C++ уйдет в прошлое, но вот сейчас очень не хватает всего того что есть под .NET (хотя даже там нет всего что хочется)
А пока я невооруженным глазом (!) по скорости открывания меню и диалогов определяю, написан ли софт на Java, каком-либо managed-языке .NET, или под реальный процессор, пишу на C++. Хотя уже достало
VD>Так как сам работаю над этим могу сказать, что IDE оперирует именно с AST. Только вот от ткста отказываться не стоит. Это ошибка. В свое время был продукт (он наверно и сейчас существует) Gupta SqlWindows. Потом его вроде как переименовывали в Centura SqlWindows или SqlBuilder... давно было, уже не помню. Так вот у него как раз вместо радактора код был АСТ-редактор. Не могу сказать, что это было совсем неудобно, но реально плоский текст с поддержкой IDE все же удобнее... по-моему.
AST-редактор для всего кода конечно же неудобен. Но, например, структуры и классы было-бы удобнее заполнять в виде таблиц, а не текста. Например, для полей данных минимальная таблица "доступ — тип — имя — значение по умолчанию — комментарий", для методов "доступ — тип — имя — раскрывающееся дерево с таблицей аргументов — комментарий".
функции и методы, безусловно, удобнее в виде текста, но чтобы в одном окне ("отсеке" окна? здесь есть место для новых концепций UI) было тело одного метода, а в какой-то заголовочной части была таблица аргументов, аналогичная таблице структуры или класса.
Речь идет просто об отказе от длинных "полотен" кода в котором свалены и классы и методы и все остальное.
Еще одна проблема — в программах нет связи с логикой предметной области. Я сейчас разрабатываю плагин для студии, чтобы добавить такую связь в простейшем варианте (по сути "иерархическая база букмарков с метаданными"). В C# эту область частично могут покрывать атрибуты. А то плоский список классов из нескольких сотен классов, в каждом из которых десятки методов и переменных, уже раздражает.
XC>> А текстовый редактор можно вызывать если программисту "по старинке" заходелось написать кусок кода (причем именно ограниченный кусок кода — метод или блок в методе), и сразу же когда программист закончит вводить код, этот код нужно преобразовать в AST. VD>Как не странно "по старинке" писать удобнее. И банально удобнее работать с файлом или даже целым проектом, нежели с одельным методом, к примеру.
Это как? Если я работаю с методом, ни разу не нужно было выходить за его пределы. Если мне нужно перейти к другому методу — пользуюсь деревом классов (к сожалению, его тоже приходится прокручивать)
А для проекта есть древовидное представление — дерево классов или то что будет вместо него на более высоких уровнях программирования. От него как раз никто и не предлагает отказываться.
VD>И ты уж совсем удивишся, но разработчикам IDE в сто раз было бы проще давать редактировать только один метод. Но они поступают сложнее. Они дают тебе править код где угодно и уже сами отслеживают что ты там на редактировал чтобы соотвествующим образом изменить внутренние структуры данных (в том числе и AST).
зачем так сделано? не вижу смысла. ради простой навигации по коду? поиск по файлам быстрее работает.
XC>>Тогда полностью исчезнет проблема синхронизации уровней, а заодно и куча других проблем. VD>К сожалению, тогда появится другая проблема. Дело в том, что очень сложно ввести сразу полностью корректный код. А такая IDE обязана
будет отвергать некорректный ввод. В итоге программист попросту не сможет ввести код программы, или будет вынужден ужасно мучиться.
В реалтайме проверять код ненужно, ИХМО это будет просто раздражать (как минимум — тормозами). Идеальный вариант — кнопочка типа "ввести" по которой файл/фрагмент кода будет преобразовываться в AST и при необходимости указываться ошибки.
Здравствуйте, x-code, Вы писали:
VD>>На самом деле так и делается в хороших IDE для хороших языков (читай не С++). XC>к сожалению, для меня пока языки типа C# непреемлемы, т.к. разрабатываю системы реального времени. Со временем, конечно, когда количество процессорных ядер будут измеряться десятками, а поддержка кода MSIL наверняка будет аппаратной (?), C++ уйдет в прошлое, но вот сейчас очень не хватает всего того что есть под .NET (хотя даже там нет всего что хочется)
Ради интереса — конкретизируйте, если не трудно, область применения разрабатываемых вами систем реального времени.
Мне казалось, что для встраиваемых систем(встраиваемых систем on-line обработки данных, встраиваемых АСУП и т.д.), для систем телекома и т.д. наоборот уже давно применяют Model-driven development(DSL+кодогенерация)
С промышленными вариантами MDD-систем-разработки встраиваемых систем я не знаком. В научных кругах наработок достаточно много(как в теории, так и в практике). Например, проект Ptolemy II, ориентированный на "modeling, simulation, and design of concurrent, real-time, embedded systems".
Концепция таких(как ptolemy) систем разработки — выбираем "правильную" для нас модель вычислений(сети Петри, конечные автоматы, как самые известные или CSP-Хоара,...) или создаём гибридную модель вычислений, затем моделируем в рамках выбранной модели нашу систему и генерируем код(в случае ptolemy возможна генерация Java, C++ кода и ранее была возможна генерация кода определённого семейства микропроцессоров Motorolы).
Вопрос: считаете ли вы такие системы разработки тем самым недостающим уровнем в проектировании систем, систем реального времени ? и вообще мой ответ в русле вопроса или я упустил суть проблемы(подменив её на свою) ?
Здравствуйте, x-code, Вы писали:
VD>>На самом деле так и делается в хороших IDE для хороших языков (читай не С++). XC>к сожалению, для меня пока языки типа C# непреемлемы, т.к. разрабатываю системы реального времени. Со временем, конечно, когда количество процессорных ядер будут измеряться десятками,
Ты очень сильно приувиличиваешь тормоза управляемых сред. Очень сильно. XC>а поддержка кода MSIL наверняка будет аппаратной (?),
Это не нужно. И даже вредно. Пусть лучше нормальный риск процессор сделают без x86'ой нашлепки. XC>C++ уйдет в прошлое, но вот сейчас очень не хватает всего того что есть под .NET (хотя даже там нет всего что хочется)
XC>А пока я невооруженным глазом (!) по скорости открывания меню и диалогов определяю, написан ли софт на Java, каком-либо managed-языке .NET, или под реальный процессор, пишу на C++. Хотя уже достало
Жаба да. .NET извини не поверю.
XC>AST-редактор для всего кода конечно же неудобен. Но, например, структуры и классы было-бы удобнее заполнять в виде таблиц, а не текста. Например, для полей данных минимальная таблица "доступ — тип — имя — значение по умолчанию — комментарий", для методов "доступ — тип — имя — раскрывающееся дерево с таблицей аргументов — комментарий".
Представил. Ужаснулся. ИМХО в морг. XC>функции и методы, безусловно, удобнее в виде текста, но чтобы в одном окне ("отсеке" окна? здесь есть место для новых концепций UI) было тело одного метода, а в какой-то заголовочной части была таблица аргументов, аналогичная таблице структуры или класса.
Зачем? чем плох простой текст? XC>Речь идет просто об отказе от длинных "полотен" кода в котором свалены и классы и методы и все остальное.
Те у тебя весь код в одном файле? Я тебя правильно понял?
XC>Еще одна проблема — в программах нет связи с логикой предметной области. Я сейчас разрабатываю плагин для студии, чтобы добавить такую связь в простейшем варианте (по сути "иерархическая база букмарков с метаданными"). В C# эту область частично могут покрывать атрибуты. А то плоский список классов из нескольких сотен классов, в каждом из которых десятки методов и переменных, уже раздражает.
А пространства имен тебя чем не устраивают?
XC>Это как? Если я работаю с методом, ни разу не нужно было выходить за его пределы. Если мне нужно перейти к другому методу — пользуюсь деревом классов (к сожалению, его тоже приходится прокручивать) в текстовом редакторе это сделать быстрее. А в IDE которая предоставляет навигацию вобще моментально. И не нужны тут никакие деревья.
VD>>И ты уж совсем удивишся, но разработчикам IDE в сто раз было бы проще давать редактировать только один метод. Но они поступают сложнее. Они дают тебе править код где угодно и уже сами отслеживают что ты там на редактировал чтобы соотвествующим образом изменить внутренние структуры данных (в том числе и AST). XC>зачем так сделано? не вижу смысла. ради простой навигации по коду? поиск по файлам быстрее работает.
Может попробуешь поработать и ReSharper'ом? Иначе если ты не видил ничего умнее IDE для С++ разговаривать с тобой о IDE не имеет смысла.
XC>В реалтайме проверять код ненужно, ИХМО это будет просто раздражать (как минимум — тормозами). Идеальный вариант — кнопочка типа "ввести" по которой файл/фрагмент кода будет преобразовываться в AST и при необходимости указываться ошибки.
Нет никаких тормозов. Те вобще нет.
Всеравно у тебя процессов постоянно бездействует вот пусть и подсвечивает ошибки в отдельном потоке с очень низким приоритетом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > Может попробуешь поработать и ReSharper'ом? Иначе если ты не видил > ничего умнее IDE для С++ разговаривать с тобой о IDE не имеет смысла.
Еще можно порекомендовать IDEA для Java. Чтобы отпали все вопросы о том,
что в нормальной IDE должно быть.
> XC>В реалтайме проверять код ненужно, ИХМО это будет просто раздражать > (как минимум — тормозами). Идеальный вариант — кнопочка типа "ввести" по > которой файл/фрагмент кода будет преобразовываться в AST и при > необходимости указываться ошибки. > Нет никаких тормозов. Те вобще нет. > Всеравно у тебя процессов постоянно бездействует вот пусть и > подсвечивает ошибки в отдельном потоке с очень низким приоритетом.
Угу, особенно это круто на двухпроцессорных машинах. Там оно вообще
параллельно работает с набором кода без всяких тормозов. Я когда
попробовал — выпал в осадок.
Здравствуйте, Cyberax, Вы писали:
C>Угу, особенно это круто на двухпроцессорных машинах. Там оно вообще C>параллельно работает с набором кода без всяких тормозов. Я когда C>попробовал — выпал в осадок.
Идею не использовать но ReSharper и на одном процессоре совсем не тормозит. Разве что стартует очень долго. Что-то у них там с кешами.
С другой стороны часто ли IDE нужно запускать?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, x-code, Вы писали:
XC>к сожалению, для меня пока языки типа C# непреемлемы, т.к. разрабатываю системы реального времени.
А чем конкретно, если не секрет?
XC>А пока я невооруженным глазом (!) по скорости открывания меню и диалогов определяю, написан ли софт на Java, каком-либо managed-языке .NET, или под реальный процессор, пишу на C++. Хотя уже достало
Ну, про глаз ты загибаешь. На самом деле прекомпилированные ехе-шники нета ни чем по скорости не оличаются. То что ты можешь наблюдать скорее всего вызвано или медлительностью написанного на каком-нить GDI+ меню, или банальным процессом джит-компиляции который происходит всего лишь раз.
Хотя бесспорно отенет пока для реалтайм-задач не применим. Если конечно речь идет о настоящем жестком реальном времени.
Вот только не могу понять причем тут IDE? Ведь IDE точно не задача реального времени.
XC>AST-редактор для всего кода конечно же неудобен. Но, например, структуры и классы было-бы удобнее заполнять в виде таблиц, а не текста. Например, для полей данных минимальная таблица "доступ — тип — имя — значение по умолчанию — комментарий", для методов "доступ — тип — имя — раскрывающееся дерево с таблицей аргументов — комментарий".
Это сделать элементарно, но вряд ли это будет удобно.
XC>функции и методы, безусловно, удобнее в виде текста, но чтобы в одном окне ("отсеке" окна? здесь есть место для новых концепций UI) было тело одного метода, а в какой-то заголовочной части была таблица аргументов, аналогичная таблице структуры или класса.
Чего же тут новго? Это, простите за моветон, VB 1.0 или даже еще раньше... тот самый SqlWindows 93-его года выпуска.
XC>Речь идет просто об отказе от длинных "полотен" кода в котором свалены и классы и методы и все остальное.
Дык а чем хуже то длинное полотно, если по нему есть удобная навигация?
XC>Еще одна проблема — в программах нет связи с логикой предметной области.
У гого как.
XC> Я сейчас разрабатываю плагин для студии, чтобы добавить такую связь в простейшем варианте (по сути "иерархическая база букмарков с метаданными"). В C# эту область частично могут покрывать атрибуты. А то плоский список классов из нескольких сотен классов, в каждом из которых десятки методов и переменных, уже раздражает.
Велкам ту Немерле! В нем можно писать свои DSL-и (встроенные предметно-ориентированные языки), расширять синтаксис и реализовывать логику времени компиляции (например, для тех же атрибутов).
XC>Это как?
Вот так. В один момент правишь меотд — рассматриваешь его как сущность. А в другой момент оказывается удобным произвести поиск по коду всего проекта. Или скажем замену. При рефакторинге вообще неудобно в рамках одного метода сидеть.
XC>Если я работаю с методом, ни разу не нужно было выходить за его пределы. Если мне нужно перейти к другому методу — пользуюсь деревом классов (к сожалению, его тоже приходится прокручивать)
Для перехода внутри файла лучше использовать комбы над редактором. А если нужно перейти к некторорому методу вызваемому в данном месте, топроще нажать F12. Метаданные же по всему коду есть!
XC>А для проекта есть древовидное представление — дерево классов или то что будет вместо него на более высоких уровнях программирования. От него как раз никто и не предлагает отказываться.
Дык в один момент удобно на уровне классов по проекту полазить. А в другой на уровне файлов. Ведь один класс может лежать в 10 файлах, а нам может быть нужен конекретный.
XC>зачем так сделано? не вижу смысла. ради простой навигации по коду? поиск по файлам быстрее работает.
Смысл в том, что работать с файлом удобнее. Ты можешь быстро взять код из одного места и скопировать в другое. Переместить сразу 10 методов. В общем можешь работать с файлами, а не отдельными фукнциями. А когда надо нет проблем перейти к нужной фукнции и т.п.
VD>>К сожалению, тогда появится другая проблема. Дело в том, что очень сложно ввести сразу полностью корректный код. А такая IDE обязана будет отвергать некорректный ввод. В итоге программист попросту не сможет ввести код программы, или будет вынужден ужасно мучиться.
XC>В реалтайме проверять код ненужно, ИХМО это будет просто раздражать (как минимум — тормозами).
Процессоры довольно мощьны. Проверить код одной фукцнии не проблема.
XC> Идеальный вариант — кнопочка типа "ввести" по которой файл/фрагмент кода будет преобразовываться в AST и при необходимости указываться ошибки.
Привет тебе. При твоей схеме текста нет! Ты сразу вводишь АСТ! А стало быть ошибки не приемлемы. Более того, проблематичным будет даже ввести код в нужном порядке.
Когда же у нас первично текстовое представление, то проблем нет. Ведь текст (как бумага) стерпит все! Мы даже можем сохранить программу в некорректном состоянии, закрыть... потом открыть и продолжить редактирование. И это не вызовет проболем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
XC>>А пока я невооруженным глазом (!) по скорости открывания меню и диалогов определяю, написан ли софт на Java, каком-либо managed-языке .NET, или под реальный процессор, пишу на C++. Хотя уже достало WH>Жаба да. .NET извини не поверю.
А что Жаба? Ты ИДЕЮ видел? Многие кто ею пользовался утверждают, что она работает вполне быстро.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Еще можно порекомендовать IDEA для Java. Чтобы отпали все вопросы о том, > C> что в *нормальной* IDE должно быть. > Вать машу... если так дальше пойдет кто же С++ то останется защищить?
Ну так я никогда и не утверждал, что для С++ есть нормальные IDE
Здравствуйте, VladD2, Вы писали:
VD>Вать машу... если так дальше пойдет кто же С++ то останется защищить?
C++ или IDE ?
C++ — защищать не стоит, он и сам за себя прекрасно постоит.
IDE — это как сказать. Но отмечу мимоходом, что у Visual Studio C++ и C# вообще-то одна и та же IDE . На .Net написанная.
Ну а что касается всяких фич IDE — это ИМХО на любителя. Кому-то нравится. что IDE на каждый его чих реагирует и подсказывает, что так и что не так (по ее мнению), кому-то — нет. Лично мне — как сказать. Я сейчас с Eclipse дело имею, там этого добра много. С одной стороны приятно, что он контролирует без того, чтобы нажимать F7 каждый раз, с другой — иногда он мне такое выдает, что и испугаться можно.
Оптимально решение ИМХО — такие возможности должны быть, но должны легко отключаться. И волки будут сыты, и овцы целы.
Это, кстати, не о IDE, а вообще о всех "интеллектуальных" средах — то есть любом ПО, которое "знает как надо". Пока его предположения о том, как надо, совпадают с моими — я рад им пользоваться. Но когда у меня появляется иное мнение "как надо" — я должен иметь возможность попросить его заткнуться и не мешать.
Pavel Dvorkin wrote: > Это, кстати, не о IDE, а вообще о всех "интеллектуальных" средах — то > есть любом ПО, которое "знает как надо". Пока его предположения о том, > как надо, совпадают с моими — я рад им пользоваться. Но когда у меня > появляется иное мнение "как надо" — я должен иметь возможность попросить > его заткнуться и не мешать.
Интересно, а в чем это должно выражаться? Например, я еще пока не нашел
в чем IDEA была когда-либо не права
Здравствуйте, Cyberax, Вы писали:
C>Pavel Dvorkin wrote: >> Это, кстати, не о IDE, а вообще о всех "интеллектуальных" средах — то >> есть любом ПО, которое "знает как надо". Пока его предположения о том, >> как надо, совпадают с моими — я рад им пользоваться. Но когда у меня >> появляется иное мнение "как надо" — я должен иметь возможность попросить >> его заткнуться и не мешать. C>Интересно, а в чем это должно выражаться? Например, я еще пока не нашел C>в чем IDEA была когда-либо не права
Нет, не то я имею в виду. По существу она права. Но , как известно, человек, который всегда прав, в конце концов начинает вызывать тихую ненависть окружающих . Здесь то же самое. Однажды переводил я программу с C на Паскаль. Работа формальная в основном, думать не надо. Я просто взял текст на C, вставил в редактор Delphi и начал редактировать. Периодически F7 нажимал, чтобы убедиться, что выше по тексту у меня ошибок нет. И все нормально было. Представляю себе, что было бы с интеллектуальной IDE в таком случае... . И со мной.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>IDE — это как сказать. Но отмечу мимоходом, что у Visual Studio C++ и C# вообще-то одна и та же IDE . На .Net написанная.
Нет. Visual Studio написана на C++ и лишь с некоторыми .NET добавками. На насчет "одна и та же" — не совсем так, потому что речь шла о таких возможностях как автозаполнение, подсветка ошибок, автоматизированный рефакторинг и т.п. А это в существенно бОльшем объеме поддерживается для C#.
Pavel Dvorkin wrote: > Периодически F7 нажимал, чтобы убедиться, что выше по тексту у меня > ошибок нет. И все нормально было. Представляю себе, что было бы с > интеллектуальной IDE в таком случае... . И со мной.
Она бы все закрасила красным цветом Хотя ради такого случая просто
можно было бы отключить нафиг все фичи.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Нет, не то я имею в виду. По существу она права. Но , как известно, человек, который всегда прав, в конце концов начинает вызывать тихую ненависть окружающих . Здесь то же самое. Однажды переводил я программу с C на Паскаль. Работа формальная в основном, думать не надо. Я просто взял текст на C, вставил в редактор Delphi и начал редактировать. Периодически F7 нажимал, чтобы убедиться, что выше по тексту у меня ошибок нет. И все нормально было. Представляю себе, что было бы с интеллектуальной IDE в таком случае... . И со мной.
Боюсь, что ничего катастрофического. Delphi же не умер при Code Completion? А это почти то же самое — компиляция частично неправильного кода. Это как раз немереная крутизна текстового формата с интеллектуальным помощником за плечом. Вот если бы ты попробовал сделать такой трюк в Direct AST Editor, то ты бы встрял.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Боюсь, что ничего катастрофического. Delphi же не умер при Code Completion? А это почти то же самое — компиляция частично неправильного кода. Это как раз немереная крутизна текстового формата с интеллектуальным помощником за плечом. Вот если бы ты попробовал сделать такой трюк в Direct AST Editor, то ты бы встрял.
Да нет, просто переташил бы AST, а дальше что там написалось — все само!
А можно для редакторов не компилировать неправильный код, пока дерево не заполнится, оно считается невалидным и в этап компиляции не включается, а когда уже все, то помечается специальной версией.
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Вать машу... если так дальше пойдет кто же С++ то останется защищить?
PD>C++ или IDE ?
-----------------------------------
— Василий Иванович! Приборы!!!
— 42.
— Что, 42,
— А что приборы?
PD>C++ — защищать не стоит, он и сам за себя прекрасно постоит.
Он живой?
PD>IDE — это как сказать. Но отмечу мимоходом, что у Visual Studio C++ и C# вообще-то одна и та же IDE . На .Net написанная.
VS — это оболочка запускающая разные пакеты. А вот уже поддержка пакетов определяет качество поддержки языка. Создать качественную IDE для С++ не позволяют слабость современных процессоров и дизайн С++ не рассчитанный на это. Так что хорошая IDE есть только для соотвествющих языков.
PD>Ну а что касается всяких фич IDE — это ИМХО на любителя. Кому-то нравится. что IDE на каждый его чих реагирует и подсказывает, что так и что не так (по ее мнению), кому-то — нет. Лично мне — как сказать. Я сейчас с Eclipse дело имею, там этого добра много. С одной стороны приятно, что он контролирует без того, чтобы нажимать F7 каждый раз, с другой — иногда он мне такое выдает, что и испугаться можно.
Дык выброси С++ и будет выдавать все как часы. Насколько я знаю с Явой Эклипс работает стабильно.
PD>Оптимально решение ИМХО — такие возможности должны быть, но должны легко отключаться. И волки будут сыты, и овцы целы.
Не волки, а страперы. Они себе нопэд с подсветкой синтксиса (а то и без оной) и так за всегда найдут.
Эффективность программиста зависит от того исползует он качественную IDE или нет. А суждения о ее ненужности разводятся теми кто банльно имеет производительность ниже плинтуса и не имеет реального оптыа применения этих самых IDE.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>IDE — это как сказать. Но отмечу мимоходом, что у Visual Studio C++ и C# вообще-то одна и та же IDE . На .Net написанная. АХ>Нет. Visual Studio написана на C++ и лишь с некоторыми .NET добавками. На насчет "одна и та же" — не совсем так, потому что речь шла о таких возможностях как автозаполнение, подсветка ошибок, автоматизированный рефакторинг и т.п. А это в существенно бОльшем объеме поддерживается для C#.
Я имел в виду только тот факт, что VS IDE есть .Net приложение. А на чем ее писали — естественно, я сказать не могу. Рефлектор, если захочешь, тебе и Delphi код ее покажет . Вполне допускаю, что там и unmanaged кода полно.
Здравствуйте, VladD2, Вы писали:
TBG>>Да нет, просто переташил бы AST, а дальше что там написалось — все само! VD>АСТ разных языков не совместимы. Или это уже один язык у которого заменили синтаксис скобой.
Да ладно? И чем же они не совместимы? Тем, что АСТ функции, класса имеют другой класс? По сути все одно и то же.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я имел в виду только тот факт, что VS IDE есть .Net приложение. А на чем ее писали — естественно, я сказать не могу. Рефлектор, если захочешь, тебе и Delphi код ее покажет . Вполне допускаю, что там и unmanaged кода полно.
For those of you that refuse to believe, here's an estimate of the lines of managed code in Microsoft applications that I got permission to blog about:
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Да ладно? И чем же они не совместимы? Тем, что АСТ функции, класса имеют другой класс? По сути все одно и то же.
Как называется конструкция AST в С++ выражающая окамловский case? Подсказка, switch не способен ее заменить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Turtle.BAZON.Group wrote:
> VD>Как называется конструкция AST в С++ выражающая окамловский case? > Подсказка, switch не способен ее заменить. > > Я про языки одной парадигмы говорил. Да и это частности. Если > программировать в AST, то всякий зоопарк языков отпадет сам собой.
Наивный взгляд. Вы, видимо, не знаете несколько абсолютно разных языков (например, erlang и C++). Помимо синтаксиса (а
это и есть Abstract Syntax Tree) язык ещё представляется семантикой (ещё прагматика есть, но тут не в тему). И
невозможно семантически разные конструкции сводить к ast.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Вышла новая статья о закономерностях в программировании. Приведу несколько выдержек из нее:
Статью прочёл. Она мне, как обычно это бывает со статьями ТРИЗовцев о программировании, не понравилась. Уж не обессудьте, слишком много у вас там наивного.
КЛ>"При этом каждое следующее серьезное изобретение в области программирования — это почти всегда изобретение следующего интерфейса (это и есть «этаж») между системными «слоями»:
КЛ>
КЛ>Изобретение операционной системы — это изобретение интерфейса между машиной и приложениями. Операционная система инкапсулирует в себе соотв. функции.
Не совсем так. Это вытеснение некоторого функционала за пределы приложений. Задачи вполне естественны: развязать процессы разработки самого компьютера и приложений.
КЛ>Изобретение языков программирования (например, ассемблера) — это изобретение интерфейса между кодом и человеком. Язык инкапсулирует в себе код.
Прежде всего, языком выражается семантика сущностей, которые человек выделил в решаемой задаче.
КЛ>Изобретение языков более высокого уровня – то же самое на следующей стадии.
Языки высокого уровня нужны, прежде всего, для того, чтобы их мог легко понимать человек. Сравни, например:
a = a + 1;
и
mov ax, [a]
inc ax, 1
mov [a], ax
Первый пример написан в терминах, близких к математическим. Второй — в терминах, близких к компьютеру. Человеку, получившему математическую подготовку проще оперировать терминами, близкими к первому примеру.
КЛ>Изобретение объектно-ориентированного программирования – это попытка создать интерфейс между функциями ("методами") и разработчиком.
Вот конкретно это утвержение весьма наивно.
Это шумное направление (ООП) родилось как ублюдок от работ по искусственному интеллекту, сугубо прагматическим подходом к представлению знаний (фрейм-слот) и стремления общаться с компьютером на языке, близком к естественному. Соответственно, ООП предоставило в руки разработчиков средство, благодаря которому они смогли инкапсулировать сложную семантику в компактном наборе терминов, сиречь — классов (или типов). Важно, что при этом была сглажена естественная для компьютерных языков дихотомия: действие-данные. Я уверен, что не все это понимали в "историческом контексте", но тот, кто хотя бы в процессе обучения долго общались с формальными системами (например — с математикой), быстро этот момент "просекли". А дальше многообразие "паттернов" объектного программирования выросло из пересечения прикладных и сугубо системных семантик. Под системными семантиками я имею ввиду принципы работы компьютера.
По сути же это сдача позиций перед лицом сложности формальной обработки естественного языка. Хотя и вполне закономерная: прежде, чем что-то анализировать, необходимо создать базис, на который будет разлагаться анализируемое. Поскольку зашить всё многообразие вывертов естественного языка в машинную память пока не представляется возможным, необходим некий конструктивный базис для построения соответствующих терминов. Шаблоны (обобщённые конструкции) как раз часть этого базиса.
КЛ>Поэтому нынешнее явление миру «шаблонно-ориентированного программирования» [12, стр 163] — совершенно закономерный надсистемный переход от «объектов» и «классов» к их готовым контекстным сочетаниям.
КЛ>Наверное, закономерен и дальнейший переход от «мышления отдельными шаблонами» к мышлению их готовыми сочетаниями (готовыми надсистемами из шаблонов). Давайте назовем эти готовые сочетания шаблонов «стилями». И тогда будет переход к «стильному программированию»".
Возможно. Только сложность компоновки этих самых "готовых сочетаний" друг с другом быстренько возвращает разработчика на э... уровень "ассемблера" самих агрегатов. Это тоже вполне закономерно. В какой-то степени, иллюстрацию этого явления можно увидеть, например, в процессе конструирования механических конструкций. Да, у нас есть, условно, говоря, мотор и условно говоря — рама. Осталось их состыковать. А вот выполняя состыковку нужно уже вспомнить о чистом ассемблере: типоразмерах болтов, их прочностных характеристиках, о положении центра тяжести двигателя, допустимых скручиваниях и изгибах рамы и т.п.
Говоря же о "переходах мышления в программировании", уместнее вспоминать не столько о самой модификации мышления, сколько об изменении номенклатуры товаров. Вчера продавали утилиты, сегодня продаётся ещё и "обучение стилю мышления". Отсюда и меняющиеся buzzwords.
КЛ>
КЛ>"Вспомним «эволюцию языков программирования»:
КЛ>
КЛ>Вначале были «нули и единицы»
Вернее — тумблеры и лампочки.
КЛ>Позже произошел первый надсистемный переход: «нули и единицы» сгруппировались в «мнемоники» — часто повторяющиеся готовые сочетания «нулей и единиц», например, для команды пересылки данных – MOV, для команды сложения – ADD и т.п. Т.е. появились «ассемблеры» [8].
КЛ>Заметим: мнемоники, как бы сказали теперь, «инкапсулировали» (закрыли) «нули и единицы» от программиста. Стали «интерфейсом» между программистом и «нулями».
Проблема не в том, что именно было прикрыто. Вопрос: зачем? Ответ: чтобы приблизить "машинный" язык к человеческому. Поэтому и произошёл переход от тумблеров к мнемоникам.
КЛ>Затем произошел второй надсистемный переход: «простые ассемблеры» заместились «макроассемблерами», которые могли оперировать уже «группой мнемоник». И в этом смысле их стали называть «более мощными» [9]. КЛ>Затем произошел третий надсистемный переход: «языки высокого уровня» вытеснили в узкую нишу «ассемблеры» и «макроассемблеры». КЛ>И здесь надо отметить сразу два «надсистемных эффекта»:
КЛ> КЛ>Каждая инструкция языка высокого уровня стала «еще мощней», т.е. компилировалась «сразу в десятки машинных команд». КЛ>Инструкция языка высокого уровня понималась целиком, а операторы, входящие в инструкцию сами по себе (вне ее контекста), не имели смысла. Подобно тому, как в литературе обладают своим смыслом целиком фраза или стихотворение, а слова, их образующие, этим смыслом не обладают [9].
КЛ>В результате исчезло соответствие между теми командами, которые пишет программист, и теми командами, которые исполняет процессор. КЛ>Как известно, это позволило создавать языки, «заточенные» под предметную область:
Главным образом, в это время научились формально переводить "околоестественный" язык в машинный. Это я о теории трансляции. КЛ>
Кроме того, есть ещё и третий "надсистемный эффект". Это был первый и последний раз в истории компьютеризации, когда производительность программистов на задачах "общего характера" выросла в несколько раз из-за простого изменения инструментального средства. Всё. Больше этого чуда не повторялось, хотя спекуляции продолжаются по сей день. Инструментарий, данный средствами ООП позволил ещё несколько подтянуть эту самую пресловутую производительность, но дальше всё упёрлось в семантические характеристики проектируемой системы, в анализ предметной области и т.п. А потому "старое" структурное программирование вполне успешно может соперничать с ООП, при соответствующем проектировании.
КЛ>
КЛ>Фортран – для решения инженерных задач и научных расчетов.
[...] КЛ>Ада – для моделирования параллельного решения задач. [7] КЛ>
КЛ>Изобретение языков высокого уровня позволило осуществлять перенос программы с машины на машину. И это позволило программисту (пишущему на высоком уровне) «не знать» или «знать минимально» устройство машины. Как бы сказали теперь, эти языки «инкапсулировали» (закрыли) «устройство машины» от программиста. Стали «интерфейсом» между программистом и компьютером.
Вот ещё один пример передёргивания. ЯВУ как раз и разрабатывались в частности для того, чтобы обеспечить переносимость программ. Соответственно, "переносимость" возникла не сама собой, как следствие некоего удивительного надсистемного перехода, а как вполне закономерное явление — ведь эту-то задачу как раз и решали! Решали путём нахождения компромисса между близостью к естественному языку и возможностью выполнения на компьютере программы, записанной на таком языке.
КЛ>Затем произошел четвертый надсистемный переход: «структурное программирование» вытеснило «линейное». Программа стала пониматься как группа (читай: «надсистема») модулей, которые можно писать отдельно, а проектирование в значительной степени стало пониматься как проектирование интерфейсов для общения модулей. КЛ>Затем произошел пятый надсистемный переход: … впрочем, дальнейшую логику вдумчивый Читатель продолжит сам." КЛ>
Конкретно эту "логику" лучше не продолжать. Например, структурное программирование к "модулям" имеет весьма опосредованное отношение. Ключевое понятие здесь: структурные блоки графа управления. Представление их в виде модулей (в частном случае — процедур, функций...) — уже отдельный вопрос.
Собственно говоря, чем страдают статьи по программированию от ТРИЗовцев (и не только от них, но о других авторах чуть ниже), так это абстрагированием от целей рассматриваемых процессов. Читая вас, у меня, например, складывается впечатление, что программирование — это такой монстр, который растёт как-то сам по себе, вне требований пользователей, способностей аналитиков, и вообще — культурного контекста. На самом же деле это совсем не так.
Глобальную задачу — научить компьютер общаться с человеком на естественном языке, — человечество так пока ещё и не решило. Хотя на этом пути отвалилось немало любопытных артефактов: языки высокого уровня, объектное програмирование, машинная лингвистика и т.п. Если их рассматривать по отдельности, или даже вместе, но тем не менее вне контекста этой самой глобальной задачи, то можно наплодить удивительное количество химеричных "аналитических" выводов. Что, собственно, я и вижу в ваших статьях, когда они касаются програмирования. Для сравнения поглядите в этом форуме, здесь иногда появляются студенты, с приблизительно такой же моделью рассуждений: берём артефакт А, артефакт Б и строим от них Глобальную Индукцию Развития Вселенной. Но то студенты, им простительно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, ., Вы писали:
.>Наивный взгляд. Вы, видимо, не знаете несколько абсолютно разных языков (например, erlang и C++). Помимо синтаксиса (а
Наивное предположение...
.>это и есть Abstract Syntax Tree) язык ещё представляется семантикой (ещё прагматика есть, но тут не в тему). И .>невозможно семантически разные конструкции сводить к ast.
В общем случае нельзя. При частных приближениях — можно. Это если к этому стремиться.
Turtle.BAZON.Group wrote:
> .>это и есть Abstract *Syntax* Tree) язык ещё представляется семантикой > (ещё прагматика есть, но тут не в тему). И > .>невозможно семантически разные конструкции сводить к ast. > В общем случае нельзя. При частных приближениях — можно. Это если к > этому стремиться.
Ну если использовать только какой-то пересекающийся набор фич двух языков, то ещё можно со скрипом. Да даже с языками
которые специально так создавались — С и С++ — и то есть проблемы.
Только смысл от этого? Зачем использовать другой язык, если запрещено использовать его фичи?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>которые специально так создавались — С и С++ — и то есть проблемы. .>Только смысл от этого? Зачем использовать другой язык, если запрещено использовать его фичи?
Ну потому как зоопарк возник, нет обобщенного AST, то смысла нет.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Собственно говоря, чем страдают статьи по программированию от ТРИЗовцев (и не только от них, но о других авторах чуть ниже), так это абстрагированием от целей рассматриваемых процессов.
Цель как раз ясна — создавать устойчивые к изменениям архитектуры.
ГВ>Глобальную задачу — научить компьютер общаться с человеком на естественном языке, — человечество так пока ещё и не решило.
На самом деле, это такой миф про естественный язык. Никаких естественных языков, которые "естественнее" всех остальных, в природе не существует. Существуют языки, заточенные под решение определенных классов задач. Так для счета мы используем язык арифметики. Три тысячи лет назад люди для обозначения чисел и операций над ними тоже использовали естественный язык. Каждое число обозначалось отдельным словом. Получалось неэкономно. Попробуйте-ка вычислить: "Триста восемьдесят семь плюс пятьсот девяносто восемь" без использования арабских цифр, позиционной системы счисления и правила сложения в столбик! "Естественный" язык (а правильнее его называть — разговорный) очень плох для решения таких задач. Поэтому-то древние и изобрели цифры и позиционную систему счисления. Т.е. был изобретен язык, который приспособлен для счета.
Точно так же и с другими областями человеческой деятельности. Попробуйте-ка написать программу уровня Microsoft Word на естестественном языке. Полагаю, еще та задачка. Не случайно, авторы ряда фундаментальных книг по алгоритмам и структурам данных как только дело доходит до описания алгоритмов, предпочитают псевдокод. А некоторые продвинутые товарищи изобретают даже собственные языки программирования — специально для записи алгоритмов.
Turtle.BAZON.Group wrote:
> .>которые специально так создавались — С и С++ — и то есть проблемы. > .>Только смысл от этого? Зачем использовать другой язык, если запрещено > использовать его фичи? > Ну потому как зоопарк возник, нет обобщенного AST,
Ну почему — есть и такая штука, обобщённое AST на "все случаи жизни" — это XML.
>то смысла нет.
Ты хочешь общую теорию всего? Это невозможно сделать. Потому и смысла нет. Для языка программирования синтаксис играет
относительно незначительную роль.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Вышла новая статья о закономерностях в программировании.
Идея о такой закономерности приходит каждому мало-мальски размышляющему программисту в первые года 3 программистской деятельности. Только вот на практике все намного сложнее, печальнее и запутаннее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Идея о такой закономерности приходит каждому мало-мальски размышляющему программисту в первые года 3 программистской деятельности.
Вы, очевидно, имели в виду, что у меня мало опыта. Краткая справка:
Мой опыт работы в коммерческом программировании — 11 лет.
Количество реализованных проектов — больше 20.
Мелкие проекты и учебу в институте сюда не включаю.
Сейчас работаю с коллегами, которые в индустрии как раз три года или около того. Нельзя сказать, что они неразмышляющие. Размышляют и еще как. А вот закономерности, к сожалению, не ловят. И качество своей работы, к сожалению, тоже повышать не хотят. Любое улучшение идет с большим скрипом.
AVK>Только вот на практике все намного сложнее, печальнее и запутаннее.
Пожалуйста, приведите пару-тройку примеров "сложного, печального и запутанного". Мы в своей статье примеры приводим и разбираем их достаточно подробно. Поэтому, думаю, вправе требовать этого же и от тех людей, которые статью критикуют.
Hello, VladD2!
You wrote on Thu, 01 Feb 2007 23:05:29 GMT:
XC>>> А пока я невооруженным глазом (!) по скорости открывания меню XC>>> и диалогов определяю, написан ли софт на Java, каком-либо XC>>> managed-языке .NET, или под реальный процессор, пишу на C++. XC>>> Хотя уже достало WH>> Жаба да. .NET извини не поверю.
V> А что Жаба? Ты ИДЕЮ видел? Многие кто ею пользовался утверждают, V> что она работает вполне быстро.
Работала. Ухудшаться ситуация начала версии с пятой, в шестой тормоза порою начинают доставать.
Здравствуйте, ., Вы писали:
>> Ну потому как зоопарк возник, нет обобщенного AST, .>Ну почему — есть и такая штука, обобщённое AST на "все случаи жизни" — это XML.
Ага. Только тоже имеет те же проблемы с семантикой.
.>Ты хочешь общую теорию всего? Это невозможно сделать. Потому и смысла нет. Для языка программирования синтаксис играет .>относительно незначительную роль.
Склонен к обобщениям. Сделать то как раз возможно. Вот только смысла нет, потому как никому не надо.
Здравствуйте, Кирилл Лебедев, Вы писали:
AVK>>Идея о такой закономерности приходит каждому мало-мальски размышляющему программисту в первые года 3 программистской деятельности.
КЛ>Вы, очевидно, имели в виду, что у меня мало опыта.
Нет.
AVK>>Только вот на практике все намного сложнее, печальнее и запутаннее.
КЛ>Пожалуйста, приведите пару-тройку примеров "сложного, печального и запутанного".
некоторые вещи упоминаются. Думаю, этого более чем достаточно, чтобы понять, что при увеличении стройная и примитивная картинка распадается на детали.
КЛ> Мы в своей статье примеры приводим и разбираем их достаточно подробно. Поэтому, думаю, вправе требовать этого же и от тех людей, которые статью критикуют.
Я статью не критикую, я намекаю на то, что идея в этой статье стара как мир.
Здравствуйте, ., Вы писали:
>> Ну потому как зоопарк возник, нет обобщенного AST, .>Ну почему — есть и такая штука, обобщённое AST на "все случаи жизни" — это XML.
Здравствуйте, Кирилл Лебедев, Вы писали:
ГВ>>Собственно говоря, чем страдают статьи по программированию от ТРИЗовцев (и не только от них, но о других авторах чуть ниже), так это абстрагированием от целей рассматриваемых процессов.
КЛ>Цель как раз ясна — создавать устойчивые к изменениям архитектуры.
Я бы обозначил так: ещё одна цель. Ещё одна в целом ряду целей, для достижения которых разрабатывались ЯП: обучение, символьная обработка, доказательство теорем, системное программирование и т.п.
ГВ>>Глобальную задачу — научить компьютер общаться с человеком на естественном языке, — человечество так пока ещё и не решило.
КЛ>На самом деле, это такой миф про естественный язык. Никаких естественных языков, которые "естественнее" всех остальных, в природе не существует.
Ну, я, к сожалению, не лингвист, так что квалифицированно поддержать тему о естественных языках не смогу. Выскажу только несколько соображений:
КЛ>Существуют языки, заточенные под решение определенных классов задач. Так для счета мы используем язык арифметики. Три тысячи лет назад люди для обозначения чисел и операций над ними тоже использовали естественный язык. Каждое число обозначалось отдельным словом. Получалось неэкономно. Попробуйте-ка вычислить: "Триста восемьдесят семь плюс пятьсот девяносто восемь" без использования арабских цифр, позиционной системы счисления и правила сложения в столбик!
Думаю, что само числительное "триста" (или какой-либо его прямой семантический аналог) не появилось бы без предварительного появления системы счисления как таковой. То есть тут налицо впитывание разговорным языком специальной "математической" нотации. Впрочем, повторюсь, что я — не лингвист.
КЛ>"Естественный" язык (а правильнее его называть — разговорный) очень плох для решения таких задач. Поэтому-то древние и изобрели цифры и позиционную систему счисления. Т.е. был изобретен язык, который приспособлен для счета.
Опять таки, думаю, что дело здесь было в необходимости что-то посчитать. Отсюда и появилась система обозначений чисел и операций над ними.
КЛ>Точно так же и с другими областями человеческой деятельности. Попробуйте-ка написать программу уровня Microsoft Word на естестественном языке. Полагаю, еще та задачка. Не случайно, авторы ряда фундаментальных книг по алгоритмам и структурам данных как только дело доходит до описания алгоритмов, предпочитают псевдокод. А некоторые продвинутые товарищи изобретают даже собственные языки программирования — специально для записи алгоритмов.
Вот в этом абзаце что-то логическую связь улавливаю плохо. Да, Word, наверное, трудновато сформулировать на разговорном языке. Но его вполне можно выразить на ассемблерных мнемониках. И кроме того, некорректно упоминать Word в контексте обсуждения мутаций языков програмирования: он появился тогда, когда "культура" обозначений в языках программирования уже достаточно устоялась. А в то время, когда изобретались первые обозначения "mov", "add" и прочие подобные, задачи WYSIWYG-редактора ещё не стояло.
Что касается алгоритмов, то они тоже, в принципе, далековаты от естественных языков — это сугубо формальное понятие (если на время забыть о забавной игре слов — "неформальном описании алгоритма"). Отсюда и вполне естественное появление специальных формальных языков для выражения алгоритмов.
Мне кажется, что интерес в даном случае представляют соображения, по которым, например команде пересылки данных было присвоено какое-то мнемоническое обозначение, а не остановились на каком-нибудь восьмиричном: "1352". И вот что любопытно. Переход от восьмиричного кода к мнемоникам является "надсистемным" (а параллельно — "освежающим") только тогда, когда мы ограничиваем, не побоюсь этого слова, само мышление имеющейся системой символов (весь этот ворох восьмиричных кодировок). А если предположить, что мотивом такого перехода является именно желание выразить программу на языке, близком к естественному, то и переход окажется вполне закономерным, а символ "1352" — так себе, промежуточный этап.
Другой инетерсный интересный аспект. Переход к мнемоникам (т.е., первый шаг на пути приближения компьютерных языков к человеческим) — это почти раскупорка ящика Пандоры! Человек первый раз позволил себе подтянуть компьютерный язык к естественному со всем многообразием конструктивных возможностей последнего.
Когда, например, один монтёр говорит другому: "Ну ни х... себе, как его пожгло! Будем перекидывать концы." другому ясно, что первый сказал о том, что переключатель №9, марки ТВ-1-15-М покрылся нагаром из-за плохих контаков, что, вероятно, означает, что выключатель давно не меняли и прямо сейчас придётся менять разводку и выполнить ещё целую кучу вполне определённых действий. Вот он, ключ к паттернам, шаблонам и прочей программистской ерунде — все эти "техники" уже давным давно используются в обычной устной речи. Таким образом, дальнейшие эволюционные прыжки языков программирования становятся вполне объяснимыми — почва для них была уже давно подготовлена тысячелетиями эволюции систем символов. А нынешнее быстрое развитие языков и технологий программирования обусловлено тем, что программисты и компьютерные учёные попросту переводят этот опыт (в квинтэссенции которого они живут!) в формализованные конструкции языков програмирования. Порой, как мне кажется, даже не осознавая этого влияния. То есть, оказывается, что и изобретать-то ничего не нужно (эк, загнул!), всё и так уже есть, надо только посмотреть повнимательнее. То есть — прислушаться.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, ., Вы писали:
.>Ну почему — есть и такая штука, обобщённое AST на "все случаи жизни" — это XML.
Угрёбище редкостное этот самый XML.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>То есть, оказывается, что и изобретать-то ничего не нужно (эк, загнул!), всё и так уже есть, надо только посмотреть повнимательнее. То есть — прислушаться.
Вот, кстати, объяснение, почему программистам полезно общаться с искусством: чтобы перенимать опыт выразительности символического отражения действительности. Таким образом сходятся рассуждения об "искусстве", "эстетике", "культуре" и "технологии" программирования. Вуаля!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Turtle.BAZON.Group wrote:
>> > Ну потому как зоопарк возник, нет обобщенного AST, > .>Ну почему — есть и такая штука, обобщённое AST на "все случаи жизни" — > это XML. > Ага. Только тоже имеет те же проблемы с семантикой.
О какой ты семантике говоришь при обсуждении Abstract Syntax Tree?..
> .>Ты хочешь общую теорию всего? Это невозможно сделать. Потому и смысла > нет. Для языка программирования синтаксис играет > .>относительно незначительную роль. > Склонен к обобщениям. Сделать то как раз возможно.
Как ты себе это представляешь?
> Вот только смысла нет, потому как никому не надо.
Ну раз любишь обобщать, значит тебе это надо. Вот и делай.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Геннадий Васильев wrote:
> .>Ну почему — есть и такая штука, обобщённое AST на "все случаи жизни" — > это XML. > > Угрёбище редкостное этот самый XML.
Зато работает.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
>> Угрёбище редкостное этот самый XML. .>Зато работает.
Крокодилы — тоже летают.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Геннадий, в своем сообщении Вы повторяете мысли, изложенные в нашей статье, только другими словами. Сравните сами.
Вы пишите: ГВ>"Проблема не в том, что именно было прикрыто. Вопрос: зачем? Ответ: чтобы приблизить "машинный" язык к человеческому. Поэтому и произошёл переход от тумблеров к мнемоникам".
Мы пишем: "Заметим: мнемоники, как бы сказали теперь, «инкапсулировали» (закрыли) «нули и единицы» от программиста. Стали «интерфейсом» между программистом и «нулями».
Вы пишите: ГВ>"Не совсем так. Это вытеснение некоторого функционала за пределы приложений. Задачи вполне естественны: развязать процессы разработки самого компьютера и приложений".
Мы пишем: "Изобретение операционной системы — это изобретение интерфейса между машиной и приложениями. Операционная система инкапсулирует в себе соотв. функции".
В чем разница? Вы написали то же самое, но при этом зачем-то попеняли.
. При этом, делается попытка противопоставить позаимствованные у нас мысли тому, что написано в статье.
Содержит сомнительную мысль по поводу естестественных языков. (Почему сомнительную? См. здесь
Кроме того, как у разработчика, у Вас наверняка есть свои примеры, когда применение данной закономерности на практике не срабатывает. Не думаю, что свой вывод Вы делали только со слов Геннадия.
Так что для того, чтобы действительно разобраться в том, почему на практике все "печальнее и запутаннее", нужно рассмотреть конкретные примеры. К сожалению, специфика любой исследовательской работы заключается в том, что исследователь оперирует фактами, а не мнениями. Мнения, не подкрепленные фактами, к сожалению (или, к счастью?) не играют никакой роли.
AVK>Я статью не критикую, я намекаю на то, что идея в этой статье стара как мир.
Новизна статьи заключается не в описании закономерности, а в демонстрации примеров, как данная закономерность может быть применена на практике.
. При этом, делается попытка противопоставить позаимствованные у нас мысли тому, что написано в статье. КЛ>Содержит сомнительную мысль по поводу естестественных языков. (Почему сомнительную? См. здесь
.) КЛ>
Не надо обсуждать здесь весь пост целиком. Ты просил примеров? В том посте примеры есть. Остальные притензии, плиз, к автору.
КЛ>Никаких примеров в посте не приводится.
А я думаю что приводятся. И автор со мной согласен, что характерно.
КЛ>Кроме того, как у разработчика, у Вас наверняка есть свои примеры, когда применение данной закономерности на практике не срабатывает.
Эту закономерность на практике вот так прям сразу применить нельзя, слишком она абстрактна.
КЛ>Так что для того, чтобы действительно разобраться в том, почему на практике все "печальнее и запутаннее", нужно рассмотреть конкретные примеры.
Конкретные примеры чего? На абстрактные мысли о нарастании абстракции сложновато привести конкретные примеры, не находишь?
КЛ> К сожалению, специфика любой исследовательской работы заключается в том, что исследователь оперирует фактами, а не мнениями. Мнения, не подкрепленные фактами, к сожалению (или, к счастью?) не играют никакой роли.
Тогда ты ошибся форумом. В этом форуме большей частью оперируют мнениями.
AVK>>Я статью не критикую, я намекаю на то, что идея в этой статье стара как мир. КЛ>Новизна статьи заключается не в описании закономерности, а в демонстрации примеров, как данная закономерность может быть применена на практике.
Возможно, я не ясно выделил акценты. Я пишу о мотивациях и том, что о них необходимо упоминать, коли речь идёт об изобретениях. Иначе оценка явления становится однобокой.
КЛ>Вы пишите:
Кстати, можно на "ты", если не возражаете.
ГВ>>"Проблема не в том, что именно было прикрыто. Вопрос: зачем? Ответ: чтобы приблизить "машинный" язык к человеческому. Поэтому и произошёл переход от тумблеров к мнемоникам".
КЛ>Мы пишем: "Заметим: мнемоники, как бы сказали теперь, «инкапсулировали» (закрыли) «нули и единицы» от программиста. Стали «интерфейсом» между программистом и «нулями».
Ну, по-моему, разница между этими абзацами очевидна: в первом случае вводится некая сущность, достаточная для обоснования перехода (я не утверждаю, что это соображение непременно было единственным). Второй же случай демонстрирует только переход сам по себе. И становится непонятно: а почему, собственно? Просто ради введения дополнительного интерфейса? Просто так, чтобы отвязать программиста от нулей и единиц? чём смысл введения дополнительной сущности "мнемоника"? Программист и так прекрасно проживёт — никогда не встречали людей, которые с лёгкостью оперируют шестнадцатеричными кодами? Я встречал.
КЛ>Вы пишите: ГВ>>"Не совсем так. Это вытеснение некоторого функционала за пределы приложений. Задачи вполне естественны: развязать процессы разработки самого компьютера и приложений".
КЛ>Мы пишем: "Изобретение операционной системы — это изобретение интерфейса между машиной и приложениями. Операционная система инкапсулирует в себе соотв. функции".
КЛ>В чем разница?
Возражение ровно то же самое, что и в первом случае. Вы выдёргиваете переход из причино-следственного контекста. Создаётся впечатление некой данности, случайности или "озарения", а не вполне закономерного перехода.
По содержанию здесь возразить нечего, ОС и в самом деле инкапсулирует определённые функции управления компьютером. Но отвязавшись от "постановки задачи" в виде вытеснения общей функциональности, мы неправомерно (на мой взгляд) оцениваем появление ОС как надсистемный переход. Скорее это просто оформление устоявшейся практики — предварительно были "мониторы", "супервизоры", что-то там ещё подобное. Да в конце концов, просто подпрограммы. То есть, появлению ОС именно как "ОС" предшествовала некоторая история удачных и неудачных решений, а операционная система уже вполне логично выкристаллизовалась из этих попыток.
Кстати, я упомянул подпрограммы — вот это, наверное, можно считать изобретением, хотя... Оно было сделано чуть ли не Адой Лавлейс.
И когда раз за разом встречаешь такую потерю обоснования, то и складывается неприятное впечатление от статьи: на базе непонятно как рассмотренных явлений делаются опять-таки непонятно насколько правомерные индукции (в несколько более резкой форме — "химеричные").
Например, называть ООП попыткой "создать интерфейс между функциями ("методами") и разработчиком", а после этого ещё и чем-то, достойным рассмотрения как надсистемный переход, попросту неверно. Об истоках ООП я уже упоминал, изначально речь там шла о фиксации знаний, дальше поищите сами по ключевым словам "фрейм-слот" (кстати, термин слот до сих фигурирует в Common Lisp). А дальше был просто активный маркетинг и свою роль сыграла определённая падкость программистской общественности до мифов. Опять таки, демографическая ситуация — пришло молодое поколение тех же программистов. Впрочем, всё это не умаляет и объективных достоинств декомпозиции в стиле ООП.
У вас же это подаётся в каком-то странном виде. Грубоватая аналогия. Были стенка, гвоздьи желание повесить картину на стенку. Был опыт забивания гвоздей и подвешивания картин. Забили гвоздь в стену, повесили картину. "Опс, — говорит автор статьи, — были стенка и гвоздь, и произошёл надсистемный переход к стенке-с-гвоздём! Значит дальше, вероятно, будет переход к стенке-с-многими-гвоздями!" Ну и таких урезанных наблюдений и фантастических предположений полна статья.
У вас на сайте есть запомнившийся мне пример с двумя баржами. Помните, вероятно, о том, как дополнительной вставкой между носовыми оконечностями сильно улучшили гидродинамику связки? Здесь как раз всё понятно: ввели новую сущность, которая не имела прямых аналогов в практике: составные суда в общем, в диковинку. То бишь, в этом примере есть всё, необходимое для читателя, чтобы он оценил изобретение, как изобретение. Понимаете разницу?
КЛ>Вы написали то же самое, но при этом зачем-то попеняли.
Дело в том, что изобретательская (как и любая иная) задача сама по себе невозможна без какой-то мотивирующей потребности. Если связать потребность, имеющийся инструментарий и решение, то становится ясным — почему решение выбрано именно такое, а не какое-то иное. И кроме того — в чём же состоит суть изобретения и как можно подкорректировать своё мышление, чтобы научиться "творчески думать". А в вашей статье как раз задача либо выпадает, либо интерпретируется не полно — пусть читатель, мол, додумает сам. Вот я и додумал, прихватив с собой бритву Оккама: если можно объяснить явления одной сущностью, то нет смысла вводить другие.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>А в вашей статье как раз задача либо выпадает, либо интерпретируется не полно...
Я имею ввиду фрагмент, процитированный вами на RSDN, где вы касаетесь истории программирования. По основному тексту статьи тоже есть возражения, о них — позже.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, ., Вы писали:
.>Turtle.BAZON.Group wrote:
>> Ага. Только тоже имеет те же проблемы с семантикой. .>О какой ты семантике говоришь при обсуждении Abstract Syntax Tree?..
А если Abstract, то почему нет обобщения?
ПС: ладно, тема зашла в тупик. Было приятно пообщаться.
Здравствуйте, Геннадий Васильев, Вы писали:
.>>Ну почему — есть и такая штука, обобщённое AST на "все случаи жизни" — это XML. ГВ>Угрёбище редкостное этот самый XML.
Ну степень редкостности, конечно, сложно оценить... Но все равно .
В своих постах я к Вам обращаюсь на Вы. Прошу и Вас так же придерживаться этого правила вежливого общения.
AVK>Не надо обсуждать здесь весь пост целиком. Ты просил примеров? В том посте примеры есть. Остальные притензии, плиз, к автору.
По прежнему не вижу там примеров, которые бы подтвержали Вашу мысль: "Только вот на практике все намного сложнее, печальнее и запутаннее".
AVK>А я думаю что приводятся. И автор со мной согласен, что характерно.
Тогда, пожалуйста, скопипейстите их в Ваш ответ.
AVK>Конкретные примеры чего? На абстрактные мысли о нарастании абстракции сложновато привести конкретные примеры, не находишь?
Вот статья. В ней разобраны три примера: пример 1, пример 2 и пример 3. Если Вам непонятно, как закономерность, описанная в конце статьи, соотносится с примерами, Вы можете обратиться к разделу "Чем "исторические примеры" похожи на три предыдущих" или спросить. Но для этого должно быть желание разобраться .
Здравствуйте, AndrewVK, Вы писали:
КЛ>>В своих постах я к Вам обращаюсь на Вы. Прошу и Вас так же придерживаться этого правила вежливого общения.
AVK>Просьба принята во внимание, однако не удовлетворена.
Ваш ответ, как и ряд предыдущих Ваших постов, нарушает 5-ое правило поведения на форумах:
"Не допускается проявление грубого или неуважительного отношения к другим участникам форума. Оскорблять и обзывать собеседника, ставить под сомнение его профессиональную квалификацию, придираться к его нику, указывать на орфографические и синтаксические ошибки и т. д. запрещается". http://www.rsdn.ru/Info/rules.xml
Если Вы и дальше не будете принимать в расчет мою просьбу о вежливом обращении, я оставляю за собой право обратиться к администрации сайта.
КЛ>Если Вы и дальше не будете принимать в расчет мою просьбу о вежливом обращении, я оставляю за собой право обратиться к администрации сайта.
самое простое в таких случаях — не отвечать. вообще или только на неустраивающие тебя письма. есть научно-плпулярная книжка по бихевиоризму "не рычите на собаку!", в которой подробюно описаны принципы формирования поведения с помощью подкреплений. в частности, система оценок писем этого форума — удачный пример использования подкреплений. к сожалению, больше нигде я такого не встречал
Здравствуйте, Кирилл Лебедев, Вы писали:
AVK>>Просьба принята во внимание, однако не удовлетворена.
КЛ>Ваш ответ, как и ряд предыдущих Ваших постов, нарушает 5-ое правило поведения на форумах:
Понятно, еще один. Значит так, поясняю еще раз — здесь есть некие общепринятые правила поведения. Одно из них — тут в основном общаются на ты и никто ради тебя одного это менять не будет. Ну то есть попросить ты имеешь право, но точно так же тебе имеют право отказать. Этот вопрос уже миллион раз здесь обсуждался. Если тебе не нравятся наши порядки, у тебя всегда есть право вобще не использовать rsdn. Все, вопрос закрыт. Дальнейшее обсуждение только на moderator@rsdn.ru
P.S. Тут народ весьма опытный в дисскуссиях, так что подобные приемчики как правило не проходят. Да и модераторы иногда не дремлют.
... << RSDN@Home 1.2.0 alpha rev. 673 on Windows Vista 6.0.6000.0>>
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Если Вы и дальше не будете принимать в расчет мою просьбу о вежливом обращении, я оставляю за собой право обратиться к администрации сайта.
Блин, так требовать изменить под себя правила форума, с которыми большинство соглашается, и которые уже не раз обсуждались можно рассматривать как пример неуважительного отношения к другим участникам форума с ВАШЕЙ стороны.
Не нравится конкретно человек, так что мешает просто не отвечать ему или найти портал наследников благородных кровей , где обращение не унижает ВАШИ моральные устои, или мы действуем согласно принципу:
Здравствуйте, Кирилл Лебедев, Вы писали:
AVK>>Конкретные примеры чего? На абстрактные мысли о нарастании абстракции сложновато привести конкретные примеры, не находишь?
КЛ>Вот статья. В ней разобраны три примера: пример 1, пример 2 и пример 3. Если Вам непонятно, как закономерность, описанная в конце статьи, соотносится с примерами, Вы можете обратиться к разделу "Чем "исторические примеры" похожи на три предыдущих" или спросить.
Уж поверьте на слово: и прочитал, и разобрался. Продемонстрированная закономерность представляется мне, мягко говоря, упрощённой оценкой практики программирования. Ну, если опять-таки прибегнуть к грубоватой аналогии, то нельзя выводить подобие грузовика и, например, кирпича, только потому, что и там и там имеется образующий параллелепипед. Или ещё проще — Холмогоры не восходят этимологически к Гомгардии ((c) к/ф "Ломоносов"). Один (всего лишь один, зато какой!) упущенный аспект в мотивации я уже показал. А чтобы написать полный разбор полётов потребуется слишком много времени.
КЛ>Но для этого должно быть желание разобраться .
В чём разбираться? В закономерности, выделенной на основании поверхностного анализа, когда эта поверхностность видна невооружённым глазом? Вам знаком тезис, что любая проблема программирования может быть решена введеним дополнительного уровня абстракции, за исключением проблемы слишком большого количества уровней абстракции? Заметьте, сказано это остаточно давно, чтобы уже стать притчей во языцех. А вы тут пытаетесь нам "продать" этот же рецепт, но под лозунгом ТРИЗ. И кто тут кого обманывает?
AndrewVK совершенно прав, когда говорит, что такие мысли приходят почти каждому программисту в первые три года работы. И здесь я его дополню, что почти каждый же начинает их подавать с не меньшим апломбом и претензией на открытие закона "всех явлений видимых, яко же и глазу неподвластных". Одобрение коллег, правда, такие персонажи зачастую заслуживают только благодаря тому, что демонстрируют самостоятельное мышление (это довольно-таки редкое явление, представляющее самостоятельную ценность), а отнюдь не в силу "глубины" изысканий. Понимаете разницу, да?
Отдельный момент — это обсуждение применимости ТРИЗ к программированию вообще. Понимаете ли, в чём дело, вводить в рассуждения и в модели новые сущности (то есть, по сути, заниматься изобретательством в чистом виде) — это наша работа. Вопрос только в количестве и достаточности оснований для появления этих сущностей.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Hello, VladD2!
You wrote on Wed, 07 Feb 2007 19:06:11 GMT:
YK>> Работала. Ухудшаться ситуация начала версии с пятой, в шестой YK>> тормоза порою начинают доставать.
V> В ГУИ? Не поверю.
Во-первых, ГУИ сам по себе в IDEA далеко не летает (Swing), но с этим можно жить.
Во-вторых, там помимо ГУИ есть чему тормозить и часто эти тормоза наблюдаются посредством ГУИ.
Turtle.BAZON.Group wrote:
>> > Ага. Только тоже имеет те же проблемы с семантикой. > .>О какой ты семантике говоришь при обсуждении *Abstract* Syntax Tree?.. > А если Abstract, то почему нет обобщения?
an abstract syntax tree (AST) is a finite, labeled, directed tree, where the internal nodes are labeled by operators,
and the leaf nodes represent the operands of the operators.
В общем всё. Обобщение идёт в том смысле, что выкидываются некоторые лексемы (типа скобок группирующих), ибо для
представления в виде дерева они не нужны. Короче говоря, это промежуточный результат, который получается после работы
парсера, но до семантики дело ещё не дошло. Ведь переменная в императивном языке совсем не то, что в функциональном.
> ПС: ладно, тема зашла в тупик. Было приятно пообщаться.
Похоже не сошлись в терминологии.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
ГВ>В чём разбираться? В закономерности, выделенной на основании поверхностного анализа, когда эта поверхностность видна невооружённым глазом? Вам знаком тезис, что любая проблема программирования может быть решена введеним дополнительного уровня абстракции, за исключением проблемы слишком большого количества уровней абстракции? Заметьте, сказано это остаточно давно, чтобы уже стать притчей во языцех. А вы тут пытаетесь нам "продать" этот же рецепт, но под лозунгом ТРИЗ. И кто тут кого обманывает?
есть такой интересный момент — когда какая-то идея переходиьт из чисто практической сферы под сень некоей научной методологии, к ней оказывается прилоджим весь тот спектр методов, который уже наработан в этой науке. в данном случае ТРИЗ известнет своими наработками в сфере решения сложных творческих задач и его методы вполне возможно удастся перенести в сферу разраьботки ПО, открыв программистам новые подходы к решению их задач, которые они не смогли изобрести сами
Здравствуйте, BulatZiganshin, Вы писали:
BZ>есть такой интересный момент — когда какая-то идея переходиьт из чисто практической сферы под сень некоей научной методологии, к ней оказывается прилоджим весь тот спектр методов, который уже наработан в этой науке. в данном случае ТРИЗ известнет своими наработками в сфере решения сложных творческих задач и его методы вполне возможно удастся перенести в сферу разраьботки ПО, открыв программистам новые подходы к решению их задач, которые они не смогли изобрести сами
Угу только ТРИЗ пытаются приложить к программированию с конца 80 — начала 90 и никаких результатов не видно. Мне кажется ТРИЗ очень эффективная методика для решения очень узкого круга проблем.
Здравствуйте, ., Вы писали:
.>представления в виде дерева они не нужны. Короче говоря, это промежуточный результат, который получается после работы .>парсера, но до семантики дело ещё не дошло. Ведь переменная в императивном языке совсем не то, что в функциональном.
Собственно, об этом и говорил.
>> ПС: ладно, тема зашла в тупик. Было приятно пообщаться. .>Похоже не сошлись в терминологии.
Здравствуйте, YК, Вы писали:
YК>Hello, VladD2! YК>You wrote on Wed, 07 Feb 2007 19:06:11 GMT:
YK>>> Работала. Ухудшаться ситуация начала версии с пятой, в шестой YK>>> тормоза порою начинают доставать.
V>> В ГУИ? Не поверю.
YК>Во-первых, ГУИ сам по себе в IDEA далеко не летает (Swing), но с этим можно жить. YК>Во-вторых, там помимо ГУИ есть чему тормозить и часто эти тормоза наблюдаются посредством ГУИ.
Возможно, стоило начать новую тему (или найти старую, наверняка была ) но все же...
Из всех новых веяний я вполне понимаю почему на смену C++ предложили сначала Java а потом C#
Я прекрасно понимаю преимущества таких вещей как reflection, сборки мусора и т.п., которых очень не хватает в C++ (равно как и многих вещей из функционального программирования, да и много чего еще)
Но вот почему вместо процессора, который просто создан для того чтобы выполнять команды ввели виртуальные машины, которые делают ровно то же самое но медленнее...
Объясните плиз... (заранее извините за то что тема поднимается наверняка не в первый раз)
Здравствуйте, x-code, Вы писали:
XC>Но вот почему вместо процессора, который просто создан для того чтобы выполнять команды ввели виртуальные машины, которые делают ровно то же самое но медленнее...
У тебя неправильное понимание того, что такое виртуальная машина. Виртуальная машина — это всего лишь идеализированный образ. Она позволяет компилятору сгенерировать такое представление программы, в котором нет излишних деталей вроде того, какие регистры для чего использовать и каким образом передавать аргументы вызовов. При этом этот образ достаточно детален (пока), чтобы отображение на реальную архитектуру не было чрезмерно сложным. В итоге компилятор отдает не "сырые" инструкции, а недокомпилированный код. Этот код, конечно, можно интерпретировать (как можно интерпретировать и код x86), а можно компилировать сразу в целевую архитектуру (как сейчас в основном и делается).
Поэтому реально все команды выполняет процессор. И очень быстро. А насчет медленнее, напомню, что собственно x86 — виртуальная машина. Реально внутри стоит RISC процессор, а то, что ты видишь как x86 код, интерпретируется на нем перед выполнением. Ну и как, достаточно быстро он выполняет CMPXCHG?
XC>Объясните плиз... (заранее извините за то что тема поднимается наверняка не в первый раз)
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>У тебя неправильное понимание того, что такое виртуальная машина. Виртуальная машина — это всего лишь идеализированный образ. Она позволяет компилятору сгенерировать такое представление программы, в котором нет излишних деталей вроде того, какие регистры для чего использовать и каким образом передавать аргументы вызовов.
как раз это я понимаю. и знаю что реально методы компилируются в реальный код x86 при первом вызове. Непонятно — зачем? Какие преимущества дает операция "докомпилировать при первом вызове, запомнить в кэше и выполнить" по сравнению с просто "выполнить"?
Я не против собственно VM, у них есть масса достоинств, но почему не сделать опцию в компиляторе "генерировать код для VM" и "генерировать код для x86" (а заодно "генерировать код для процессора/VM "X", где X — некоторая архитектура, а для компилятора — просто некоторый плагин)?
При этом этот образ достаточно детален (пока), чтобы отображение на реальную архитектуру не было чрезмерно сложным. В итоге компилятор отдает не "сырые" инструкции, а недокомпилированный код. Этот код, конечно, можно интерпретировать (как можно интерпретировать и код x86), а можно компилировать сразу в целевую архитектуру (как сейчас в основном и делается). S>Поэтому реально все команды выполняет процессор. И очень быстро. А насчет медленнее, напомню, что собственно x86 — виртуальная машина. Реально внутри стоит RISC процессор, а то, что ты видишь как x86 код, интерпретируется на нем перед выполнением. Ну и как, достаточно быстро он выполняет CMPXCHG?
Я полностью согласен с тем что архитектура x86 кривая, устаревшая и тянущая за собой ошибки 20-летней давности. Мне непонятна сама идеология. Вот например переход с 32 на 64 бита можно было совместить с переходом на новую (например RISC) архитектуру, ввести в процессор поддержку безопасности и вообще ввести все что нужно для поддержки современных парадигм программирования. Пусть 32-битные приложения выполнялись бы как раньше на микропрограммной VM, а 64-битные — на RISC. Но нет — архитектура осталась той же, а вместо этого нам предлагают по сути двойную VM. Страшно подумать что будет, когда окажется что C# слишком низкоуровневый и придумают какой-нибудь скриптовый язык, который будет интерпретироваться, а интерпретатор будет написан на C#
x-code wrote: > как раз это я понимаю. и знаю что реально методы компилируются в > реальный код x86 при первом вызове. Непонятно — *зачем*? Какие > преимущества дает операция "докомпилировать при первом вызове, запомнить > в кэше и выполнить" по сравнению с просто "выполнить"?
Во-первых, кроссплатформенность. Во-вторых, в теории Java-код может
работать быстрее аналогичного С-шного кода из-за механизма HotSpot.
> Я полностью согласен с тем что архитектура x86 кривая, устаревшая и > тянущая за собой ошибки 20-летней давности. Мне непонятна сама > идеология. Вот например переход с 32 на 64 бита можно было совместить с > переходом на новую (например RISC) архитектуру, ввести в процессор > поддержку безопасности и вообще ввести все что нужно для поддержки > современных парадигм программирования. Пусть 32-битные приложения > выполнялись бы как раньше на микропрограммной VM, а 64-битные — на RISC.
Рассказать что случилось с Intel Itanic, проститие, Intel Itanium? Линус
об этом хорошо сказал: http://www.ussg.iu.edu/hypermail/linux/kernel/0302.2/1909.html
Здравствуйте, Cyberax, Вы писали:
C>x-code wrote: >> как раз это я понимаю. и знаю что реально методы компилируются в >> реальный код x86 при первом вызове. Непонятно — *зачем*? Какие >> преимущества дает операция "докомпилировать при первом вызове, запомнить >> в кэше и выполнить" по сравнению с просто "выполнить"? C>Во-первых, кроссплатформенность. Во-вторых, в теории Java-код может C>работать быстрее аналогичного С-шного кода из-за механизма HotSpot.
если кроссплатформенность, то "докомпиляцию" можно было бы выполнить один раз на этапе инсталляции программы, а не делать это каждый раз при запуске. Это же элементарная оптимизация — вынести независящее от цикла вычисление за пределы цикла...
Насчет HotSpot — почитал статью, он может выполняться быстрее в 2 раза чем обычный Java-код. Большая часть этой оптимизации доступна на этапе компиляции для того же си. А вся "статистическая" real-time оптимизация, основанная на сборе статистики о наиболее часто вызываемых методах и т.п. — да, ее конечно проще всего реализовать на VM, но совсем не обязательно только на VM.
C>Рассказать что случилось с Intel Itanic, проститие, Intel Itanium? Линус C>об этом хорошо сказал: C>http://www.ussg.iu.edu/hypermail/linux/kernel/0302.2/1909.html
Я думаю, основная причина — несовместимость с огромным количеством существующего ПО.
x-code wrote: > C>Во-первых, кроссплатформенность. Во-вторых, в теории Java-код может > C>работать быстрее аналогичного С-шного кода из-за механизма HotSpot. > если кроссплатформенность, то "докомпиляцию" можно было бы выполнить > *один раз* на этапе инсталляции программы, а не делать это *каждый раз* > при запуске. Это же элементарная оптимизация — вынести независящее от > цикла вычисление за пределы цикла...
.NET так умеет делать. В Sun JVM это затруднительно из-за организации
самой виртуальной машины. Хотя прекомпилировать классы стандартной
библиотеки оно умеет.
> Насчет HotSpot — почитал статью, он может выполняться быстрее в 2 раза > чем обычный Java-код.
Бред. Что за статья?
HotSpot — это именно технология runtime-оптимизации, которую в принципе
невозможна сделать статически.
FR wrote: > C>HotSpot — это именно технология runtime-оптимизации, которую в принципе > C>невозможна сделать статически. > Статически нет а без виртуальной машины вполне.
Как? Нам надо уметь как-то в runtime перекомпилировать код.
В принципе, если есть доступ к исходникам — можно перекомпилировать из
исходников. Но это все равно будет слегка извращенная VM.
Здравствуйте, x-code, Вы писали: XC>если кроссплатформенность, то "докомпиляцию" можно было бы выполнить один раз на этапе инсталляции программы, а не делать это каждый раз при запуске. Это же элементарная оптимизация — вынести независящее от цикла вычисление за пределы цикла...
Это уже сделано, по крайней мере для .Net. RTFM "ngen tool".
XC>Насчет HotSpot — почитал статью, он может выполняться быстрее в 2 раза чем обычный Java-код. Большая часть этой оптимизации доступна на этапе компиляции для того же си.
Плохо читал. Не в 2, а в любое количество раз. И эти оптимизации совершенно недоступны для си, т.к. у него нет информации о статистике реального выполнения. К примеру, си не может инлайнить косвенный вызов.
XC>А вся "статистическая" real-time оптимизация, основанная на сборе статистики о наиболее часто вызываемых методах и т.п. — да, ее конечно проще всего реализовать на VM, но совсем не обязательно только на VM.
Не обязательно. Но VM — это удобная абстракция.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>FR wrote: >> C>HotSpot — это именно технология runtime-оптимизации, которую в принципе >> C>невозможна сделать статически. >> Статически нет а без виртуальной машины вполне. C>Как? Нам надо уметь как-то в runtime перекомпилировать код.
Ну Profile Guided Optimization уже давно есть. Он вполне может обходится не перекомпиляцией исходников, а переоптимизацией объектников
C>В принципе, если есть доступ к исходникам — можно перекомпилировать из C>исходников. Но это все равно будет слегка извращенная VM.
Если оптимизировать прямо у клиента то исходники не нужны, достаточно объектников и правильного линкера.
Здравствуйте, Sinclair, Вы писали:
XC>>Насчет HotSpot — почитал статью, он может выполняться быстрее в 2 раза чем обычный Java-код. Большая часть этой оптимизации доступна на этапе компиляции для того же си. S>Плохо читал. Не в 2, а в любое количество раз. И эти оптимизации совершенно недоступны для си, т.к. у него нет информации о статистике реального выполнения. К примеру, си не может инлайнить косвенный вызов.
FR wrote: > C>Как? Нам надо уметь как-то в runtime перекомпилировать код. > Ну Profile Guided Optimization уже давно есть. Он вполне может обходится > не перекомпиляцией исходников, а переоптимизацией объектников
PGO может оптимизировать только для некоторых случаев. Горячие точки
ведь могут мигирировать во время работы программы.
> C>В принципе, если есть доступ к исходникам — можно перекомпилировать из > C>исходников. Но это все равно будет слегка извращенная VM. > Если оптимизировать прямо у клиента то исходники не нужны, достаточно > объектников и правильного линкера.
А как ты будешь оптимизировать виртуальные вызовы, например?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, x-code, Вы писали: XC>>если кроссплатформенность, то "докомпиляцию" можно было бы выполнить один раз на этапе инсталляции программы, а не делать это каждый раз при запуске. Это же элементарная оптимизация — вынести независящее от цикла вычисление за пределы цикла... S>Это уже сделано, по крайней мере для .Net. RTFM "ngen tool".
За ngen спасибо, для меня это серьезный повод перейти на NET
а как быть с NET'освкими библиотеками (типа WinForms)? Они существуют в виде кода для VM или уже откомпилированные для проца?
XC>>А вся "статистическая" real-time оптимизация, основанная на сборе статистики о наиболее часто вызываемых методах и т.п. — да, ее конечно проще всего реализовать на VM, но совсем не обязательно только на VM. S>Не обязательно. Но VM — это удобная абстракция.
не спорю, более того — то что существуют VM это очень даже хорошо. просто мое ИМХО — не стоит использовать VM везде.
Здравствуйте, x-code, Вы писали:
S>>Это уже сделано, по крайней мере для .Net. RTFM "ngen tool".
XC>За ngen спасибо, для меня это серьезный повод перейти на NET
При этом, как правило, использование ngen-а может привести не только к ускорению работы приложения, но и к его замедлению.
Здравствуйте, Cyberax, Вы писали:
C>FR wrote: >> C>Как? Нам надо уметь как-то в runtime перекомпилировать код. >> Ну Profile Guided Optimization уже давно есть. Он вполне может обходится >> не перекомпиляцией исходников, а переоптимизацией объектников C>PGO может оптимизировать только для некоторых случаев. Горячие точки C>ведь могут мигирировать во время работы программы.
Ну если он будет постоянно и у клиента запущен, то какие проблемы.
>> C>В принципе, если есть доступ к исходникам — можно перекомпилировать из >> C>исходников. Но это все равно будет слегка извращенная VM. >> Если оптимизировать прямо у клиента то исходники не нужны, достаточно >> объектников и правильного линкера. C>А как ты будешь оптимизировать виртуальные вызовы, например?
А какие проблемы, тот же линкер из VC8 уже умеет вынимать из объектника и инлайнить функции, и с виртуальными думаю тот же фокус пройдет. То есть думаю в принципе все вполне реально, вот только нужно ли.
Хотя так любимая тобой низкоуровневая виртуальная машина наверно будет эффективней для такого рода вещей.
FR wrote: > C>PGO может оптимизировать только для некоторых случаев. Горячие точки > C>ведь могут мигирировать во время работы программы. > Ну если он будет постоянно и у клиента запущен, то какие проблемы.
А как ты в ответ на отклик PGO будешь перекомпилировать код (на
клиенте!) и обновлять работающую программу?
> C>А как ты будешь оптимизировать виртуальные вызовы, например? > А какие проблемы, тот же линкер из VC8 уже умеет вынимать из объектника > и инлайнить функции, и с виртуальными думаю тот же фокус пройдет.
Э, нет. При Link Time Code Generation в объектниках помещается
промежуточный код, который при линковке компилируется в машинный. Так
что без VM тоже никуда
Здравствуйте, Cyberax, Вы писали:
C>FR wrote: >> C>PGO может оптимизировать только для некоторых случаев. Горячие точки >> C>ведь могут мигирировать во время работы программы. >> Ну если он будет постоянно и у клиента запущен, то какие проблемы. C>А как ты в ответ на отклик PGO будешь перекомпилировать код (на C>клиенте!) и обновлять работающую программу?
А зачем обновлять работающую программу. Будет копится статистика и при некторых
запусках кое что перекомпилироватся. Да и на ходу при желании можно, у нас же
объектники есть.
>> C>А как ты будешь оптимизировать виртуальные вызовы, например? >> А какие проблемы, тот же линкер из VC8 уже умеет вынимать из объектника >> и инлайнить функции, и с виртуальными думаю тот же фокус пройдет. C>Э, нет. При Link Time Code Generation в объектниках помещается C>промежуточный код, который при линковке компилируется в машинный. Так C>что без VM тоже никуда
Ну так да, но это не полноценная виртуальная машина.
Здравствуйте, x-code, Вы писали:
XC>а как быть с NET'освкими библиотеками (типа WinForms)? Они существуют в виде кода для VM или уже откомпилированные для проца?
Здравствуйте, FR, Вы писали: FR>Нет я ошибся. Они только умеют прямо подставлять вызов виртуальной функции, FR>когда точно известен тип объекта, то есть вызов уже не косвенный.
То-то. А хотспот может
а) убедиться, что в памяти нет классов, перегружающих данный метод, и его можно считать невиртуальным. Ну и, естественно, откатить оптимизацию обратно, когда будет загружен новый класс.
б) даже если есть несколько перегрузок, посчитать, какая из них чаще встречается, и заинлайнить ее. Обрамив, естественно, т.н. guard code, который проверяет — нужный ли класс попался.
И еще много того, что называется Profile-Guided Optimization.
Естественно, PGO не обязательно проводить в динамике (как это делает Java). Информацию о хот спотах можно получить и статически, а затем использовать. Тем не менее, рекомпиляцию с PGO все равно удобнее производить из промежуточного представления.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, FR, Вы писали: FR>>Нет я ошибся. Они только умеют прямо подставлять вызов виртуальной функции, FR>>когда точно известен тип объекта, то есть вызов уже не косвенный. S>То-то. А хотспот может S>а) убедиться, что в памяти нет классов, перегружающих данный метод, и его можно считать невиртуальным. Ну и, естественно, откатить оптимизацию обратно, когда будет загружен новый класс. S>б) даже если есть несколько перегрузок, посчитать, какая из них чаще встречается, и заинлайнить ее. Обрамив, естественно, т.н. guard code, который проверяет — нужный ли класс попался.
Кстати такое можно и на C++ замутить.
S>И еще много того, что называется Profile-Guided Optimization.
Ну PGO уже подерживается C++ компиляторами, хотя конечно у них он беднее.
S>Естественно, PGO не обязательно проводить в динамике (как это делает Java). Информацию о хот спотах можно получить и статически, а затем использовать. Тем не менее, рекомпиляцию с PGO все равно удобнее производить из промежуточного представления.
Здравствуйте, FR, Вы писали:
FR>Ну тот же VC8 именно так и поступает.
Ну вот промежуточное представление, скорее всего, и есть код для какой-то "виртуальной машины".
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я бы обозначил так: ещё одна цель. Ещё одна в целом ряду целей, для достижения которых разрабатывались ЯП: обучение, символьная обработка, доказательство теорем, системное программирование и т.п.
Не хочу вдаваться в муторные и многословные препирательства, но закономерности сами по себе не имеют цели. Ни в одной науке. Какова, например, цель Закона Всемирного Тяготения или Закона Ома? Да никакая. Человек просто может использовать эти законы на практике. И тут он сам находит цель. Но закономерности не имеют цели.
Мы же в своей статье попытались показать, как указанная закономерность может быть приспособлена для проектирования архитектур, устойчивых к изменениям.
ГВ>Думаю, что само числительное "триста" (или какой-либо его прямой семантический аналог) не появилось бы без предварительного появления системы счисления как таковой. То есть тут налицо впитывание разговорным языком специальной "математической" нотации. Впрочем, повторюсь, что я — не лингвист.
Это обстоятельство опять-таки развенчивает миф о "естественном" языке. Для счета был изобретен язык математики. Поскольку он оказался удобен, он в каком-то трансформированном виде и перекочевал в "естественный" язык. А вот "естественный" язык (изначально) для счета был неудобен.
ГВ>Опять таки, думаю, что дело здесь было в необходимости что-то посчитать. Отсюда и появилась система обозначений чисел и операций над ними.
Вы опять процитировали фразу из моего предыдущего сообщения своими словами. Зачем?
КЛ>>Точно так же и с другими областями человеческой деятельности. Попробуйте-ка написать программу уровня Microsoft Word на естестественном языке. Полагаю, еще та задачка. Не случайно, авторы ряда фундаментальных книг по алгоритмам и структурам данных как только дело доходит до описания алгоритмов, предпочитают псевдокод. А некоторые продвинутые товарищи изобретают даже собственные языки программирования — специально для записи алгоритмов.
ГВ>Вот в этом абзаце что-то логическую связь улавливаю плохо. Да, Word, наверное, трудновато сформулировать на разговорном языке. Но его вполне можно выразить на ассемблерных мнемониках. И кроме того, некорректно упоминать Word в контексте обсуждения мутаций языков програмирования: он появился тогда, когда "культура" обозначений в языках программирования уже достаточно устоялась. А в то время, когда изобретались первые обозначения "mov", "add" и прочие подобные, задачи WYSIWYG-редактора ещё не стояло.
Попробую пояснить еще раз. Вы взяли за основу миф о компьютере, понимающем так называемый "естественный" язык. И высказались в том роде, что это цель, ради которой и были проведены все те преобразования над языками программирования, которые описаны в нашей статье. В качестве доказательства Вы привели 2 факта:
1) Названия мнемоник являются сокращениями английских слов: mov, add, jmp и т.д.
2) В программе на языке высокого уровня можно записать выражение в "математическом" виде: b = a + 1
Не отрицая важности того, что язык программирования должен быть более доступен для человека за счет использования слов из естественного языка, я Вам привел 2 контраргумента:
1) "Математический" язык не является "естественным" языком, поскольку он разрабатывался специально для решения задач счета. Наоборот, т.н. "естественный" очень плохо подходит для счета. Пример я Вам уже приводил выше.
При этом "математический" язык оказался таким успешным, что затем частично перекочевал и в "естественный" язык — Ваш пример про слово "триста".
2) Пример с Microsoft Word'ом я Вам привел для того, чтобы Вы поняли, что даже если компьютер будет понимать "естественный" язык, это никак не поможет в создании подобной программы. "Естественный" язык не только не упростит запись алгоритмов, но еще внесет серьезные проблемы для команды сопровождения, если каждый программист начнет надиктовывать алгоритм на своем диалекте.
Таким образом, "естественность" языка тут совершенно не при чем. Основой для надсистемного перехода (для перехода на новый уровень абстракции) могут быть совершенно разные языки, понятия или системы понятий (==контексты). В одном случае цифры заменили сокращениями "естественных" слов, и получили мнемоники. В другом случае основой послужил язык математики, и программистам стали доступны конструкции вида b = a + 1. В третьем случае основой может оказаться что-то еще, чего еще в помине не существует. И это что-то предстоит еще создать. Так что не нужно зцикливаться на каком-то мифическом "естественном" языке, а лучше поискать подходящие контексты для группирования сущностей. Именно эти контексты и дадут все необходимые термины.
Так в одном из предыдущих обсуждений Вы спросили меня "Что общего между трубкой курительной и трубкой телефонной?" Если помните, я Вам ответил, что для нахождения общности нужно искать контекст. Например, таким контекстом может являться опись имущества. И с точки зрения описи имущества обе трубки — лишь строки в ней.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>В чём разбираться? В закономерности, выделенной на основании поверхностного анализа, когда эта поверхностность видна невооружённым глазом? Вам знаком тезис, что любая проблема программирования может быть решена введеним дополнительного уровня абстракции, за исключением проблемы слишком большого количества уровней абстракции? Заметьте, сказано это остаточно давно, чтобы уже стать притчей во языцех. А вы тут пытаетесь нам "продать" этот же рецепт, но под лозунгом ТРИЗ. И кто тут кого обманывает?
Речь идет НЕ только и не столько об уровнях абстракции при решении задач программирования, сколько:
1) о частной, но очень распространенной проектной ошибке, которая называется "проскок системного уровня" и которая приводит к наведенной задаче многофакторности;
2) а также о том, что есть тенденция развития ОТРАСЛИ В ЦЕЛОМ, которая пока развивается "этажами" — Если бы это (на уровне отрасли) было известно давно и стало притчей во языцех, никто бы не считал бы "откровениями" ни ООП (в свое время), ни паттерны проектирования (сейчас).
3) о проектировании "сверху вниз" — да, и это не "новость", между тем, достаточно посмотреть это обсуждение, чтобы понять какой протест это вызывает.
4) о том, что кроме уровней есть "полутона".
5) о том, что — думая над проектом — разработчик понимает его как набор сущностей третьего или четвертого уровня, куда он в процессе работы добавляет сущности уровня 1, 2 и 3. А потом из этих сущностей уровня "1,2,3" он пишет сразу объект уровня 6 (программу), совершая, тем самым, "проскок уровней".
Т.е., о том, что программист, конечно знает "про уровни абстракции", но не отождествляет их с этапами написания программы.
Касательно "много уровней — мало уровней", смотрите статью про "много-мало". Она специально названа "Как вспомнить и так известное", хотя, если Вы скажете, что формулировка противоречий в программировании общепринята — это не будет соответствовать действительности.
Ссылка на материал по ТРИЗ — это ссылка на публикацию 1979 года (не вчерашнюю, мягко говоря), причем указана именно аналогия и написано "сказано по другому поводу".
Ссылки на первоисточники мы делаем — см. список литературы.
Здравствуйте, x-code, Вы писали:
XC>как раз это я понимаю. и знаю что реально методы компилируются в реальный код x86 при первом вызове. Непонятно — зачем? Какие преимущества дает операция "докомпилировать при первом вызове, запомнить в кэше и выполнить" по сравнению с просто "выполнить"? XC>Я не против собственно VM, у них есть масса достоинств, но почему не сделать опцию в компиляторе "генерировать код для VM" и "генерировать код для x86" (а заодно "генерировать код для процессора/VM "X", где X — некоторая архитектура, а для компилятора — просто некоторый плагин)?
Дык в том же дотнете есть NGen который как раз создает образы с бинарным кодом который уже не надо прекомпилировать при запуске.
А приемущество очевидно — прекомпиляция проводится на конкретной машине с кокретными процессором, памятью и т.п. Плюс, потениально, можно использовать информацию от мониторинга исполнения (профилирование, но на конкретной железке).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, x-code, Вы писали:
XC>За ngen спасибо, для меня это серьезный повод перейти на NET
Поясни, а с чего это для тебя стало поводом?
Открою тебе один сикрет. Скорость выполнения это не поднимает. Это поднимает только скорость загрзуки, и то в большинстве случаев этого не заметить в микроском. Я впервые почувствовал необходимость в пре-помпиляции только когда сатал пользоваться Nemerle. Его компилятор так интенсивно исползует функциональные объекты (которые конвертируются в тучу простеньких классов), что загрузка компилятора занимает очень ощутимое время. С ngen-ом оно практически счезает. Но когда я писл на C#, то ни одна мая программа не требовала ngen-а (точнее время ее загрузки практически не менялось после ngen-а).
XC>а как быть с NET'освкими библиотеками (типа WinForms)? Они существуют в виде кода для VM или уже откомпилированные для проца?
Практически все библиотеки дотнета прекомпилированы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
FR>>Нет я ошибся. Они только умеют прямо подставлять вызов виртуальной функции, FR>>когда точно известен тип объекта, то есть вызов уже не косвенный. S>То-то. А хотспот может
Вообще-то в некоторых случаях может. S>а) убедиться, что в памяти нет классов, перегружающих данный метод, и его можно считать невиртуальным. Ну и, естественно, откатить оптимизацию обратно, когда будет загружен новый класс.
Ага. Очень похоже действуют С++-ные компиляторы. Только в рамках ехе-шника.
S>б) даже если есть несколько перегрузок, посчитать, какая из них чаще встречается, и заинлайнить ее. Обрамив, естественно, т.н. guard code, который проверяет — нужный ли класс попался.
Вот толкьо такая проверка приблизительно равна виртуальному вызову. Так что вигрыша не будет или он будет очень не существенным.
Вот в Яве 1.7 обещают эскеп-анализ. Может он позволит выявлять "короткие" объекты и тогда оптимизации можно будет делать более уверенно.
S>И еще много того, что называется Profile-Guided Optimization. S>Естественно, PGO не обязательно проводить в динамике (как это делает Java). Информацию о хот спотах можно получить и статически, а затем использовать. Тем не менее, рекомпиляцию с PGO все равно удобнее производить из промежуточного представления.
Вот только как показывает практика дотнетный код без всех этих выкрутасов обычно работает быстрее. Может тому виной менее качественная работа Сновчников, а может все эти изыски мало что дают на фоне остальных проблем.
Кстати, тут так часто обсуждают избавление от виртуальных вызовов, что можно подумать, что это галавная проблема производительности. Меж тем виртуальные вызовы не видно в микроспом в большинстве случаев. Их можно заметить если с их помощью делаются сложения или сравнения целых, а в ОО-программе их применение просто незаметно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, тут так часто обсуждают избавление от виртуальных вызовов, что можно подумать, что это галавная проблема производительности. Меж тем виртуальные вызовы не видно в микроспом в большинстве случаев. Их можно заметить если с их помощью делаются сложения или сравнения целых, а в ОО-программе их применение просто незаметно.
Думаю, что избавление от виртуальных методов позволяет не останавливать на них оптимизацию и, например, инлайнить, а иногда и полностью устранять вызов методов.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, x-code, Вы писали:
XC>>За ngen спасибо, для меня это серьезный повод перейти на NET
VD>Поясни, а с чего это для тебя стало поводом?
я не хочу чтобы функция при первом вызове работала дольше чем при последующих.
хотя, честно сказать, я серьезно C# не занимался, мне просто стало интересно почему пошла такая тенденция перехода к виртуальным машинам.
VladD2 wrote: > Вот толкьо такая проверка приблизительно равна виртуальному вызову. Так > что вигрыша не будет или он будет очень не существенным.
Выигрыш есть достаточно заметный, так как branch instruction очень
эффективно оптимизируется предсказателем переходов. У нас там в
большинстве случаев она займет один-два такта.
> Вот только как показывает практика дотнетный код без всех этих > выкрутасов обычно работает быстрее. Может тому виной менее качественная > работа Сновчников, а может все эти изыски мало что дают на фоне > остальных проблем.
Сильно быстрее он никогда, собственно, и не был. Просто некоторые вещи у
MS были более качественно оптимизированы. Ну и во фреймворке от MS
меньше используется виртуальных вызовов из-за необходимости их явно
указывать.
А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно
быстрее .NET.
> Кстати, тут так часто обсуждают избавление от виртуальных вызовов, что > можно подумать, что это галавная проблема производительности. Меж тем > виртуальные вызовы не видно в микроспом в большинстве случаев. Их можно > заметить если с их помощью делаются сложения или сравнения целых, а в > ОО-программе их применение просто незаметно.
Заметны, очень даже заметны.
А вообще, inlineing (не только виртуальных методов) — это самая
эффективная оптимизация.
EvilChild wrote: > C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно > C>быстрее .NET. > А можно подробнее?
Есть программа на Java и C# — поиск "похожих" объектов в длинном списке.
Объекты — это некие "хэши" биометрических данных (если быть точным,
геометрии руки), причем еще для каждого хэша хранится история (20 штук
предидущих хэшей). "Похожесть" двух хэшей определяется достаточно
сложно, поэтому программа сначала строит для этого списка индекс, а
потом ищет с его помощью.
В общем, примерно 300 килобайт запутаного кода. У производителя он
изначально был только на C#, я его полуавтоматически перевел на Java.
Я тестировал сколько будет строится индекс для большой базы. При
использовании Sun JDK 1.4 и .NET FW2 лидировал .NET FW примерно с 30%
отрывом. После перехода на 1.6 скорость Java-версии стала примерно на
10% больше.
Здравствуйте, Cyberax, Вы писали:
C>Я тестировал сколько будет строится индекс для большой базы. При C>использовании Sun JDK 1.4 и .NET FW2 лидировал .NET FW примерно с 30% C>отрывом. После перехода на 1.6 скорость Java-версии стала примерно на C>10% больше.
EvilChild wrote: > C>Я тестировал сколько будет строится индекс для большой базы. При > C>использовании Sun JDK 1.4 и .NET FW2 лидировал .NET FW примерно с 30% > C>отрывом. После перехода на 1.6 скорость Java-версии стала примерно на > C>10% больше. > На 10% больше чем .NET'ная?
Да, больше чем .NETная. Хотя надо будет с .NET FW3 потестить.
Здравствуйте, IT, Вы писали:
IT>Думаю, что избавление от виртуальных методов позволяет не останавливать на них оптимизацию и, например, инлайнить, а иногда и полностью устранять вызов методов.
В том то все и дело, что дает это что-то только если речь идет местах где вызовы используются для сложения или сравнения. Даже в алгоритме сортировки такая оптимизация дает не более 30% выигрыша. А в средней ОО-программе вообще речь идет о долях процента.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Выигрыш есть достаточно заметный, так как branch instruction очень C>эффективно оптимизируется предсказателем переходов. У нас там в C>большинстве случаев она займет один-два такта.
Это голосвловные утверждения.
C>Сильно быстрее он никогда, собственно, и не был. Просто некоторые вещи у C>MS были более качественно оптимизированы. Ну и во фреймворке от MS C>меньше используется виртуальных вызовов из-за необходимости их явно C>указывать.
Ну, так в итоге быстрее? Далее без труда можно сделать вывод о том, что вопрос этот излишне раздувается и его важность преувеличивается.
C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно C>быстрее .NET.
Тесты в студию. Обсудим.
>> ОО-программе их применение просто незаметно. C>Заметны, очень даже заметны.
Мой опыт говорит об обратном. Е тебя есть что-то чем ты можешь обосновать свое мнение?
C>А вообще, inlineing (не только виртуальных методов) — это самая C>эффективная оптимизация.
Это чушь. Большинство методов выполняют столь большой объем работ, что время на вызов просто нивелируется.
Я уже устал повторять, что время вызова влияет только в тех случаях если в методах выполняются микроскопические операции (занимющие еденицы инструкций). А такие опрерации обычно завернуты в разные библиотеки и фрэйворки. В прикладном коде их практически нет. Соотвественно влияние инланинга очень незначительное.
Инлайнинг рулит в пенисометрии, но на практике он далеко не так ощутим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Смысл? Рантайм то тот же.
Не тот же делегаты похоже ускорились.
Проблема в том, что это все треп. Надо смотреть реальные тесты. Там столько мест где могут быть расхождения. Скажем используемые контейнеры, или качество эша.
И вообще, то снова разговор о каких-то мало заметных на глаз величинах и каком-то редко-встречающемся коде. Основной код приложений — это работа с довольно большими объектами. И там вся эта лабуда мало ощутима.
Просто товарищь Киберакс имеет нехилый такой пунктик в области быстродействия и явно не может адекватно оценивать этот вопрос.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали: C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно C>быстрее .NET.
... C>После перехода на 1.6 скорость Java-версии стала примерно на C>10% больше.
Самому то не смешно? 10% это значительно? Уверен, что качетсво хэш-фукнций и различие алгоритмов в хэш-таблицах влияет намного больше.
К тому же это не ОО-код. А какие-то Киберакс-лайк оптимизации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, x-code, Вы писали:
VD>>Поясни, а с чего это для тебя стало поводом? XC>я не хочу чтобы функция при первом вызове работала дольше чем при последующих.
А ничего что ты в упор разницы незаметишь?
XC>хотя, честно сказать, я серьезно C# не занимался, мне просто стало интересно почему пошла такая тенденция перехода к виртуальным машинам.
Уж точно не из-за скорости запуска ехе-шников.
Тут дело в том, что на безопасных языках со сборкой мусора писать быстрее и легче. А это реальное конкуретное приемущество.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
>>> Ну потому как зоопарк возник, нет обобщенного AST, .>>Ну почему — есть и такая штука, обобщённое AST на "все случаи жизни" — это XML.
K>Не, есть штука ещё обобщённее — Лисп
VladD2 wrote: > C>Выигрыш есть достаточно заметный, так как branch instruction очень > C>эффективно оптимизируется предсказателем переходов. У нас там в > C>большинстве случаев она займет один-два такта. > Это голосвловные утверждения.
Собствено, с чем именно ты споришь? С тем, что branching медленнее
косвенного перехода?
> C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно > C>быстрее .NET. > Тесты в студию. Обсудим.
Сложно. Кусок кода достаточно большой, да еще и под NDA.
А микротесты тебе не нравятся.
Что предлагаешь?
>> > ОО-программе их применение просто незаметно. > C>Заметны, очень даже заметны. > Мой опыт говорит об обратном. Е тебя есть что-то чем ты можешь > обосновать свое мнение? Моим опытом
> C>А вообще, inlineing (не только виртуальных методов) — это самая > C>эффективная оптимизация. > Это чушь. Большинство методов выполняют столь большой объем работ, что > время на вызов просто нивелируется.
get/set методы...
А вообще, история с qsort и std::sort как бы вообще никем не оспаривается.
VladD2 wrote: > C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно > C>быстрее .NET. > ... > C>После перехода на 1.6 скорость Java-версии стала примерно на > C>10% больше. > Самому то не смешно? 10% это значительно? Уверен, что качетсво > хэш-фукнций и различие алгоритмов в хэш-таблицах влияет намного больше.
На 10% быстрее .NETовой.
> К тому же это не ОО-код. А какие-то Киберакс-лайк оптимизации.
А как ты мой код так видишь через 1000 километров?
Этот код вообще был не мой, а предоставлен вендором устройства. Там я
при переписывании вообще ничего не трогал, за исключение банальных
подстановок контейнеров и прочей ерунды.
Здравствуйте, Cyberax, Вы писали:
>> Самому то не смешно? 10% это значительно? Уверен, что качетсво >> хэш-фукнций и различие алгоритмов в хэш-таблицах влияет намного больше. C>На 10% быстрее .NETовой.
Вижу, не глухой. Ты внимательнее читай.
>> К тому же это не ОО-код. А какие-то Киберакс-лайк оптимизации. C>А как ты мой код так видишь через 1000 километров?
Я тебя знаю.
C>Этот код вообще был не мой, а предоставлен вендором устройства. Там я C>при переписывании вообще ничего не трогал, за исключение банальных C>подстановок контейнеров и прочей ерунды.
Вот "ерунда" может оказать очень значительное влиятие.
Для сравнения именно JIT-ов это негодится. Тут нужно иметь полностью идетничные алгоритмы (вплоть до контейнеров). А еще лучше сравнивать не только показатели, но и генерируемый ассебленый код. Вот только как его на Яве полчить я не знаю. Это на дотнете то проблематично.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: >> > К тому же это не ОО-код. А какие-то Киберакс-лайк оптимизации. > C>А как ты мой код так видишь через 1000 километров? > Я тебя знаю.
> C>Этот код вообще был не мой, а предоставлен вендором устройства. Там я > C>при переписывании вообще ничего не трогал, за исключение банальных > C>подстановок контейнеров и прочей ерунды. > Вот "ерунда" может оказать очень значительное влиятие.
Тут более интересно ускорение JVM — оно примерно на 30% быстрее стало
работать по сравнению со старой версией.
> Для сравнения именно JIT-ов это негодится. Тут нужно иметь полностью > идетничные алгоритмы (вплоть до контейнеров). А еще лучше сравнивать не > только показатели, но и генерируемый ассебленый код. Вот только как его > на Яве полчить я не знаю. Это на дотнете то проблематично.
Ассемблерный код при желании получить можно, надо только собрать JVM с
поддержкой отладки.
Здравствуйте, Cyberax, Вы писали:
C>Тут более интересно ускорение JVM — оно примерно на 30% быстрее стало C>работать по сравнению со старой версией.
Еще раз повторяю, никаких выводов из таких поверхностных тестов сделать нельзя.
Может они подправили хэш-табличку или еще что.
C>Ассемблерный код при желании получить можно, надо только собрать JVM с C>поддержкой отладки.
Ну, это гемор на который лично я не решусь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Тут более интересно ускорение JVM — оно примерно на 30% быстрее стало > C>работать по сравнению со старой версией. > Еще раз повторяю, никаких выводов из таких поверхностных тестов сделать > нельзя. Может они подправили хэш-табличку или еще что.
Это вряд ли. Только что проверил — хэши для строк, байтовых массивов, и
BigDecimal'ов совпадают.
> C>Ассемблерный код при желании получить можно, надо только собрать JVM с > C>поддержкой отладки. > Ну, это гемор на который лично я не решусь.
Аналогично. Хотя можно попробовать скачать скомпиленую версию из проекта
OpenJDK, но я с ним еще не разбирался.
Здравствуйте, Cyberax, Вы писали:
>> C>А вообще, inlineing (не только виртуальных методов) — это самая >> C>эффективная оптимизация. >> Это чушь. Большинство методов выполняют столь большой объем работ, что >> время на вызов просто нивелируется. C>get/set методы...
Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?
По идее должен.
Вообще было бы прикольно глянуть сводную таблицу run-time оптимизаций, которые выполняют CLR и JVM — никто не натыкался?
now playing: Sinthetix — Neurotoxin (feat. MC Mecha)
Здравствуйте, IT, Вы писали:
C>>>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно C>>>быстрее .NET.
EC>>А можно подробнее?
IT>Это действительно так. Особенно сильно вырывается вперёд серверный вариант. Это заметно даже по шустрикам на нашем сайте.
Здравствуйте, EvilChild, Вы писали:
EC>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?
Даже виртуальные? Прикол именно в том, что HotSpot может частично либо полностью устранять виртуальность, основываясь на спекулятивных предположениях. На практике это означает отсутствие abstraction penalty и возможность обойтись без архитектурно корявых залепух навроде намеренно невиртуальных методов и публикации полей вместо свойств.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
EC>>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое? S>Даже виртуальные? Прикол именно в том, что HotSpot может частично либо полностью устранять виртуальность, основываясь на спекулятивных предположениях. На практике это означает отсутствие abstraction penalty и возможность обойтись без архитектурно корявых залепух навроде намеренно невиртуальных методов и публикации полей вместо свойств.
Насчёт виртуальных не знаю, но теоретических препятствий этому не вижу.
EvilChild wrote: > S>Даже виртуальные? Прикол именно в том, что HotSpot может частично либо > полностью устранять виртуальность, основываясь на спекулятивных > предположениях. На практике это означает отсутствие abstraction penalty > и возможность обойтись без архитектурно корявых залепух навроде > намеренно невиртуальных методов и публикации полей вместо свойств. > Насчёт виртуальных не знаю, но теоретических препятствий этому не вижу.
И как ты это собираешься делать без HotSpot?
Здравствуйте, Cyberax, Вы писали:
C>И как ты это собираешься делать без HotSpot?
Не совсем понял твой вопрос.
По моему у CLR есть достаточно информации, чтобы устранять виртуальность там, где это возможно и откатывать эту оптимизацию, когда она становится невалидной (загрузили тип, где эта функция overriden).
Или ты о том, что это и будет HotSpot?
Если да, то пожалуйста — мне всё равно как это называется.
EvilChild wrote: > C>И как ты это собираешься делать без HotSpot? > Не совсем понял твой вопрос. > По моему у CLR есть достаточно информации, чтобы устранять виртуальность > там, где это возможно и откатывать эту оптимизацию, когда она становится > невалидной (загрузили тип, где эта функция overriden). > Или ты о том, что это и будет HotSpot?
Да, именно это и будет HotSpot.
Но смысл в том, что сейчас .NET VM не выполняет перекомпиляцию кода.
Здравствуйте, Cyberax, Вы писали: C>И как ты это собираешься делать без HotSpot?
Ну разве что при помощи PGO. Без profile-time информации совершенно нереально выбрать одну из перегруженных версий виртуального метода для инлайнинга. Либо я не понимаю чего-то элементарного.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote: > C>И как ты это собираешься делать без HotSpot? > Ну разве что при помощи PGO. Без profile-time информации совершенно > нереально выбрать одну из перегруженных версий виртуального метода для > инлайнинга. Либо я не понимаю чего-то элементарного.
Ну PGO — это тоже своеобразный HotSpot
Самое плохое в том, что PGO не работает с динамической подгрузкой кода.
Здравствуйте, IT, Вы писали:
IT>Это действительно так. Особенно сильно вырывается вперёд серверный вариант. Это заметно даже по шустрикам на нашем сайте.
В серверном варианте просто доругой ЖЦ. К скорости кода это отношение не имеет. У дотента тоже разный ЖЦ и сравнивать тут так просто нельзя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?
Вот такого не происходит. За-то в релизе почти всегда.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
EC>>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое? S>Даже виртуальные? Прикол именно в том, что HotSpot может ...
На словах он могое может. На деле — нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Ну разве что при помощи PGO. Без profile-time информации совершенно нереально выбрать одну из перегруженных версий виртуального метода для инлайнинга. Либо я не понимаю чего-то элементарного.
На самом деле во многих случаях было бы достаточно анализа потока управления. Ведь часто виртуальные методы и нитерфейсы применяются локально и можно проследить использование этой переменной. Если во время ее использования не делается ни одного изменения ссылки или все изменения делаются на тот же тип объектов, то можно смело создавать специализированную версию фукнции которой передается интерфейс (или класса) и устанять в ней как виртуальность, так и сам вызов. Учитывая, что это можно сделать во время пред-компиляции особых ресурсов (кроме некоторого увеличения расхода памяти под образ кода) тратить не приется, можно говорить о хорошем выигрыше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EC>>Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?
VD>Вот такого не происходит. За-то в релизе почти всегда.
Как-то студия отказалась ставить бряку в теле тривиального сеттера (или геттера) в отладочной версии и сказала, что метод был оптимизирован, вот я и подумал, что инлайнинг случился. Если это не инлайнинг, то что тогда?
Здравствуйте, EvilChild, Вы писали:
VD>>Вот такого не происходит. За-то в релизе почти всегда.
EC>Как-то студия отказалась ставить бряку в теле тривиального сеттера (или геттера) в отладочной версии и сказала, что метод был оптимизирован, вот я и подумал, что инлайнинг случился. Если это не инлайнинг, то что тогда?
Может ты релиз пытался отлаживать?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
VladD2 wrote: > IT>Это действительно так. Особенно сильно вырывается вперёд серверный > вариант. Это заметно даже по шустрикам на нашем сайте. > В серверном варианте просто доругой ЖЦ. К скорости кода это отношение не > имеет. У дотента тоже разный ЖЦ и сравнивать тут так просто нельзя.
Вообще-то, серверная и клиентская JVMы заметно различаются в Java.
Клиентская GC имеет более простые алгоритмы HotSpot'а, оптимизированые
для быстрого запуска приложения.
Физически даже размеры файлов даже различаются:
client/jvm.dll — 2301952
server/jvm.dll — 3276800
Здравствуйте, VladD2, Вы писали: VD>На самом деле во многих случаях было бы достаточно анализа потока управления. Ведь часто виртуальные методы и нитерфейсы применяются локально и можно проследить использование этой переменной.
В большинстве случаев это сводится к определению наличия вызова конструктора в области видимости. К сожалению, это происходит не так часто, как хотелось бы — это видно на примере современных С++ компиляторов. Они делают всё, что могут в этой области, но в большинстве случаев инлайнинг ограничивается автоматическими объектами.
Есть масса сценариев, в которых устранить виртуальность статическим анализом невозможно. Классы, которые задаются через конфиг файл; традиционная схема вызова виртуального метода из невиртуального, и еще много всего.
А для полей объектов получить строгое доказательство единственности присваивания вообще очень сложно (в смысле complexity) и неоправдвно: в большинстве случаев строгое доказательство вовсе невозможно. Именно тут рулит подход с guarded inlining. Для его применения достаточно нестрогого доказательства: если на практике одна из реализаций вызывается достаточно чаще других, то ее уже можно инлайнить. Строгое доказательство дает лишь небольшое улучшение — убирается guard code, который и так весьма недорог.
VD>Если во время ее использования не делается ни одного изменения ссылки или все изменения делаются на тот же тип объектов, то можно смело создавать специализированную версию фукнции которой передается интерфейс (или класса) и устанять в ней как виртуальность, так и сам вызов. Учитывая, что это можно сделать во время пред-компиляции особых ресурсов (кроме некоторого увеличения расхода памяти под образ кода) тратить не приется, можно говорить о хорошем выигрыше.
Не спорю. Трудно говорить "на пальцах", не имея точных цифр. Это же не выбор да/нет, это всего лишь наличие разнообразной информации у компилятора. Чем ее больше, тем лучшие оптимизации можно в общем случае провести. Но естественно, здесь должно быть применимо правило Парето — 80% выигрыша должно достигаться самыми простыми оптимизациями. А следующие 80% оптимизаций дадут не больше 20% выигрыша.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали: C>Можешь предложить лучший вариант термина?
"Динамическая оптимизация целевого кода с использованием статистики времени выполнения".
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote: > C>Можешь предложить лучший вариант термина? > "Динамическая оптимизация целевого кода с использованием статистики > времени выполнения".
Ну разве что если сократить до ДОЦКСИСВЫ
Здравствуйте, VladD2, Вы писали:
AVK>>fc /b вам в руки.
VD>И где я тебе найду разные версии? Да и суров ты. Я уж лучше какой-нить гуёвой утилитой воспльзуюсь (которая сможет сравнить сразу подкаталоги).
Чего искать то? Распаковываешь дистрибутив 3 фреймворка, достаешь оттуда дистрибутив рантайма (wcu\dotNetFramework\dotnetfx.exe) и сравниваешь его с оригинальным, хотя бы из состава VS 2005. На моей машине результат ожидаемый:
FC: no differences encountered
Так что выкиньте ваши тесты на помойку, если они показывают, что "делегаты ускорились".
Здравствуйте, IT, Вы писали:
EC>>Как-то студия отказалась ставить бряку в теле тривиального сеттера (или геттера) в отладочной версии и сказала, что метод был оптимизирован, вот я и подумал, что инлайнинг случился. Если это не инлайнинг, то что тогда?
IT>Может ты релиз пытался отлаживать?
Здравствуйте, Cyberax, Вы писали:
C>Вообще-то, серверная и клиентская JVMы заметно различаются в Java. C>Клиентская GC имеет более простые алгоритмы HotSpot'а, оптимизированые C>для быстрого запуска приложения.
Сюрприз — у .NET тоже два рантайма — mscorwks.dll и mscorsrv.dll
... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>
AndrewVK wrote: > C>Вообще-то, серверная и клиентская JVMы заметно различаются в Java. > C>Клиентская GC имеет более простые алгоритмы HotSpot'а, оптимизированые > C>для быстрого запуска приложения. > Сюрприз — у .NET тоже два рантайма — mscorwks.dll и mscorsrv.dll
К чему бы это? Я ничего про .NET не намекал, а только отвечал на тезис
Влада о том, что серверная и клиентская JVM отличаются только
настройками GC.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
А я то сначала подумал, что человеку хочется просто писать в синтаксических деревьях...
в текстовом редакторе это сделать быстрее. А в IDE которая предоставляет навигацию вобще моментально. И не нужны тут никакие деревья.
1.2.0 alpha rev. 655
.
Если нам не помогут, то мы тоже никого не пощадим.
