?

Log in

No account? Create an account

Категория: it

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


Вступление



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

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

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


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



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


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

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

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

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

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



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




20 фактов о Microsoft Word
lex_kravetski


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

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


Ферзи и множества
lex_kravetski


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

Иными словами, никакие два ферзя не должны находиться на одной горизонтали, вертикали или диагонали — именно так ведь ходит ферзь.

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

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

Казалось бы, а чего тут такого? 1 — есть на этом поле ферзь, 0 — нет ферзя. Переберём все варианты, для каждого проверим, не бьют ли какие-то ферзи друг друга…


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



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


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

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

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

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

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

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

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


Многозначная логика своими руками
lex_kravetski


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

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

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

Это, впрочем, не умаляет реальной содержательности того, что он упомянул — пусть даже он и не понимает его устройства. Заблуждение тут не в том, что «он думает, будто существует нечёткая логика, но на самом деле такой нет», а в том, что «он думает, будто бы нечёткая логика — альтернатива формальной, но на самом деле…».

Что же должно в данном случае следовать за «но на самом деле…»? Если это не «альтернатива», то что? Дополнение? Развитие? Усовершенствование?

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


Топ-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
Есть, знаете ли, такая фраза: «Иисус, спаси меня от твоих последователей». Удивительно, но к некоторым другим областям она тоже отлично подходит — в частности к так называемой «функциональной парадигме программирования».

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

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

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

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



Deep Learning: история и современность
lex_kravetski
Анатолий Левенчук. Интеллект-стек, Ч. I. Deep Learning: история и современность



Анатолий Левенчук, эксперт в сфере Deep Learning, президент консалтинговой компании «ТехИнвестЛаб.ру», директор по исследованиям Русского отделения международного совета по системной инженерии (INCOSE), член исполкома Русского отделения SEMAT. В первой части Анатолий делает обзор исторического развития и современного состояния области Deep Learning.

Организатор: Щепотка Соли — https://vk.com/granumsalis
Съемка: XX2 Век — http://22century.ru/

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

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


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

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

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

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


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

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



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

О способе публикации статей
lex_kravetski
Короткую заметку в стиле смс-сообщения, разумеется, можно написать в авторском веб-интерфейсе блога или сайта. Более того, многих как будет выглядеть их текст настолько не парит, что они ровно там же пишут и длинные статьи тоже.

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

Если писать заметку в Ворде (или во Врайтере ОпенОфиса), то сделать хорошее оформление для статьи ощутимо проще. Там есть стили, спецприблуды для вставки таблиц и схем из других приложений Офиса и всё такое. Не InDesign, конечно, но вполне на уровне. Однако после написания текста его ещё надо опубликовать. Во всех офисах есть экспорт в html, но результат экспорта слабо подходит для переноса в блог или на некий сайт. Я написал макрос, упрощающий перенос, но это тоже дополнительные клики — особенно тогда, когда в тексте до фига иллюстраций.

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

ДальшеСвернуть )
Метки:

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

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

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

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

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

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

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

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