Metaprogramming
614 subscribers
103 photos
1 video
156 links
μετά- «между, после, через» (греч.)

Жизнь программиста за пределами программирования: алгоритмы, психология, инвестиции, иное.
Download Telegram
Мысли каждого программиста - кого раньше, кого позже - в какой-то момент времени начинает занимать идея некоего "аналогового" хобби. Для кого-то это путешествия, для кого-то прогулки на природе, для кого-то спорт.

Для меня это идея научиться пилотированию.

В прошлый раз эта идея сконцентрировалась до неких конкретных действий лет десять назад. Я тогда набрал тривиальный запрос в Гугле, мол, "получить PPL без регистрации и sms"

Из результатов запроса следовало, что только вокруг Москвы имеют место десятки "любительских" аэродромов, на каждом из которых за умеренную плату примерно в 300к рублей готовы научить по любому удобному графику полётам с выдачей "авиаправ" (той самой PPL) на выходе.

На днях я, повторно поддавшись давнему вдохновению, ввёл тот же запрос.

И не нашёл вообще ничего.

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

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

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

Шесть штук (не берём в рассчёт вертолёты, аэростаты и автожиры).

В России примерно столько же лётных школ для частных пилотов, сколько в Латвии (напомню, население ~2 млн.).

Ну а для желающих стать пилотом - вот результирующий набор ссылок:

https://nebosvod-avia.ru/contacts.html
https://artraining.ru/
https://fs.aerograd.ru/
https://siberianairbase.ru/pilot-training/
https://a-54.aero/
https://s7-training.ru/

Медианная цена - 900к.

По всем признакам авиация у нас под прямым воздействием "ингибирующего поля". Но про это как-нибудь потом.

#hobby #economics
Дисклеймер: всё нижесказанное не является инвестиционной рекомендацией - более того, автор не является ни профессиональным инвестором, ни даже успешным инвестором-любителем - это просто фантазии на некую интересную тему.

Как известно, в период золотой лихорадки надо продавать лопаты. В период "инвесторской лихорадки" очевидными лопатами являются сами биржи и брокеры.

В России две биржи: Московская и Санкт-Петербургская. Ликвидны только акции первой (MOEX).

Рассмотрим десяток брокеров, у которых наибольший прирост клиентов за последнее время. Из них публично торгуемыми и, по совпадению, топом-3, являются (в указанном порядке) Тинькофф (TCSG), Сбербанк (SBER, SBERP) и ВТБ (VTBR).

Ну, Сбербанк и ВТБ много чем помимо популяризации инвестирования занимаются. В итоге получаем тривиальную идею покупать TCSG и MOEX - как-то не очень интересно, но всё равно забавный вывод.

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

- NYSE - ICE
- Nasdaq - NDAQ
- London Stock Exchange - LSE
- Hong Kong Exchange - 388
- Euronext - ENX
- Toronto Stock Exchange - X
- Xetra/Börse Frankfurt - DB1
- Singapore Exchange - S68

Список для желающих поставить на новую "биржевую лихорадку" :)

#investing
О замыканиях в JavaScript.

В JavaScript, на самом деле, не "настоящие" замыкания. Я бы даже сказал, что в JS нет замыканий, а есть некая отдалённо напоминающая их эмуляция.

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

Посмотрим пример на Elixir-е — "настоящем" функциональном языке:

x = 2
plus_2 = fn(n) -> n + x end

plus_2.(10) # => 12

x = 3

plus_2.(10) # => 12

Итак, мы внутри функции plus_2 используем переменную x, которая определена до этой функции.

Прикол в том, что в момент определения функции значение этой переменной "фиксируется": внутри функции теперь это уже не какой-то там x, а конкретно оказавшаяся там двойка. На место свободной переменной x, фактически, подставляется конкретное содержащееся там в момент определения значение.

Поэтому в последней строке plus_2 всё также продолжает прибавлять двойку к своему единственному аргументу n, а не новое значение x. Исходное значение x "замкнулось" внутри функции.

В императивных языках, которые эмулируют эту функциональность (простите за тавтологию) функциональных языков, всё не так:

// js
let x = 2
plus_2 = n => n + x

plus_2(10) // 12

x = 3
plus_2(10) // 13

# ruby
x = 2
plus_2 = ->(n) { n + x }

plus_2.(10) # 12

x = 3
plus_2.(10) # 13

Как видим, в JS (и Ruby) функция не "запомнила" (не подставила) значение переменной внутри её тела. Вместо этого, она каждый раз заново обращается к этой переменной, используя текущее значение.

Конечно, одно из типовых использований замыканий — в "фабрике функций" (функциях, которые возвращают другие функции). И когда вы пишете код "внешней" функции (= самой фабрики), ничто не мешает тщательно контролировать самого себя на предмет того, какие переменные "утекают" во "внутреннюю" функцию (= результат работы фабрики, который будет возвращён коду, вызвавшему фабрику). И убедиться, что эти переменные никто не будет изменять вне внутренней функции, или их изменение учтено by design — например, с "неправильными" JS-замыканиями можно тривиально реализовать функцию, которая считает, сколько раз она была вызвана — а с "правильными" замыканиями это, фактически, невозможно:

// js

timesRunFactory = () => {
let count = 0;

return () => {
count++;
return count
}
}

timesRun = timesRunFactory();

timesRun(); // 1
timesRun(); // 2
...

#programming #fp
Прошла онлайн Ruby-конференция: https://noruko.org/ (доступ разрешили без регистрации).

В докладе Матца (создателя Ruby) были все обычные заявления: добавим type annotations, нужно больше сторонних инструментов (линтеров, тайп чекеров), интерпретатор будет быстрее, улучшим JIT, думаем над созданием некоего супербыстрого "микроруби" (интерпретатора, реализующего подмножество Ruby).

Мне лично интересно было глянуть на три нововведения в синтаксисе языка (собственно, той части, которая на виду у пользователя):

1. Pattern matching

case JSON.parse(json, symbolize_names: true)
in {name: "Alice", children: [*, {name: "Bob", age: age}, *]}
p age
in _
p "no Alice"
end

- В целом, мне нравится, как реализован этот оператор case... in
- Не понятно, почему в качестве плейсхолдера "что угодно" используется *, а не _
- Удручает, что нет планов распространения паттерн матчинга на сигнатуры метода в стиле Elixir или JS (декомпозиция аргументов метода прямо в его сигнатуре + возможность определить/"перегрузить" одноимённые методы с разной сигнатурой)

2. Оператор "правого присвоения" (right assignment).

# было
top_five =
(1..100)
.map{|x| rand(x)}
.sort
.reverse
.take(5)

# стало
(1..100)
.map{|x| rand(x)}
.sort
.reverse
.take(5) => top_five

- Мне нравится, как Матц не ставит пробелы перед и после фигурных скобок блока - такое написание удобней и практичней традиционного по "западному" кодстайлу
- Пример не убедительный - следовательно, убедительного примера, где бы правое присвоение могло быть удобным придумать сходу Матцу не удалось

3. Порядковые аргументы блока

# умножить каждый элемент на 2
[1, 2, 3].map{_1 * 2}

- Идея мне нравится - такая возможность была бы весьма востребована
- Выбор имён _1, _2, ... выглядит как-то несовременно

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

#programming #ruby
Дисклеймер: всё нижесказанное не является инвестиционной рекомендацией - более того, автор не является ни профессиональным инвестором, ни даже успешным инвестором-любителем - это просто фантазии на некую интересную тему.

1. Китай был нетто-экспортёром еды в 2003 (+6 млрд. долл.). По данным на 2017 год - нето-импортёр (-45 млрд. долл.). Из 105 млрд. долл. импорта почти 20 млрд. приходится на США (второе место; на первом Бразилия с чуть больше чем 20 млрд. долл.).

2. Взрывной рост, среди прочего, пришёлся на импорт сои (соевых бобов — в основном как корм для скота). И здесь среди источников китайского импорта США на втором месте после Бразилии (правда, уже с существенным отрывом).

3. США является нетто-экспортёром еды. Экспорт в Китай — на первом месте.

4. Крупнейшими производителями сои в США являются: ADM (Archer Daniels Midland), Cargill, Bunge, Ag Processing.

5. Дальше смотрите сами.

Источники:

[1] CSIS ➤ How is China feeding its population of 1.4 billion? ➤ https://chinapower.csis.org/china-food-security/

[2] Mother Jones ➤ Don’t Look, But a Couple of Mega-Companies Are About to Take Over Your Food Supply ➤ https://www.motherjones.com/food/2018/01/archer-daniels-midland-merger-bunge-soybeans-monsanto-farmers-grain/

[3] Mary Hendrickson, Ph.D. ➤ The Dynamic State of Agriculture and Food: Possibilities for Rural Development? ➤ https://www.fca.gov/template-fca/download/Symposium14/hendrickson19feb2014.pdf

[4] China: Top Market for U.S. Ag Exports ➤ Minnesota Department of Agruculture ➤ https://www.mda.state.mn.us/sites/default/files/inline-files/profilechina.pdf

#investing
"Функциональное программирование" (ФП) - модный термин.

Автор имеет опыт разработки веб-приложений на Elixir-е (с использованием фреймворка Phoenix). Можно ли Elixir считать функциональным языком? Большинство отвечают, мол, конечно, это один из референтных представителей группы. Тот же JavaScript или Ruby могут назвать "языком с *элементами* ФП", но никому не придёт в голову назвать "полноценным" "функциональным языком".

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

В самом деле, ООП (объектно-ориентированный подход/программирование) зиждется на следующей формуле: "состояние" + "поведение". У нас есть некие автономные чёрные ящики (объекты), у которых в каждый момент времени есть некое внутреннее (не видимое снаружи) состояние и есть возможность получать сообщения.

Сейчас обычно говорят не "получать сообщения", а "вызывать метод". Впрочем, обратите внимание, что в Ruby проверка на то, существует ли у объекта метод, делается с помощью метода `respond_to?`— "отвечает ли?". Наследие Smalltalk, где объекты таки посылали друг другу именно "сообщения". В каком-нибудь Objective C (базовом языке для разработки под iOS) до сих пор официально "посылают сообщения".

Но, простите, а что наши разработанные на Elixir "процессы" делают, когда работают в экосистеме Erlang-а? Посылают друг другу сообщения. И так, Elixir-овский "процесс":
— имеет внутреннее состояние (минимальное разнообразие типовых способов работы с состоянием заложено в стандартную библиотеку, называющуюся OTP);
— отвечают на "сообщения".

QED, господа — Elixir это объектно-ориентированный язык (где роль "классов" играют "модули", роль "объектов" — "процессы", роль "методов" — сообщения и функции).

Отличие Elixir в том, что, когда вы пишете код, язык вас вынуждает явно себе представлять, как ваши объекты "раскладываются" по процессам (параллельным потокам выполнения) — какой объект живёт в каком "домике"-процессе на каком "островке"-сетевом узле. Традиционный объектно-ориентированный язык позволяет инкапсулировать даже сетевой вызов к REST-ресурсу, избаловывая программиста этими непрозрачными стенками абстракций.

#programming #fp #ruby #javascript #elixir
Элементы ФП в императивных языках

Мода на "функциональное программирование" задаётся, несомненно, как раз привнесением в более распространённые императивные языки пресловутых "элементов ФП".

Среди всех таких элементов можно (условно — реальная "генеалогия" чуть сложнее) выделить два класса:

1) Элемент LISP: лямбда-функции. В Ruby "лямбды" изначально были заложены в язык в виде "блоков кода" (конечно, в оригинальном LISP это сделано несколько более органично). Вслед за взрывным ростом популярности Ruby и большим признанием удобства использования "лямбд" со стороны прикладных программистов, стали потихоньку добавлять их и в другие языки: кажется, первым среди невымирающих динозавров была Java 8. Ну а теперь даже в C++ вы можете встретить нечто похожее.

2) Элемент LISP: итераторы. Аналогично с итераторами: map, select, reduce, zip, и т. д. и т. п. можно найти в любом уважающем себя современном языке. Популяризирует их в наше время JavaScript, в очередной ревизии которого они наконец появились, чтобы язык не выглядел совсем уж позорно на фоне любительской поделки фанатиков Rails — CoffeScript-а (как раз после появления "лямбд" и итераторов в JS "коффискрипт" и умер).

3) Элемент Haskell: "монады". Мало кто, в сущности, знает хоть что-то о системе категорий, но антураж "матана" привлекает неуверенных в себе программистов. Точно также, как психолог в связи с массовостью профессии и отсутствием профессиональных стандартов считается неполноценным психиатром, и программист на заре развития программирования мог бы считаться неполноценным математиком. В какой-то мере сохраняется подобное смутное чувство и сегодня. Из всего Haskell-а (этакого "языка программирования от математиков") выдёргивают обычно так называемые "монады". Элементарная, в сущности, концепция, которая на языке ООП описывалась бы простым интерфейсом контейнера с 3-8 методами, превращается в жупел, которым неполноценные математики, так и не сумевшие стать программистами, формируют неуверенность в своём интеллекте у программистов, которые не желают становиться математиками.

4) Элемент Haskell: pattern matching. Опять же, JavaScript популяризирует концепцию в наше время, переназвав её как "destructuring". На мой взгляд, впрочем, в таком терминологическом изменении нет ничего страшного: надо быть ближе к народу. Destructuring позволяет, например, прямо в сигнатуре функции (в перечислении аргументов) "выдернуть" ключ хеша или элемент массива из входящего параметра (таким образом "сопоставив", match, входящую структуру некоему "образцу", pattern). Ruby идёт с отставанием: на коленке сделанный case... in в свежей версии это хорошо, но мало: даёшь "перегрузку" функций в зависимости от структуры аргумента, как в том же Elixir.

А кроме этих четырёх пунктов, что-то больше ничего и не приходит на ум.

А вам каких "элементов ФП" не хватает в любимых языках?

#programming #fp #ruby #javascript #elixir
Очередное важное международное событие, о котором стоит поговорить нам, программистам (и сочувствующим). Программист — гражданин своей страны и дееспособный член общества, профессионал, человек с достаточно высоким уровнем интеллекта и самосознания. Программист не должен оставаться в стороне от важных событий, и должен в меру сил и средств поддерживать свою школу, свой цех и профессиональное гражданское общество в целом.

Конечно, вы уже верно поняли, что я намекаю на тему выборов. Выборов модераторов RU сектора StackOverflow. RU сектор всепланетного сайта "вопросов и ответов" на темы, касающиеся разработки программного обеспечения (и сопутствующие) представляет из себя в данный момент жалкое зрелище. Низкое количество активных пользователей, культура сниженного общения, не развитое самоуправление: русскоязычный программист (я подчёркнуто говорю русскоязычный, обращаясь к дружному космополитическому международному сообществу трудящихся) находится в настоящий момент в трудном положении.

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

О выборах модераторов RU сектора SO (https://ru.stackoverflow.com/election/4) я сам узнал случайно. Классово враждебные силы не просто замалчивали это событие всесоюзного (а может быть и международного, учитывая, что речь идёт об одном из шести языков ООН) масштаба, не уведомив правоспособных пользователей по электронной почте. Но специально генерировали повестку дня в ведущих СМИ в течение всего последнего времени, вытесняя информацию о данном мероприятии за третьи полосы газет, отвлекая и рассеивая внимание трудящихся.

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

Мы должны сами стать кузнецами своего счастья.

Следующие выборы через год. Все неравнодушные представители свободолюбивого сообщества профессионалов призываются — а, учитывая их занятый график, буквально упрашиваются — зарегистрироваться на RU-домене Stackoverflow: https://ru.stackoverflow.com/ — и, качественно сформулировав вопросы или ответы для участников сообщества, набрать 150 баллов рейтинга (минимальный порог для того, чтобы иметь возможность отдать свой голос за кандидата). Через год прогресс должен восторжествовать.

Нашим первым действием будет требование прекратить затуманивать разум электорату и просьба кандидатам предоставить чёткую базовую информацию о себе:

1. ФИО и год рождения.
2. Краткая биография, тезисно: пол, возраст, образование, специальность, текущее место работы.
3. Краткое описание профессиональных навыков и текущей работы (в уместных для публичного пространства рамках).
4. Рабочий распорядок дня - сколько часов в неделю планирует посвещать общественной деятельности.
5. Краткое описание собственной мотивации - какую выгоду надеется получить от позиции?
6. Свободное поле.

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

Вместе победим!

#programming
В продолжение темы "виды онлайн курсов" (https://www.youtube.com/watch?v=mDKl1EaxVqI).

Некая широко известная в специализированных кругах образовательная онлайн-организация предлагает:

— Курс «Профессия Data Scientist» с трудоустройством

Впрочем, с точки зрения автора данной заметки, слова "профессия" и "трудоустройство" стоило бы выделить отдельными кавычками. Заявлено, что освоить "профессию" можно, занимаясь по 4 часа в неделю(!) в течение около полугода.

Профессия, бесспорно, интересная, и описание курса сопровождается вот такими слоганами:

"88% студентов <широко_известная_организация> находят работу до защиты диплома"

Автора, как практика и исследователя онлайн-образования, конечно, заинтересовали подобные данные об эффективности онлайн-курсов. Учитывая, что Coursera даёт выхлоп в 4% получивших сертификат по отношению к записавшимся на курс, а качественные "крафтовые" онлайн-курсы дают результативность в примерно 30% освоивших программу от числа записавшихся — данные революционные. Требуется публиковать статьи на международных семинарах, оформлять патенты, и обобщать методики на все отечественные платформы.

К сожалению, в переписке со службой поддержки выяснилось, как в известном анекдоте ("и не в покер, а в дурака; и не выиграл, а проиграл"):
— 88% из тех, кто "обратился за помощью в трудоустройстве", "получил работу"
— помощь в трудоустройстве "обговаривается" (т. е. не предоставляется безусловно всем студентам из тех, кто успешно освоили программу)
— "консультант помогает составить резюме и организовать собеседование с работодателем" (т. е. не делает ничего более)

Кто любит рекламу и лапшу на уши — выбирает <широко_известную_организацию>. Кто любит честный труд и работу — выбирает <замечательных_разработчиков>!

#education
Вышла свежая новость с повторением известных цитат:

— Согласно среднему варианту прогноза Росстата, в период 2019–2030 гг. общая численность населения трудоспособного возраста снизится на 2,1 млн человек (при низком варианте прогноза — на 4,3 млн). В российских реалиях использование иностранных работников позволяет снизить издержки на фонд оплаты труда, так как их зарплатные требования на 30-40% ниже, чем у россиян. Возможность экономить на заработной плате является одним из основных факторов, который приводит к появлению на российском рынке труда миллионов иностранцев.

— На запущенном летом 2018 году в Московской области крупнейшем в Европе заводе по производству сырокопченых колбас компании «Черкизово» вся производственная цепочка полностью автоматизирована. На это предприятие будет приходиться 30% всех сырокопчёных колбас, произведенных в России. Общий объем инвестиций в производство составил 7 млрд рублей, при этом на заводе будут трудиться всего 170 сотрудников: IT-специалисты и инженеры. Можно предположить, что если все сырокопчёные колбасы в России будут производить по данной технологии, то в их изготовлении будут участвовать не более 570 человек.

— В Ставропольском крае готовится к вводу в эксплуатацию первый в России завод по производству лактозы, который должен на первом этапе выпускать 1,8 тыс т готовой продукции в год, что соответствует 10% импорта. Трудиться на этом предприятии будут только 5 человек. То есть для производства всей лактозы для нужд России будет необходимо не более 50 человек.

— «Сбербанк России» посредством внедрения систем искусственного интеллекта сократил 70% менеджеров среднего звена в 2018 году.

https://myfri.org/2020/09/04/ekonomist-aleksandr-grebenyuk-o-rabote-budushhego/

— Российская компания-разработчик беспилотного транспорта и сельскохозяйственной техники Cognitive Pilot заключила контракт на автоматизацию 242 комбайнов компании «Русагро». Система управления способна полностью автономно передвигаться по полю, отслеживая объекты на нем, в том числе различные структуры, такие как кромка, рядок и валок.

https://proteh.org/news/27052020-rusagro-vyvedet-na-rossijskie-polya-bolee-200-bespilotnyh-kombajnov/

(Всего у компании Русагро, как пишут в открытых источниках, около 800 комбайнов — т. е. автоматизировали в первый/пробный заход сразу четверть.)

К вопросу "вымирающих деревень" (хотя не в меньшей мере актуален вопрос "вымирающих офисов").

#economics
Часто считается, что (любой) программист должен знать, для начала:
— обязательно язык Си (почему именно Си, обычно уточняют неубедительно)
— матан на уровне второго курса технического ВУЗа
— алгоритмы и структуры данных на уровне книги Кернигана и Ритчи

Это вроде как даёт "прочную базу". До идеи "прочной базы" потенциальный бросивший учиться программированию заинтересованный студент доходит не своим умом, ему это наглядно объясняют либо старшие коллеги, либо вопросы к собеседованиям FAANG (устоявшаяся аббревиатура по названию крупнейших IT-компаний: Facebook, Apple, Amazon, Netflix, Google).

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

В целом, конечно, и жалко человека, застрявшего в вечных "поисках базы"; с другой стороны: падающего подтолкни. Поэтому добавим к списку выше следующее:
— знание системы команд x86 и языка ассемблера
— знание основ дизайна схем на языках высокого уровня (Verilog и т. п.) и основных архитектур процессоров
— знание основ API целевых операционных систем (Windows, Linux, ...)
— знание принципов разработки языков программирования (парсеры, лексеры, грамматики, и т. д.)
— знание многоуровневой модели сетевых протоколов и основных протоколов стека TCP/IP

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

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

#programming #education
Продолжая идею "прочной базы". Если выделять наиболее полезный мыслительный (и одновременно предметный/инженерный) навык, программист — это специалист, который правильно выделяет границы (уровни) абстрагирования.

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

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

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

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

Конечно, заглянуть на "следующий уровень" может быть полезно. К такому походу надо ответственно готовиться, правильно оценивать свои силы, и адекватно
приоритизировать. Когда некто признаётся, что не разобрался в понятии "переменная" и операции присвоения, но полез учить основы дифференциального счисления (как бы всё ещё "учась программировать"), это, надо признать, случай столь же безнадёжный, сколько случай человека, который решил выучить 100 (1000, 10000) слов иностранного языка для того, чтобы комфортно объясняться с официантами и таксистами в целевой стране и читать местные газеты, и, по ходу этой задачи, к примеру, застрявшего на чтении Шекспира без словаря и изучении дихотомии переменчивой орфографии английского в её связи с латинским и греческими прообразами.

Со стороны понятно, что это не обучение, а облагороженное безделье.

Впрочем, конечно, можно начать изучать английский с изучения латыни и греческого, этимологи и порождающих грамматик, перейдя к историческим основам, к Шекспиру, и дойдя до относительно современной классики, до Шоу, почему бы и нет? Можно начать изучать программирование от теории суперструн, устройства полупроводников приборов, или даже с языка Си. Можно, если вы бессмертный сверхчеловек с неограниченным временем и неиссякаемым источником доходов.

#education #programming
Почему невозможен профсоюз программистов?

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

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

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

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

Позиция вполне понятная для Стива Джобса или Стива Балмера (и их платных лоббистов), но для джаваскрипт-девелопера из Пензы или QA-специалиста с кредитным айфоном из Сан-Франциско — нонсенс.

В самом деле:

1) С точки зрения потребителя — демонополизация всегда положительный фактор качества продукта. В истории не было прецедентов, когда от исчезновения некоей монополии и в самом деле бы пострадало качество продукта, как этим пугают пиар-менеджеры самих монополистов.
2) С точки зрения гражданина — демонополизация всегда положительный фактор для защиты персональных данных и реализации свободы выбора в широком смысле.
3) С точки зрения сотрудника компании — демонополизация, как правило, положительный фактор из-за роста давления на компанию. Больше вызовов (challenges), больше зарплата тем, кто их решает.
4) С точки зрения миноритарного акционера компании — демонополизация умеренно негативный фактор. Впрочем, в долгосрочной перспективе может сыграть позитивную роль за счёт роста "антихрупкости" (адаптивности) компании.
5) С точки зрения мажоритарного акционера — демонополизация выраженно негативный фактор.

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

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

#economics #psychology #programming
Психологическая типизация — важный и популярный вопрос психологии

Существенный прогресс сделал в нём Карл Юнг, написав в результате работу "Психологические типы". Психологические типы — это, в целом, в массе самый увлекательный вопрос психологии. Каждому хочется знать, к какому типу (всё равно в какой системе) он относится.

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

Но здесь хотел отметить, что человек, который верит в систему психологических типов (любую — например, в систему знаков зодиака) выраженно эффективней в коммуникации, чем человек, не имеющий никакого механизма "диагностировать" окружающих — поскольку у первого, в отличие от второго, есть твёрдый базис для убеждённости в том, что он может так или иначе воздействовать на товарищей. А наличие данной убеждённости уже, по сути, 50% процентов дела (хоть и не 100%).

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

Плохая система типов (если каждый тип хоть немного позитивен и жизнеутверждающ, конечно) лучше никакой; а хорошая лучше, чем плохая.

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

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

#psychology
Парные темы

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

На самом деле, цель СМИ — создать тематическую оппозицию, где одна тема прикрывает другую (и обе ложные).

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

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

Конечно, верно и обратное: аккуратные соображения о том, что действующий эффект не может объясняться степенью разведения до полного отсутствия в растворе одной молекулы действующего вещества, будут натыкаться на ответ "а-а, так ты аллопат" :) Ну или что-то вроде того (к сожалению, не участвовал в полемике с гомеопатами, в отличие от докмедовцев).

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

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

Закон парных тем — один из таких.

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

Как в том анекдоте: "А что будет, если все будут такими умными, как вы?" - "Согласно статистике, все не будут".

#psychology
Про "софт-скиллы"

В целом следует отличать три типа софт-скиллов:

1. Личное умение (и набор навыков) для достижения социальных ("быть обеспеченным"), коммуникативных ("добиться повышения зарплаты от начальника") и предметных ("быстро придумывать правильную архитектуру кода") навыков.
2. Некое принятое полунегласное соглашение о том, как люди на производстве должны общаться друг с другом, нацеленное на воспитание интровертов ("здороваться с коллегами, не ругаться матом, поддерживать разговор о погоде").
3. Общее объяснение/рационализация о том, почему в целом некоторым людям со временем работать надо больше, а денег платят меньше ("у вас просто правильных софт-скиллов нет").

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

Что касается базовых "софт скиллов" для индивидуума, т. е. набора коммуникативно-ментальных навыков, я бы вот какой шорт-лист составил:

1. Раппорт. Простой, традиционно тренируемый, прямолинейный навык установки многоуровневого раппорта даёт +1 балл на экзамене, +10% зарплаты на собеседовании, и в целом прохождение "по верхней границе" всех организационных "вилок" на всех уровнях частных корпоративных/организационных раскладов/интриг и в карьере в целом.

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

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

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

В этом большой рекламный парадокс: реклама должна давить на простые эмоции, но реклама правильных "софт скиллов" не может этого делать, т. к. вообще про другое.

#psychology #programming
Caenorhabditis elegans
К вопросу переселения в нейросети.

Вот, друзья, бытует убеждение, что скоро нейросети дойдут до такого уровня, что человекоподобный искусственный интеллект станет реальностью. А там и можно поставить вопрос переселения разума в облака и здравствуй цифровое бессмертие. Заживём!

Извините, разочарую — не заживём. И дети, и внуки, и правнуки не заживут.

Знакомьтесь – на картинке выше C. elegans, «палкоподобный элегантный», червячок длинной 1мм. Нервную систему червяка формируют 302 нейрона (примечательно, что схема нейросети у него статичная — прошита в геном, в отличие от более развитых-сложных организмов). Создана полная трёхмерная карта связей между этими нейронами (так называемый коннектом). Геном полностью расшифрован.

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

Червячок умеет:

1. Ориентироваться в пространстве по гравитационному и магнитному полю.
2. Выслеживать еду (бактерий), применяя механически замысловатые манёвры (за что его и прозвали элегантным).
3. Оценивать температуру среды и передвигаться в сторону оптимальной температуры.
4. Жрать хорошую еду.
5. Не жрать плохую еду.
6. Учиться на своём опыте, запоминая, какая еда хорошая, а какая плохая.
7. Выбирать партнёров для спаривания и размножаться.

На всё про всё 302 нейрона. Попробуйте создайте компьютерную нейросеть, которая воспроизводит аналогичное поведение, на 302 перцептронах.

Живой нейрон C. elegans может напрямую реагировать на окружающую температуру и хранить сам в себе воспоминания (за всю память и восприятие запаха отвечают три нейрона). Более чем сотня нейропептидов (гормонов, нейромедиаторов и иных белков, модулирующих работу нервной системы) вторично влияет на функционирование нервной системы. Нейропептидные связи формируют внутри коннектома что-то вроде подпольной «вторичной» сети обмена информацией.

Учёные не могут сейчас и не смогут в ближайшие 50 (оптимистично – реально, и 100) лет – как показывает опыт применения «атомарного подхода» – переселить в облако жалкую «душонку» этого червячка.

Каждый раз, когда вам на страницах Nature будут хвалиться успехами в моделировании человеческого мозга, спросите мысленно: а чё там с C. elegans-то?

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

#science
К вопросу принципов ОО (объектно-ориентированного) дизайна.

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

Принципы ОО-дизайна строят, в свою очередь, так. Давайте согласимся с тем, что "класс должен отвечать за нечто одно". И напишем один том про классы, другой про ответственность, третий для прояснения вопроса что является чем-то одним, а что следует считать двумя разными вещами.

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

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

Однако, без каких-то общих принципов тоже сложно обходиться, всякому рациональному человеку хочется поверх практики построить теорию.

Для дизайна простых классов вот к чему стремится всякий разумный программист:

1. Минимизировать "состояние". На практике, это означает использование минимально возможного количества instance-переменных, задающих "базис" объекта. Если у человека в instance-переменных хранится имя и фамилия, то не должно быть instance-переменной, где хранилось бы имя с фамилией одной строкой.

2. Не смешивать "классы-вещи" и "классы-процессы". Если объект "человек" должен, кроме хранения данных об означенном человеке, ещё после своей инициализации сходить на сторонний сервис и отправить пару email-ов, то данный принцип оказался нарушен. Процесс "Регистрация человека" должен быть выделен отдельным классом.

3. Не нарезать код на части без необходимости. Если у некоего метода 200 строк это не повод нарезать его на 20 методов по 10 строк. Поводом станет (реальная или реалистично прогнозируемая) необходимость повторно использовать логику фрагмента этого метода в другом методе.

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

5. Избегать циклических зависимостей (на уровне методов, классов, архитектурных частей проекта).

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

7. Снижать "цикломатическую сложность". Например, не вкладывать условие в условие, если можно добавить ветку в корневое условие (аналогично, не вкладывать условие в rescue-блок, проверяя вид исключения, если можно добавить отдельную rescue-ветку; и т. п.).

Вот такие вот семь заповедей разумного программиста :)

#programming
Три стадии развития продуктивности и преодоления прокрастинации:

1. Делаешь вид, что всё время с момента предыдущего обращения чем-то занимался, героически преодолевая возникшие серьёзные затруднения, чтобы не смущать коллег своим существенным отставанием от общего темпа работы.

2. Нормально работаешь наравне со всеми.

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

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

Но в центре открытия всегда один конкретный человек. По-другому не бывает.

В программировании мы знаем фон Неймана, Тьюринга, Дейкстру, Вирта, и т. д. и т. п. Их деятельность как раз, можно так сказать, выставляется напоказ, и они получают свою долю славы. Столпы.

Но скольких мы не знаем? Вот, например, Андерс Хейлсберг. Легендарная личность. Разработал Turbo Pascal (1983), который стал одним из опорных продуктов компании Borland. Затем, во главе собственной команды под крылом того же Borland, разработал Delphi (1986-1996).

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

И Хейлсберг переходит в Microsoft (1996), где разрабатывает язык C# (2000), перенося, кроме прочего, в некоем трансформированном виде все наработки "быстрого прототипирования и разработки оконных приложений", которые были им заложены в Delphi.

Borland и Delphi по инерции плюхаются ещё чуть ли не 10 лет, но воду из бассейна уже слили. Видимость жизни можно поддерживать даже в трупе, "были бы бабки", но всё же это не жизнь.

Ну а C# сейчас используется в каждом утюге, от веб-приложений до мобильных игр.

Хейлсберг сейчас (с 2012) занимается разработкой TypeScript под крылом Microsoft.

Google, напротив, по-видимому, исповедует корпоративную политику "никогда не давать инженерам власти". Для разработки Dart привлекают ДВУХ программистов – Dart разрабатывает "коллектив полуанонимных разработчиков" вместо конкретного (в определённой мере) выдающегося главного конструктора.

Итог закономерен: TypeScript это новый мейнстрим и конвенциональный инструмент во фронтенде (во фронтенде! где на каждый чих десять уникальных трендовых альтернатив), а Dart это очередная поделка для кладбища неудавшихся проектов.

Любой реальный инженерный и научный продукт всегда может быть атрибутирован конкретной личности, которая сыграла центральную роль в его разработке. "Коллектив авторов" – это bullshit, который указывает на то, что под видом научного или инженерного продукта пытаются впарить продукт политический или теологический. Для Библии "коллектив авторов" – почему бы и нет? Для физического принципа, компьютерной технологии, психологической практики — нет, ребята, так не бывает.

#science #programming