.Net Framework в интересах диалектики – 3.1.
(Минусы платформы .Net Framework (Microsoft Corp.). Некоторые функциональные аспекты ряда ресурсов, реализованных на её базе. К теме «Платформа .Net Framework и логика».)
- 06.04.14 г. -
>> Как следует из анализа платформы .Net Framework (Microsoft Corp.), в обычном программировании бытие превалирует над умом программиста, а не ум программиста над бытием.
И в ряде случаев программисты, на самом деле, не могут дать гарантии правильного исполнения программ сложных программно-аппаратных комплексов, обрабатывающих недетерминированные внешние сигналы.
А в диалектике из бытия выводятся и реализуются позиции (алгоритм) управления им.
1. Предметная часть.
В предыдущей статье («.Net Framework в интересах диалектики – 2доп») обнаружилось то, что концептуальные моменты ресурсов платформы .Net Framework и формы их позиционирования имеют некоторую логику, или связаны с логикой. Причем это соотношение оказывается настолько богатым, что обусловливает тему «Платформа .Net Framework и логика» (именно такое название актуально, но об этом позже). И это не должно казаться удивительным.
При этом, что более важно, как уже отмечалось на сайте, платформа .Net Framework вобрала в себя знания, опыт и практику многих тысяч программистов, и это всё может укладываться в неё только в рамках неких правил, некой логики. Или моменты знаний, опыта и практики могли быть хоть как-то собраны в какое-то цельное только благодаря логике (хотя это было сделано на эмпирической основе, как и во многих науках, и с недостатками, уже обусловившими известные и широко обсуждаемые программные негативы).
Эти вопросы подлежат изучению.
Однако они нигде и никогда не рассматривались ранее, что следует из анализа материалов корпорации Microsoft и, главное, многочисленных обсуждений на форумах. Но их изучение нужно современной диалектике, так как позволяет выявлять весьма значимые алгоритмические, системно-программистские и даже гносеологические положения. Поэтому указанные и другие вопросы активно изучаются в Новейшей философии.
Даже частный вопрос – логика платформы .Net Framework (это часть темы «Платформа .Net Framework и логика») – это весьма обширный и сложный вопрос. И его следует начинать обсуждать с отдельных, хорошо понятных положений, которые, правда, нельзя сразу связать в некое целое. (Полная совокупность положений, их соотношения и проч. – это вопросы других исследований, которые, несмотря на их сложность, надеемся, будут интересны пользователям, и тогда соответствующие обсуждения по предметным направлениям будут продолжены. Но это уже по пожеланиям пользователей сайта. Хотя в дискуссиях некоторые вопросы и пути их решения могут быть обозначены.)
А пока, начиная с этой статьи, достаточным будет обозначить ряд разделов темы «Платформа .Net Framework и логика», которые, с одной стороны, покажут богатство палитры её вопросов, а, с другой стороны, определят отдельные важные вопросы и направления (разделы) исследований. (При этом, главное, они создадут базу для важного вывода и поиска путей его реализации, которые будут обозначены в следующих статьях.)
Для определенности начнем с того раздела темы «Платформа .Net Framework и логика», который касается методологических, алгоритмических и системно-программистских вопросов, точнее – с одного многогранного вопроса этого раздела, который специально вынесен в отдельную статью, так как, с одной стороны, является переходным от предыдущего обсуждения, а, с другой стороны, отражает значимую проблему, хорошо обозначающую всю тему.
I.
А. Некоторые из обсуждаемых ниже вопросов уже были рассмотрены на сайте как в связи с аспектами диалектического программирования, так и в связи с ресурсами платформы .Net Framework. Но сейчас следует рассмотреть группу положений, для наглядности поясненную на примерах ряда известных конкретных ресурсов, которая, с одной стороны, касается алгоритмических и системно-программистских аспектов и будет всем понятна, однако, с другой стороны, довольно ярко обрисовывает вопросы, возникающие в смысле логики платформы .Net Framework и являющиеся именно переходными к ней. Это некоторые функциональные аспекты ряда широко известных ресурсов платформы .Net Framework (напомним, в предыдущей статье рассматривались концептуальные моменты).
Важное достоинство этой группы положений заключается еще и в том, что их рассмотрение является прямым продолжением рассмотрения концептуальных моментов ресурсов платформы .Net Framework, т.е. некоторым образом восполняется пропущенная в предыдущих статьях функциональная сторона исследований.
Таким образом, предлагается рассмотреть совокупность аспектов, новых по отношению к предыдущим изложениям и обсуждениям, а также новых для обычного программирования. При этом будет решаться ряд задач. Обозначим две из них.
Во-первых, необходимо показать наличие перехода к теме «Платформа .Net Framework и логика». А это лучше сделать путем развития исследований от уже обозначенных концептуальных моментов ресурсов платформы .Net Framework к функциональным аспектам её ресурсов. Конечно же, обозначается лишь часть перехода, да еще на примере только четырех ресурсов и как бы «наискосок». Но и вопрос-то – лишь указание на наличие перехода к теме «Платформа .Net Framework и логика», точнее – к ряду её базовых разделов (некоторые из которых будут рассмотрены в следующей статье).
Во-вторых, необходимо рассмотреть те положения, которые интересны именно диалектическому программированию, да и диалектической гносеологии в целом, а не сторонним лицам (хотя другие вопросы и положения можно будет обсудить отдельно).
Причем рассмотрены будут только критичные моменты приводимых ниже ресурсов, которые лишний раз подтверждают неслучайность известных негативов, в т.ч. указанных в статье «.Net Framework в интересах диалектики – 2». Правда, не понятно, почему программисты не уделяют им внимания. А вот для диалектического программирования и для лиц, заинтересованных в обсуждении новых форм программирования, актуальны более широкие исследования, чем обычные программистские темы. Это станет понятным по ходу изложения настоящей статьи.
Итак, ниже рассматривается лишь некоторое, достаточное для настоящей статьи количество ресурсов, так как их исследование в совокупности с другими – это отдельная большая тема, которая в большей мере относится к темам решения конкретных проблем и исключения негативов, а для обозначенного в данной статьи вопроса достаточным является рассмотрение нескольких ресурсов. И группы вопросов «другой диагонали» – это также темы других обсуждений.
Также пока не будем затрагивать диалектику недочетов программных ресурсов (это – отдельная большая тема, и её тоже можно обсудить в дискуссиях с заинтересованными лицами отдельно), ибо сейчас нужно акцентирование и рассмотрение а) обозначенных выше положений и б) конкретной возможности во взаимной связи с логикой в части исполнения программы.
Так что обратимся к рассмотрению некоторых функциональных аспектов четырех известных ресурсов, реализуемых на базе платформы .Net Framework (см. «Руководство по программированию в C#» ( (с) Microsoft Corp.)).
А1. Для начала обсудим одно из базовых программистских положений – полиморфизм. Его обсуждению вообще-то следовало бы посвятить отдельную дискуссию, а в ракурсе настоящей статьи следует акцентировать лишь ситуативный полиморфизм, даже только то, что этот вид полиморфизма обычно поддерживается за счет перегрузки методов.
Вопрос в том, что объявление принципиально разных и логически не связанных вариантов исполнения метода в обычном программировании обусловлено эмпирической необходимостью, а не следует из необходимости развития перегружаемого метода. Метод не развивается, а просто заменяется на другой. (То же самое может происходить и при переопределении метода.)
Могут возразить: мол, что тут плохого – в зависимости от таких-то факторов вводится и применяется такой-то метод (еще возникает возможность динамической диспетчеризации методов). Нужен новый метод взамен имеющегося? – вот, пожалуйста, он сразу же создается! Это да, и для эмпирики и для наук оно так и есть. Но это и есть недостаток используемой в платформе .Net Framework логики (иначе тут уже и не скажешь), ибо, во-первых, задача не будет решена в случае других факторов, которые попросту могут быть не учтены в принципе в силу отсутствия общего анализа ситуации при трансформации метода (а вот когда они обнаружатся … тогда программа может быть уже не нужна). Это, кстати, одна из причин того, что в ряде случаев программисты не могут дать гарантии правильного исполнения сложной программы …; а в диалектике и в диалектическом программировании всё, даже метод в алгоритме, выводится из предмета задачи и трансформируется в связи с ним и задачей до требуемой функциональности. И, во-вторых, обнаруживается то, что в обычном программировании бытие превалирует над умом программиста, а не ум программиста над бытием. А в диалектике (и в диалектическом программировании) из бытия выводятся и реализуются позиции (алгоритм) управления им.
(Так что обсуждение даже одного из базовых положений объектно-ориентированного программирования – полиморфизма – приводит к выводу о необходимости тщательного исследования вопросов, связанных с логикой платформы .Net Framework, в т.ч. в части используемых принципов программирования, создания программ и обработки данных.)
Далее, повторимся относительно рефлексивного программирования, когда фактически обрабатывается информация об известном,
Как указывалось в статье «Рефлексия и рефлексивное программирование», рефлексивное программирование предоставляет возможности, позволяющее получать сведения о типе данных – метаданные типа, но при этом фактически обрабатывается информация об известном.
И как бы красиво не смотрелась обработка получаемой информации о сборке, – когда выявляются типы и их параметры, а затем они используются с новыми данными, не обрабатываемыми (не получаемыми) исходным программным кодом, – все равно нужно знать функции типов или их членов. Например, надо знать, что делают методы – те самые, количество и типы параметров которых устанавливаются за счет рефлексивного программирования. Ведь конкретные данные в абы какой метод с подходящими параметрами не вставишь: надо заранее знать то, что в данной сборке есть именно тот метод, который нужен, и с требуемыми параметрами. То есть выявить параметры и другие метаданные недостаточно: важен алгоритм метода, а не его параметры, и, по сути, заранее должно быть известно наличие требуемого метода … метаданные которого устанавливает рефлексивное программирование. А установить его параметры – это дело десятое.
И дело даже не в том, что рефлексивное программирование не может опосредовать алгоритм типа или его члена, что и представляет собою суть вопроса, об этом уже было сказано, а в том, что в нем неявным образом заложена концептуальная ошибка понимания отражения, которая усугубляется формой построения некоторых программных платформ; но главное – это все же неверное понимание рефлексии, откуда и пошло непосредственное применение отражения.
(Рассмотренный казус легко объясняется на основе знания обстоятельств рефлексии, понимаемой, конечно же, не как самонаблюдение, не как размышление о собственном психическом состоянии и не как там еще определяют её науки: эти определения к программированию никак не приставишь. А вот гегелевские идеи, развитые в современной диалектической философии, очень даже органичны программированию и разъясняют указанный казус.
Однако самым критичным является случай, когда за отраженное принимают рефлектированную непосредственность, которая, по определению Гегеля, есть не что иное, как пустое определение непосредственности.)
Также интересны аспекты и варианты нестрогого использования ряда программных ресурсов; в частности, интересен случай вариативности делегатов.
Не будем останавливаться на этом положении, так как с ним можно ознакомиться в руководствах по программированию и в учебниках. Лишь укажем, что кажущееся раздолье, образующееся благодаря возможности несоблюдения строгого соответствия типов значений или аргументов, означает лишь наличие логических и алгоритмических «люфтов» в программе, т.е. её недоработанность. Конечно же, опытный программист «поймает», наверное, несоответствие в своей программе. А вот что делать неопытному пользователю, который может столкнуться с не имеющимися в документации случаями, причем исполняемой программы? И вопрос не только в обсужденных ранее программных сбоях и др. (см. «.Net Framework в интересах диалектики – 2»). Еще вопрос и в том, что даже оценить в целом правильность результатов будет нельзя, ибо саму такую ситуацию выловить будет невозможно (программа работает без алгоритмических ошибок, но имеют место ошибки её логики). Это тоже одна из причин того, что в ряде случаев программисты не могут дать гарантии правильного исполнения программы …
Интересным является и такое положение, как исключение (недопустимой) операции из алгоритма (!) в случае обработки исключительной ситуации (например, деление на нуль), т.е. при срабатывании программного механизма исключений (Exception).
Дело в том, что, согласно «Руководству…» и вообще, следуя логике программистов, актуален механизм, когда при возникновении в программе некой ошибки выдается установленное сообщение о ней путем создания исключения (содержащего сведения об этой ошибке), и в случае обработки исключительной ситуации выполнение программы будет продолжено.
(Дополнительно укажем, что на ошибку программная среда среагирует и при наличии обработчиков исключительных ситуаций и при их отсутствии, только в первом случае будет выдано сообщение об ошибке, и исполнение программы будет продолжено.)
При этом одним из главных преимуществ обработки исключительных ситуаций считается то, что это позволяет отреагировать на ошибку и … продолжить выполнение программы: утверждается, что и для отладки программы и для её исполнения в некоторых случаях целесообразно не прерывать её сразу при возникновении ошибки.
Однако проблемы в следующем.
При возникновении обрабатываемой исключительной ситуации соответствующая операция пропускается (и выдается сообщение). Но вот если результат этой операции (значение переменной и т.п.), согласно алгоритму, используется в программе далее, что тогда? Тогда не только будет использоваться не то значение, которое предусмотрено логикой программы (а то значение, которое было до ошибочной операции, например, заданное автоматически по умолчанию при объявлении переменной), но и изменяется логика программы. Действительно, не «спасенное» значение требуется в алгоритме, а то, которое не было вычислено. Да, оно ошибочно, но это надо исправить, ибо, казалось бы очевидно(!), пропуск звена алгоритма может серьезно влиять на ход всей программы, и выявлять другие ошибки будет вообще невозможно или попросту не нужно (например, сам алгоритм ошибочен).
Можно сказать и по-другому. Зачем вообще создавать такую программу, в которой перехватываются ошибки, т.е. они есть?!
Может, лучше создавать программу без ошибок? Лучше. Но тут выявляется положение, которое не очевидно для платформы .Net Framework и вообще для обычного программирования, и которое в диалектическом программировании формулируется так: все операции в алгоритме должны исполняться только после надлежащей подготовки данных (например, не должно быть нуля в качестве делителя, т.е. должно использоваться то значение, которое а) предусмотрено логикой программы, и которое б) допустимо и правильно, а не некое предыдущее ему «спасенное» значение).
Кстати, именно тут проявляется одно имплицитное свойство построения ресурса по образу «в себе» (см. статью «.Net Framework в интересах диалектики – 2»), в результате которого «страдает» логика программы: не всегда может быть осуществлена надлежащая подготовка данных.
Это также является одной из причин указанной выше критичности программирования, когда в ряде случаев программисты, на самом деле, не могут дать гарантии правильного исполнения программ сложных программно-аппаратных комплексов, обрабатывающих недетерминированные внешние сигналы, что очень опасно не столько в смысле широко обсуждаемых сбоев Windows, сколько из-за применения компьютеров в военной сфере, в атомной энергетике и т.д.
Другие ресурсы платформы .Net Framework и обычного программирования можно будет обсудить в дискуссиях.
Однако уже сейчас следует отметить то, что вопросы, касающиеся исполнения программы в указанных ракурсах, уже достаточно долго изучаются в диалектическом программировании, и только в нем, и являются в нем отдельной темой. Это оказалось не только важным в обсужденном смысле аспектом, но и теоретически плодотворным положением. И совершенно не понятно, почему обычное программирование не рассматривает соответствующие вопросы ни в смысле безопасности и практики, ни для развития собственной теории и программных инструментов …
А2. Итак, обозначена совокупность вопросов, которые в обычном программировании не рассматривались с указанных сторон, а в диалектическом программировании служат основой выявления и изучения принципов алгоритмической обработки данных, что, кстати, составляет отдельный предмет исследования (отсутствующий в обычном программировании).
Однако, кроме этой совокупности вопросов, касающихся обозначенных ресурсов, имеются и другие. Кроме того надо рассматривать и иные ресурсы. Также возникают вопросы, касающиеся применения совокупности ресурсов, причем в отношении данных различных типов и, главное, разных форм наследования и подчиненности.
При этом, как уже указывалось, дело не ограничивается рассмотрением концептуальных моментов ресурсов платформы .Net Framework и функциональным аспектов её ресурсов: кроме указанных и других направлений исследований возникают вопросы методологии (напр., принципы алгоритмической обработки данных) и др.
Более того, как видно, приходится рассматривать многие положения и их аспекты в ряде направлений исследований, казалось бы, в уже давно хорошо изученной программистами области. Однако программисты подходят лишь к некоторым из них и только со стороны эмпирики и по причинам конкретных потребностей и необходимости улучшения ресурсов, а это далеко не все аспекты и причины создания программных ресурсов (даже сам этот вопрос надо изучать отдельно). Поэтому в обычном программировании и были упущены многие важные направления исследований, которые обнаружились при изучении платформы .Net Framework (в этом методологическая значимость её исследований).
Отсюда напрямую следует и другие позиции исследований, как касающиеся работы программного обеспечения, в т.ч. указанные ранее (например, такие, как программная несовместимость и сбои приложений), так и … внепрограммистские, например, социальные. Как это кому-то удивительным не показалось бы, но и такого рода вопросы – социальные вопросы, связанные с программированием, – также рассматриваются в диалектическом программировании, причем как следующие из концептуальных, функциональных и других аспектов программного обеспечения (хотя используются и результаты исследований социально-экономических процессов, получаемые в других областях познания современной диалектики).
Отдельно отметим и то, что в диалектике в связи с комплексом задач диалектического программирования*, частично обусловленным указанными выше положениями, ими же дело не ограничивается.
Однако для данной статьи важным является не столько развитие вопросов, затронутых в предыдущей и настоящей статьях (это темы самостоятельных исследований, которые, правда, отсутствуют в обычном программировании, но, быть может, появятся в нём), сколько обозначение и структуризация перехода от программистских вопросов, касающихся ресурсов и их применения, к принципиально новому вопросу – к логике построения и организации программных ресурсов, в данном случае – к логике платформы .Net Framework (хотя это частный случай, пусть и достаточно значимый), являющейся частью темы «Платформа .Net Framework и логика». И при этом, кстати, колоссальную роль будет исполнять вывод о том, что в обычном программировании бытие превалирует над умом программиста, а не ум программиста над бытием.
Примечание 1.
В диалектическом программировании приходится рассматривать многие положения и их аспекты, причем по ряду направлений исследований, что было наглядно продемонстрировано материалами предыдущей и настоящей статей. Еще больше исследовательских операций следует осуществить при рассмотрении десятков аспектов некоторого конкретного изучаемого положения за счет применения сотни-другой диалектических методологических возможностей. Трудоемкость работы понятна и не требует дополнительных объяснений. Это является одной из причин компьютеризации исследований современной диалектической философии, о чём уже говорилось в статье, посвященной одной из групп задач диалектического программирования (см. «Задачи алгоритмизации диалектического познания»).
Примечание 2.
Еще раз акцентируем внимание на том, что по ходу статьи были обозначены не только вопросы моментов перехода к теме «Платформа .Net Framework и логика», но и вопросы исследования программных ресурсов, отсутствующие в обычном программировании, например, вопросы, касающиеся правильного исполнения программы в указанных ракурсах. По этим вопросам возможно взаимное обоюдовыгодное сотрудничество с заинтересованными организациями и лицами.
* На сайте уже обозначены три их группы:
- «Базовые задачи диалектического программирования»,
- «Синтетические задачи диалектического программирования»,
- «Задачи алгоритмизации диалектического познания».
[См. «Диалектическое программирование: темы исследования ресурсов» и «Диалектическое программирование: принципы алгоритмической обработки данных».]
2. Дискуссионная часть
[в рамках проекта ДИАЛЕКТИКА].
а. Обозначение исходных, предметных и целевых положений обсуждений предполагается осуществить в начале предметных дискуссий.
б. Для предметных дискуссий в рамках Академии диалектики и диалектической философии предоставляются ссылки на дополнительные материалы.
в. Вопросы, предложения, сообщения и т.д. можно присылать на сайт через Контакты, а также на различные вспомогательные и дополнительные ресурсы сайта.
г. Для новых пользователей и для новых ветвей обсуждений могут быть созданы дополнительные дискуссионные площадки; заявки и предложения присылать через Контакты.
Облачная зона по этой теме временно закрыта до новых дискуссий.