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