Здравствуйте, 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.
. Вполне допускаю, что там и unmanaged кода полно.
