?

Log in

No account? Create an account

Категория: it

О реальности импортозамещения в области софта
lex_kravetski


Вступление



На данный момент инициативы в области озвученного в заголовке касаются только госкорпораций и имеют относительно локальные масштабы, однако ежегодные попытки ужесточить ограничения подводят к мысли, что в правительстве действительно есть люди, которые надеются целиком, всей страной отказаться от иностранного софта и перейти на отечественный софт — вкупе с софтом, разработанным в некоторых странах бСССР.

Ввиду того, что я в целом считаю сей процесс бесперспективным (о чём и будет вся дальнейшая статья), я не могу сказать наверняка, как далеко всё это зайдёт, прежде чем, либо экономика страны рухнет, либо невозможность такового перехода всё-таки станет очевидна тем, кто принимает подобные решения.

Однако давайте всё-таки представим, что некто действительно нацелился на полный переход, и рассмотрим, насколько мечты в принципе могут совпасть с реальной реализацией и чем это чревато.


Современная сфера программного обеспечения



ДальшеСвернуть )


Компенсаторные механизмы
lex_kravetski
— …а вот если тебе надо коэффициенты в химическом уравнении посчитать, то как тогда без запоминания наизусть таблицы умножения?

— Вообще говоря, я это за три секунды на калькуляторе посчитаю.

— Это если оно одно, а если их тридцать и их ещё надо варьировать?

— В этом-то случае я уж точно не буду в уме: я напишу скрипт на три строки в Mathematica, который будет по десять тысяч уравнений за секунду обсчитывать.

— Да ну, тупость какая-то.



Я давно уже подозреваю, что гордое «я зато умею в таблицу умножения» чаще всего на деле означает «я не умею в программирование и вообще в современный софт, и очень боюсь, что не смогу научиться».




20 фактов о Microsoft Word
lex_kravetski


Основная масса приведённых здесь сведений относится к современным версиям Ворда. Чем дальше ваша версия от сегодняшнего дня, тем меньше вероятность, что в ней есть та функция, о которой идёт речь. Однако минимум половина функций всё-таки присутствует и в довольно старых (в разумных пределах) версиях.

Читать целиком


Современное программирование на примере словогенерации
lex_kravetski


Современное программирование на примере словогенерации

Говоришь людям, что в современном подходе к программированию всё уже не так, как раньше — не верят. Однако не только управление памятью, но и циклы отходят в прошлое. И что там циклы — даже условия, оформленные в виде «if-then-else», в хорошем коде теперь нечасто встретишь. И перехват ошибок при помощи «try-catch».

Разумеется, на это временами возражают не только прошаренные граждане, тридцать лет назад для интереса изучавшие программирование по первой попавшейся книге, но и даже некоторые вроде бы программисты. Которые заодно постоянно порождают код, полный контрпримеров к «отходят в прошлое», поскольку не подозревают, что можно как-то иначе.

И правда, как иначе? Давно ведь сложился стереотип, что программирование — это такая особая элитарная штука для особых людей, умеющих разговаривать с компьютером на компьютерном языке. Где какие-то там регистры, прерывания, двоичное счисление, вот это вот всё.

Сейчас, конечно, уже основной носитель стереотипов не первое поколение программистов, поэтому не «регистры и прерывания», а «вложенные циклы и условное ветвление в три экрана длиной» считаются вещью, от которой решительно невозможно избавиться.

Но фишка в том, что таки можно. И люди таки избавляются. И программирование становится всё ближе к «формальному языку для человеческих рассуждений» и всё дальше от минимализма и неинтуитивности Машины Тьюринга.

ДальшеСвернуть )


Топ-7 мифов о программировании
lex_kravetski


Мифы о программировании интересны в том числе и тем, что их иногда распространяют и сами программисты тоже. Причём иногда они в них сами же ещё и верят. И даже уровень квалификации не является панацеей от этой веры — он лишь понижает вероятность того, что она действительно будет.

Поэтому не удивляйтесь, если услышите от какого-то программиста что-то похожее на изложение одного из приведённых здесь мифов.


1. Чтобы быть программистом, надо хорошо знать математику



Конечно, понимание математики — крайне полезная штука. Её активно использует подавляющее большинство наук, а все остальные науки тоже используют, но чуть менее активно. Математика, кроме того, один из лучших способов натренировать абстрактное мышление, понять, что такое «доказательство», и научиться решать задачи.

Однако ирония в том, что программирование — это не столько наука, сколько инженерная деятельность. Причём, хоть результат этой деятельности выглядит очень похоже на всякие сложные учебники, в ней математика используется в гораздо меньшей степени, чем, например, в физике или астрономии.

ДальшеСвернуть )


Миф о «простом языке для непрограммистов»
lex_kravetski
«Мы сделали язык, на котором смогут писать программы даже те, кто не умеет программировать».

В 99% случаев за этой фразой скрывается не более чем оправдание для плохо задизайненного языка. И от того, чтобы написать «100%», меня удержало только то, что я не все случаи в истории видел, поэтому, мало ли — надо дать миру шанс.

Но лично я сам ни разу не встречал, чтобы такая заявка соответствовала реальности. Каждый раз, вместо языка, на котором «смогут и не умеющие», я вижу язык, на котором даже умеющим написать что-то более-менее полезное для практики будет весьма и весьма непросто. И вызвано это, на самом деле, тем, что разработчики очередного «языка для не умеющих программировать» сами не особо-то это делать умеют. И, что ещё хуже, не особо-то интересуются этой сферой, отчего и не знают о существовании гораздо лучших, чем их вариант, языков для «неумеющих программировать», одновременно с тем отлично подходящих и умеющим программировать тоже.

Тут вся штука в том, что очень многие путают «язык, у которого очень мало команд» с «языком, на котором легко писать программы» или с «языком, на котором легко научиться писать программы». На самом деле, всё обстоит чуть ли не с точностью до наоборот: язык, у которого очень мало команд, крайне сложен и в освоении, и в использовании.

Конечно, большое количество команд — вовсе не гарантия лёгкости, однако оно совершенно точно является необходимым для означенной лёгкости условием.

Но ещё более необходимое условие — дизайн, облегчающий использование тех мыслительных конструкций, под которые хорошо заточен человеческий мозг. Тех конструкций, которыми люди пользуются регулярно. За этим как раз и скрывается та самая «близость к человеку, а не к машине», так часто фигурировавшая в рассуждениях философов конца прошлого века.

ДальшеСвернуть )

(NM – 1)-нашки
lex_kravetski
После того, как разверзлись бездны «простой и понятной» реализации игры в пятнашки на неком языке для контроллеров, похожем на блок-схемы, я просто не удержался от того, чтобы проверить, какого размера будет полная (почти) реализация этой игры на каком-то нормальном языке программирования.

И таки проверил. На языке Wolfram в среде Mathematica. Естественно, по сравнению с представленным по ссылке адовым трешем на Wolfram получилось коротко и довольно понятно.

Кроме того, когда язык позволяет думать над задачей, а не тратить всё время на многократные копипасты, в голову приходят мысли о том, как это сделать ещё лучше: ещё короче, общее и понятнее.

После этого товарищ в комментах предложил флеш-моб, смысл которого в реализации пятнашек на чём угодно — ну, на чём нравится конкретному человеку.

Однако я внесу в это размытое предложение коррективы, уточнив правила.

  1. Должен быть реализован случай для доски размера N на М


  2. Настройки размера доски можно прописать прямо в коде


  3. Сама игра должна быть представлена в графике и управляться кликами мышки


  4. С мега-дизайном можно не заморачиваться — любая графика, более-менее изображающая фишки с числами, сойдёт


  5. Должна диагностироваться победа, когда она наступила, и об этом должно писаться на экране


  6. Должно быть можно подвинуть сразу целый фрагмент ряда или столбца — от той фишки, по которой игрок кликнул, до пустого места


  7. Старт с перемешанными пятнашками, но можно не диагностировать тот случай, когда данная игра неразрешима


  8. Программа должна, блин, работать, а не быть написанной чисто «в уме»


ДальшеСвернуть )

Запах монад по утрам
lex_kravetski
Есть, знаете ли, такая фраза: «Иисус, спаси меня от твоих последователей». Удивительно, но к некоторым другим областям она тоже отлично подходит — в частности к так называемой «функциональной парадигме программирования».

В этой области явно существует какой-то закон, типа закона Бойцовского Клуба: «никому не говорить о Бойцовском Клубе», — но там он более изощрён: о Бойцовском Клубе говорить разрешается, но если кто-то, услышав о нём, вдруг решит в него вступить, то ему надо сразу же в ответ на простые вопросы задвинуть мощной метафизики со специальными терминами, которые он ни за что не поймёт, а ещё чуть-чуть пообщавшись с последователями, решит, что от этого вашего Клуба и от Иисуса вообще лучше держаться подальше.

И козырным тузом в деле отвращения человечества от прогрессивных методов разработки кода, безусловно, выступает «монада». О да, монадой вам трахнут мозг, независимо от того, что вас на самом деле интересовало. И ей же вам запулят вслед, когда вы будете убегать от всего этого кагала. Не зря, видимо, понятие «монада», кроме функциональной парадигмы и теории категорий также широко используется в эзотерике.

Но, несмотря на всё это, означенные монады действительно имеют практически полезное применение, отличное от универсального способа перевести любой практический вопрос в убедительную (в основном, для самого́ отвечающего) демонстрацию его запредельной крутизны. Собственно, когда основная цель в этом, ответ специально строится так, чтобы непонимающий и дальше бы тоже ничего не понял.

ДальшеСвернуть )



Continuations
lex_kravetski
Данная статья не содержит никаких масштабных метафор, тонких ассоциаций или суровой сатиры. Поэтому интересна она будет только программистам. Да и то не всем.

Целью данной статьи является объяснение некоторого момента, который вызывает массу вопросов, а не обучение годному стилю написания программ и не рекомендация всё тут описанное в обязательном порядке использовать.


«Продолжения». Вопросы, что это такое, и зачем оно может понадобится Scala, имеются в изобилии практически в любом месте, где Scala обсуждается в постоянном режиме. А вот ответы на эти вопросы, напротив, почти не имеются.

Но если ответ всё-таки есть, то с вероятностью 99% им будет вот этот пример.

ДальшеСвернуть )

Нейронные сети и всё-всё-всё
lex_kravetski


Снимал и монтировал не я, поэтому не надо у меня спрашивать, почему снято под таким углом и смонтировано именно так. Однако беседа — хоть она и по верхам — ничего так получилась.

Через некоторое время, видимо, с тем же математиком сделаем передачу, где будет не по верхам, а с разъяснениями и блэкджеком.



Комменты на ютюбе от людей с глубоко расширенным сознанием — внушают.

Scala. Полёт нормальный
lex_kravetski
Большинство программистов, думаю, прочитав слово «Scala», среагируют в ответ термином «WTF?». Чуть менее значительная часть скажет «что-то такое слышал, но не представляю, зачем это нужно». И лишь совсем немногие смогут похвастаться знанием этого языка. Между последней и предпоследней группой находится группа заинтересованных, но сомневающихся, так что данная статья, увы, совсем для немногих.

Мне посчастливилось около полугода программировать на Scala, и теперь я таки могу авторитетно рассуждать о нюансах девелопмента на данном языке. Самое главное, я могу ответить на наиболее часто возникающий у заинтересовавшихся вопрос «а можно ли вообще на нём девелопить?». Что для прикола поразвлечься понятно можно, но писать-то что-то полезное, оно как?

В общем, авторитетно отвечаю. Можно. Все сомнения о том, что какие-то штуки не будут работать, всё развалится в самый последний момент, возникнут непредвиденные сложности с языком, будет чего-то важного не хватать и так далее, они логичны и обоснованы, однако эксперимент показал, в случае со Scala такого не происходит. За полгода разработки я не встретил ни одной непреодолимой сложности, всё работало, из Java вызывалось и так далее.

Свои нюансы были, но не фатальные. Самый большой, видимо, — смена API работы с контейнерами, которая имела место быть при переходе с версии 2.7 на версию 2.8. Да, в Скале обратная совместимость есть далеко не всегда, однако это не только минус, но и плюс. Строгая обратная совместимость мешает языку развиваться. Однажды принятое решение остаётся навсегда, хотя вероятность не угадать даже при очень напряжённой предварительной подготовке совсем даже ненулевая. Кто как не знаю, но я с трудом верю в реюзабельность очень старого кода. Лучше получить более качественный инструмент для нового кода, чем мучиться из-за того, что новый код всё так же трудно писать в тех местах, где он завязан на неудачный, хотя и историчный дизайн за ради того, что код пятилетней давности всё ещё компилируется на новых версиях компилятора.

Собственно, мой старый код с новыми стандартными библиотеками не компилировался, однако я всё исправил довольно быстро — благо, код был написан без копипэйста, поэтому править пришлось мало где.

А без копипэйста он был написан благодаря тому, что написан на Скале. Да, во всех языках предлагают копипэйстить по минимуму, но в большинстве случаев это не удаётся, даже если очень хочешь. В первую очередь потому, что в той же, например, Java (и в C++ тоже) некоторые вещи, будучи обёрнутыми во что-то некопипэйстное, занимают даже больше места, чем с копипэйстом. Когда есть способ написать вместо десяти строк одну, то возникает соблазн написать одну. Если вместо десяти строк «по уму» следует написать восемь или тем более пятнадцать, очень тяжело побороть желание временно скопипэйстить, а в никогда не наступающем «потом» всё исправить на «как надо».

В плане возможностей преодоления копипэйста Скале, я считаю, практически нет равных. Любую конструкцию можно оформить так, чтобы она вызывалась из самых разных мест, даже когда контексты этих мест совершенно непохожи друг на друга.

ДальшеСвернуть )

О политических проектах на примере программирования
lex_kravetski
Если раньше сограждане тихо соглашались с тем, что дают, утверждая, будто «бесполезно трепыхаться, всё равно всё куплено», то потом они вдруг обнаружили внутри себя окончательно лопнувшее терпение, и это позволило им хотя бы внутри себя выносить оценки происходящему и делать внутренний выбор в пользу добра, даже если внешнее Зло давно всё скупило.

Способность выносить оценки, однако, не означает способности и желания действовать: даже если речь идёт о такой простой вещи, как агитация знакомых или согласованное с единомышленниками бросание бюллетеней в урну (для голосования или хотя бы для мусора). Сограждане уже научились осознавать и оценивать происходящее, но пока не научились модифицировать его. Поэтому где-то так в прошлом-позапрошлом году стартовал новый процесс: развитие способности влиять на мир.

Пока ещё эта способность у сограждан развита слабо, но со временем она разовьётся. Так же, как ранее развилась способность формулировать для себя свою позицию.

Хотелось бы поэтому дать согражданам ряд советов, которые, надеюсь, упростят и ускорят процесс обучения.

Чтобы проиллюстрировать основные ошибки, приведу, казалось бы, отвлечённый пример. Есть, положим, форум, на котором собираются любители компьютерных игр и даже некоторое количество этих игр разработчиков. На форуме в основном идут какие-то разговоры о нюансах игровых моделей, посетители оставляют отзывы о новинках и старинках, в общем, традиционное и типичное коротание времени.

Внезапно туда заходит Василий Пупкин (обычно лет 14-18) и шлёт туда пост примерно такого содержания: «Я только что придумал отличную игру. Там можно строить крепости или на них нападать, а ещё там будет настоящая экономика!!!».

Ну, придумал, казалось бы, и придумал. Однако он продолжает: «я сам программировать не умею, но тут наверно есть программисты, поэтому давайте они напишут игру, а деньги пополам!!!».

Само собой, зашедший с таким ценным предложением сразу же подвергается целому ряду насмешек и оскорблений той или иной степени замаскированности. Ему самому, при этом, кажется, будто оскорбляют его из зависти к его выдающемуся интеллекту, да и вообще все собравшиеся — серое и убогое быдло, один только он — гений, только вот, увы, программировать не умеет.

На самом деле, ошибка этого активного молодого человека состоит в том, что он неверно определил свою позицию в данном контексте. Если говорить более просто: он почему-то решил, что является заказчиком по отношению к совершенно незнакомым ему людям, хотя не располагает ни деньгами, ни навыками, ни даже авторитетом в данной области. Он мог бы с тем же успехом сказать: «пацаны, я придумал, давайте вы устроитесь на работу, а мне будете отдавать половину своей зарплаты». Примерно так.

Сделка, которую он предлагает, настолько очевидно невыгодна потенциальным реализаторам идеи, что они её трактуют либо как издевательство, либо как демонстрацию вопиющей глупости. Оттуда насмешки в адрес «автора гениальной игры».

ДальшеСвернуть )

Про либеральные подходы к программированию
lex_kravetski
Граждане делятся ценными сведениями:

Давайте ка посмотрим на то как ведут себя программы при модульном подходе: есть некий модуль который содержит в себе управляющий код(точка входа в программу ....) она реализует две модели при модульном подходе это либо так называемые "поток преобразования" либо "Диспетчерская" в разных учебниках по технологии программированию их по разному называют, суть их же заключается в том что при "потоке преобразования" управляющий модуль вызывает модуль который выполняет основную работу, но перед этим может выполнить некоторые преобразования входных данных, но при условии что управляющий модуль знает какие имеются вспомогательные модули, это первый ключевой момент для обеих моделей при модульном подходе. УПРАВЛЯЮЩИЙ МОДУЛЬ МОЖЕТ ВЫЗВАТЬ ТЕ МОДУЛИ О КОТОРЫХ ЕМУ ИЗВЕСТНО!

Второй ключевой момент состоит в том что если происходят какие то изменения в системе, то управляющий модуль должен последовательно обновить, изменить или еще что то , в общем как то повлиять на всю систему и выполнить он это может только путем вызова методов конкретных подсистем, а для этого ему необходимо знать все особенности и нюансы всех подсистем. Если таких подсистем много, то выполнить синхронизацию очень сложно, к тому же если возникает у одной подсистемы необходимость повлиять на другую подсистему, то выполнить это можно только через управляющий модуль, что очень часто с ростом программной системы приводит к так называемой циклической связи между модулями, которую при модульном подходе отследить очень сложно! К тому же с ростом системы и увеличения количества подсистем, цикломатическая сложность управляющего модуля просто зашкаливает, можно конечно выполнить декомпозицию управляющего модуля, но выполнять декомпозицию можно только до какого то предела!

(источник)


Вот так вот, друзья мои. С точки зрения современников, до наступления сегодняшнего дня был адский ад. «Модульное программирование», — не смотрите, что самим своим названием намекает на концепцию «модуля», — это когда каждая программа написана в стиле «волшебный метод». До внедрения ООП все писали только так. Все подсистемы взаимодействовали между собой строго через «УПРАВЛЯЮЩИЙ МОДУЛЬ, КОТОРЫЙ О НИХ ЗНАЛ».  И сам лично во всех подсистемах всё менял. Поскольку, системы подписки не существовало!!! Даже функция qsort, поди, сортировала только то, что было известно разработчикам стандартной библиотеки. И только так, как они хотели.

Мне завсегда нравятся оба замечательных подхода: объявить, что предки были умные, а мы все — дураки, и наоборот, объявить всех предков дураками, а себя лично — умным. Раз у предков не было ООП, разумеется никто из них не догадывался, что можно абстрагировать компоненты и локализовать взаимодействие между модулями.

Как тут строится логика рассуждений? «Я недавно прочитал книжку про ООП, а до того писал на Бейсике. Само собой, моя программа на Бейсике состояла из одного огроменного куска кода, без функций и подпрограмм. Но в книжке про ООП написано, что так писать плохо! А ООП позволяет писать хорошо! У предков не было ООП, следовательно, они наверняка писали, как я раньше на Бейсике. То есть, плохо писали».

Слава богу, положение исправилось.

При объектном подходе есть Управляющий класс, у которого есть события, которые оповещают о каких то изменениях, и есть подсистемы, которые при необходимости могут зарегистрировать свой обработчик данного события, в добавок каждая подсистема может указать свои события на которые может подписаться другая подсистема, что в результате приводит к тому, что у Управляющего класса нет необходимости держать в голове все особенности каждой подсистемы. В результате работа Управляющего класса сводиться к тому что бы инициализировать подсистемы, предоставить им контекст для взаимодействия и следить за тем что бы каждая подсистема работала как того требуется! А подсистемы сами решают реагировать им на какое то событие или нет, и как реагировать, что в свою очередь очень сильно упрощает дальнейшее расширение системы и делает ее более предсказуемой.

(там же)


Вместе с объектным подходом, понимаете, к нам пришла Свобода и Демократия. Теперь подсистемы сами решают, реагировать ли им, как реагировать и зачем реагировать. Вот где успех-то: подсистема если хочет — делает, а если не хочет, так не делает. Тут вам уже не тоталитаризм, где Главный Управляющий Модуль навязывает угнетённым подсистемам свои правила. Фиг там. Любая подсистема может самовыразиться и, например, сделать всё наоборот. Ну, чтобы быть не такой как все. Неясно, правда, как при этом «Управляющий класс следит, чтобы каждая подсистема работала, как того требуется», но в этом как раз и зарыта самая-самая трансцидентальность. Подсистема реагирует как хочет, а Управляющий класс — следит. Так-то!

Если кто не понял, именно в этом самая суть ООП. Вы, дурачьё, думали, будто ООП дал нам удобный способ записи понравившихся многим программистам сценариев организации кода, а на самом-то деле он, эвон как, внедрил Свободу и Демократию.

Уже, знаете ли, хочется внедрить либеральное программирование. Ну, например, ввести конкуренцию между трэдами за процессорное время. Продажу возвращаемых значений на бирже. Тендеры среди объектов за право предоставить требуемую объектом-заказчиком функциональность. Систему импичмента методу main. Написать, наконец, Декларацию Прав и Свобод инкапсулированных сущностей. И Невидимую Руку в качестве диспетчера последовательности исполнения.

Несогласные, надеюсь, согласятся, и Каспаров ещё скажет своё веское слово по данному поводу.




Про странные совпадения
lex_kravetski
Если компьютер, — как с точки зрения широкой общественности единогласно утверждают медики, — действительно портит зрение, то почему я не знаю практически ни одного программиста в очках? Точнее, единственный программист в очках, которого я знаю, — Вассерман, — давно уже не работает программистом, причём он, по ходу, носил очки ещё в институте. Программистов при этом я знаю человек сто минимум. Какое странное совпадение.


Как-то раз был на собрании одной коммунистической партии. Там человек в годах заявил, что ориентироваться на всяких там программистов не сто́ит. Дескать, рабочая молодёжь ещё, быть может, пойдёт в компартию, а вот программисты — никогда. Они, дескать, слишком хорошо устроились в современности. Многие его сверстники полностью поддержали данный тезис. Оглядев зал, я вдруг осознал, что все собравшиеся здесь люди, возрастом младше тридцати лет, — программисты или сисадмины. Какое странное совпадение.


Почему-то на страшную занятость чаще всего ссылаются и жалуются те, кто не в состоянии предъявить сколь либо ощутимых результатов своего труда. Регулярно выдающие вагон результатов люди почему-то запросто встречаются с друзьями, знакомыми и незнакомыми, помогают всем подряд без капризов и ещё умудряются развлекать себя разной ерундой. Однако спроси постоянного занято́го по его словам человека: «а что ты всё это время делал?», — в ответ неизменно слышишь: «то, сё, пятое, десятое, крутился-вертелся», — и крайне редко: «написал книгу», «построил дом», «открыл ранее неизвестный закон природы». Какое странное совпадение.


Словом «эгоист» почему-то наиболее часто называют того, кто отказался делать всё так, как того хотел назвавший его словом «эгоист». Какое странное совпадение.


Много раз слышал, вежливость — лучший способ убеждать людей. Почему тогда в армии, где убеждение людей выполнить приказ жизненно важно, изъясняются не высоким штилем, а в основном матом? Какое странное совпадение.




Отвоевал своё
lex_kravetski
В своё время мой отец очень доходчиво мне объяснил, почему он никогда не ходит в туристические походы: «Я воевал четыре года в окопах. После этого идея ехать в лес с палаткой кажется мне несколько странной».

Теперь я так же объясняю сыну, почему я не использую линукс: «Я работал на множестве разных компьютеров, начиная с БЭСМ-4...»

(источник)



Ну, понеслась!