Привет, друг.
Повезло, что ты посмотрел на свет, ведь я собираюсь рассказать сказку.
Об эпохах настоящего и прошлого, о пределах возможностей кодера и о том, как, отказывая себе в силе, можно достичь силы.
А если тема парадигм вас не интересует, продолжайте листать и сделайте вид, что не слышали о моей сказке.
Если вы выйдете в свет, то должны знать, что рассказчик ради красивого слова не всегда соблюдал хронологию и все перегибы и упущения лежат на его совести.
Вначале было машинное слово и только дух витал над компьютером.
В те далекие времена компьютеры были большими по размеру, программисты – высокими и сильными, а их программы – короткими и прямыми, как стрела.
Кроме самого кода не было ничего, и это было хорошо.
По мере того как программисты становились все более искушенными, а программы множились и становились более сложными, стало ясно, что программисты слишком могущественны и что избыток власти ведет не к эпохе изобилия и процветания, а к раздорам и трагедиям.
Создавая по собственному изобретению, программисты черпали силы из вод Хаоса первозданной вседозволенности, которая вопреки воле создателей, а иногда и по его желанию, высверливалась из каждого байта машинной инструкции.
Кто бы столько ни сделал в далекое время, не было общего видения и понимания.
Программисты увидели, что они слишком мощные, и это затрудняет написание и масштабирование кода.
И они поняли, что правила им нужны для того, чтобы держать свою власть в заданных пределах и получать предсказуемые результаты, а не какую-то туфту.
Тогда они собрались и создали парадигмы, чтобы навсегда закрепить свою власть.
И они создали кольца, чтобы обуздать свою власть.
Первым волшебным кольцом стало процедурное программирование, поскольку существовала широко распространенная потребность снова и снова выполнять одни и те же действия с данными.
Чтобы не прописывать подобные действия по сто пятьсот раз, мы решили выделить кусок небольшого кода, который будет выполнять намеченную работу и делать ее хорошо.
И программисты решили регулярно обращаться к нему, как к волшебнику и великому мудрецу.
Программисты создали процедуры, посмотрели на них и поняли, что это хорошо.
И с тех пор они ими пользуются.
Широкое распространение процедур и функций привело к тому, что программы стали достаточно унифицированными.
Вместо первозданного хаоса и всевластия над регистрами программисты умерили свои возможности и ввели в свой код стиль подпрограмм и аргументов.
Хотя программисты еще могли делать с процессором все, что позволял производитель, они решили, что преимущества процедурного стиля важнее их гордости.
Потому что их соблазнила возможность не повторять когда-то написанное, возможность ограничить область необходимого мгновенного интеллектуального охвата и возможность вылизать код кристально чисто, не весь сразу, а задачу за задачей.
.
И они отдали часть своей власти, потому что они уже не писали иначе, чем то, как им начала подсказывать парадигма.
И наступила процедурная эра.
Тем временем в мир пришли новые программисты, и они не были такими возвышенными и сильными, как их предшественники, и им было трудно понимать машинные слова.
А потом вместе они создали для себя инструменты, чтобы преодолеть свою слабость, и так появился сначала Ассемблер, а позже Фортран и Алгол.
Стало немодным управлять машинным кодом и напрямую доминировать над процессором.
Дайте компилятору поработать, сказали программисты, и они потеряют часть своей мощи и ослабят хаос.
При этом процессуальная парадигма была окончательно возведена в ранг права.
Но программисты не унимались и начали желать интерактивности и изобрели технологию repl, чтобы можно было придумывать и реализовывать свои мелочи, не отходя от кассы, и именно в это время появились прототипы первых интерпретаторов.
А вскоре из репла вышли скрипты и мир разделился между машинными программами и интерпретируемыми скриптами, и было счастье в то время, потому что всегда было понятно, где программа и где скрипт, а не так, как сейчас, когда интерпретируемое компилируется, а скомпилированное интерпретируется.
Программисты были еще дальше от железа и уже не знали, как работает АЛУ, потому что появилась ОС и уже не нужно было знать железо, о чем, впрочем, никто не горевал, пока все махали, улыбались и радовались.
Мир в ту эпоху был долгим, но прогресс не стоял на месте.
Программисты хотели не только писать код, но и периодически читать его, чтобы поддерживать и масштабировать.
И они поняли, что им это сложно, потому что даже мощности процедурного кольца не хватило, чтобы навести порядок в коде.
И тут пришел один техношаман, которого звали Дийкстра, и ему помог Вирт. 
Дейкстра повысил голос и впоследствии, вооружившись теоремой Бема-Якопини, злоупотреблял оператором goto, утверждая, что колдовство этого оператора порочно и магических слов while, for и if должно быть достаточно для любого хакера.
И сказав это, он изгнал гото, лишив сообщество ещё одного мощного инструмента, а прогеры затем создали кольцо структурной парадигмы, чтобы прославить подвиг шамана во веки веков.
goto опечалился, но не поддался героической тирании, и даже сейчас нет-нет-да проскальзывает в код другого кодера, ностальгирующего по былому величию, и сбивает его с толку.
Программист робко оглядывается по сторонам, не видит ли это кто-нибудь, ставит метку, пишет goto и прячет свою процедуру в отдаленный файл, чтобы никто не увидел, а затем слезы на глазах у статического анализатора, когда он видит код вот так, потому что статические анализаторы не умеют работать, когда парадигма не соблюдается.
Код стал красивым, размеченным табуляциями и скобками, обрамленным циклами и блоками.
Программисты были благодарны техношаману и его теореме, и командное взаимодействие между программистами, хакерами и программистами стало улучшаться, потому что стало возможным не только писать код, но и периодически его читать и даже понимать.
В то время шаманы увлеклись темой искусственного интеллекта и задумались о том, как создать машинный мозг, родить гомункула, заставить его выполнять черную работу.
А потом создали Пролог, экспертные системы и теорию автоматического доказательства и потихоньку придумали еще одну парадигму и назвали ее логической.
Мало кто понял, что это за парадигма и в чем ее суть и суть, но для порядка включили ее в книгу и присвоили номер.
И забыли об этом, потому что это не вписывалось в парадигму, потому что было слишком узко и оригинально.
Тем временем, благодаря структурной парадигме, команды программистов начали создавать продукты, множить свой код и делиться своим кодом, и они поняли, что перед ними снова возник предел, потому что код их программ разваливался под собственными силами.
вес, достигнув определенного размера.
Но были инженеры с вооружёнными глазами и они увидели проблему задолго до того, как она стала полностью видимой, и Simula и Smalltalk были созданы их руками, и Алан Кей произнес свою речь.
Но речь была слишком умной и она смущала программистов, их детей и детей их детей, и увы, детей их детей и еще многие поколения будут смущать и будут смущать, потому что вместо луны над водой кодеры смотрели на палец, и вместо декомпозиции и иерархии видели инкапсуляцию, полиморфизм, наследование и описание объектов реального мира, а во время просмотра закусывали абстракцией, что конечно же не имело ничего общего с истинной сутью ООП, но лишь немного повлияло на внешнюю форму.
Тогда Алан Кей загрустил и сказал, что C++ — это не настоящее ООП, но было уже поздно, потому что шум был такой, что ни сказкой, ни пером его не описать.
Однако нет-нет, но дело пошло, и программисты без особых проблем научились объектному мышлению, связывали данные с кодом, собирали объекты из объектов и тем самым декомпозировали код и строили его иерархически.
И мы научились использовать интерфейсы, и дело наконец-то стало лучше, потому что программы теперь делились не только на процедуры, но и на объекты и их методы, что снизило связность программ и повысило удобство чтения кода.
А что касается обмена сообщениями, о котором говорил Алан Кей, то о нем забыли, потому что решили, что нехорошо праведным кодерам писать письма, когда можно напрямую зайти в гости, лишь бы интерфейс соблюдался.
И на эту же тему спустя долгое время вышла эпическая битва между святым воином Торвальдсом и почитаемым мудрецом Таненбаумом, но это уже другая история, казалось бы, речь вообще не об этом и почему здесь упомянуто непонятно, а заботятся ли мы, простые кодеры, о делах святых воинов и почитаемых мудрецов, чтобы лезть.
С тех пор и до сих пор наступила эпоха объектной парадигмы, и программирование без объектов немыслимо, но и здесь были недовольны и говорили правильные слова, что ООП-программное обеспечение тормозит и его избыточность увеличивается, а качество программ снижается, потому что Это потому, что интерфейсы слишком жесткие и вам приходится делать много ненужных действий, но остальные программисты их не слушали и выкатили иерархии объектов в продакшн, и создали Java, и DotNet. И потихоньку кинули на всё память и богомипы, чтобы повысить производительность и заткнуть наконец глотки недовольным.
Писать бесклассовый код стало немодно, хотя классов в машинных словах нет и никогда не было, а потому кодеры все дальше и дальше отходили от своей изначальной природы и уже не могли управлять процессором на полную мощность и управлять машиной фон Неймана из сердце к генератору тактовых импульсов.
Тем временем учёные не унимались и продолжали споры о том, как правильно написать код, чтобы не допустить ошибок, чтобы он выполнялся предсказуемо и не удивлял создателей своим поведением и нравом.
И решили, что чистота и неизменность — это хорошо, а глобальные переменные и побочные эффекты — это зло.
И это было хорошо, но еще говорили, что отображение информации на экране должно быть отформатировано как возврат от функции модифицированного объекта вселенной, что все есть монада, что теория категорий командует типами, а также что уменьшить, отобразить, выбрать и другие слова пугают. И в конце концов, Haskell был придуман, чтобы всех окончательно запутать.
Программисты чесали затылки, не понимали, что функциональное программирование — это про объекты, только неизменяемые и без глобализма, но решили, что это сложно и непонятно, а кто понимал FP — это какая-то заумная монада.
Однако концепция чистых функций прижилась, и программисты затем научились писать юнит-тесты, а позже по какой-то причине была изобретена непрерывная интеграция.
Стоит отметить, что хотя научные умы всегда писали математический код, термин неизменяемость не особенно применим к базовым типам, и поэтому функциональная парадигма не возникла раньше объектной парадигмы, поскольку речь идет об объектах, а не о математике.
неважно, что кто-то думает и утверждает, а если программист пишет не объективно, то он точно не сможет писать функционально.
Но если он откажется менять состояние своих объектов, то получит строгую логическую цепочку вывода, а заодно и возможность кэширования и мемоизации.
А все, что касается монад и композиций функций, — это метод, а не результат, и палец, а не луна.
Итак, в очередной раз отдав часть своих сил, программисты научились добавлять в свой код новые свойства и, ограничивая себя в одной области, стали сильнее в другой, но хорошо это или плохо — не мне судить.
Пока разрабатывались скрипты и интерпретаторы, нашлись немытые кодеры, которые решили, что не хотят объяснять процессору, как построить дом, а просто хотят сказать, каким он должен быть и как он должен выглядеть снаружи и как интерьер должен быть как изнутри.
И они создали языки разметки, и xaml, и yaml, и css и много других интересных вещей, и в то же время попутно породили веб и постулировали декларативное программирование.
А для тех невежд, которые не хотели описывать свои мимолетные желания, а так же, как и раньше хотели класть кирпичи, они презрительно называли все недекларативное императивом и тем самым породили дихотомию императивной и декларативной парадигм.
Кодеры, вымытые и чистые, посмотрели на это, пожали плечами и сказали: «Ну, ладно… Вроде тоже неплохо».
И вот теперь мир стал таким, каким мы его знаем и нам следовало бы перевести дух, но другая важная парадигма прошла мимо нас незамеченной.
Хакерам и программистам не удалось императивно описать ряд задач, связанных с обработкой данных, поступающих непрерывным потоком или в непредсказуемые моменты времени, поскольку невозможно императивно обрабатывать то, что непонятно когда и в каком количестве попадает в система.
А затем программисты и хакеры создали виджеты для графического интерфейса, сервисы для Интернета и конвейеры для обработки данных и связали реакции, qt и simulink с labview в парадигму, управляемую событиями, или реактивную парадигму, что по сути одно и то же, потому что обратное код Им пришлось строить его на обратных вызовах и конвейерах.
На этапе инициализации они один раз строили структуры обработки данных, а после этого только пересылали через них информацию и считали, что это хорошо и действительно так, потому что по-другому никто никогда не умел, и никогда не узнает, и вряд ли они когда-нибудь узнают. .
Множество других колец выплавили программисты, написали умные книги и провели конференции.
Тут вам и аспектно-ориентированное, и компонентно-ориентированное, и реактивно-функциональное, и прототипическое, что тоже ООП, но в другом смысле.
Однако всегда и везде суть парадигмы в том, чтобы ограничить свои возможности и свои инструменты, O Coder, чтобы результат вашей работы имел дополнительную мощь, ведь свойства вашего программного кода зависят от того, какие инструменты вы используете и как.
Воистину, древний мудрец сказал еще во времена до сотворения мира: Получить что-то можно, только отдав что-то.
И если у вас на душе стало грустно после моего рассказа об утрате великой державы, то я вам вот что скажу.
Не клевещите на своих предков, ибо дела их были совершены во благо, а помыслы их были чисты и возвышенны.
И как вы думаете о них, так и все ваши внуки и правнуки будут думать о вас.
Если вы чувствуете в себе желание создать еще одно кольцо и изобрести новую парадигму, подумайте дважды, ведь никогда нельзя знать заранее, какое из ваших детищ останется на века.
Это мой завет и мораль.
А тем временем сказка закончилась.
И кто слушал, тот молодец.
При создании сказки не пострадала ни одна парадигма.
Пока друг.
Теги: #Популярная наука #ООП #Функциональное программирование #Изучение языков #фп #сказка #парадигмы программирования
-
Самый Полный Анализ Google Glass
19 Oct, 24 -
Рост Стоимости Ведения Бизнеса В Неваде
19 Oct, 24 -
Как Правильно Выставлять Счета-Фактуры
19 Oct, 24
