На нынешней работе приходится использовать Go. Я хорошо познакомился с этим языком. Мне он не нравится, и меня озадачивает его популярность.

Эргономика разработки

Никогда не встречал языка, настолько открыто противостоящего удобству для разработчика. К примеру, Роб Пайк неоднократно и открыто враждебно относился к любому обсуждению подсветки синтаксиса на Go Playground. В ответ на разумно сформулированные вопросы пользователей его публичные ответы отсвечивали пренебрежением и неуважением:

Gofmt написан специально чтобы уменьшить количество бессмысленных дискуссий о форматировании кода, что отлично удалось. К сожалению, это никак не повлияло на количество бессмысленных дискуссий о подсветке синтаксиса или, как я предпочитаю её называть, spitzensparken blinkelichtzen.

И снова в ветке 2012 Go-Nuts:

Подсветка синтаксиса — для маленьких. В детстве меня учили арифметике на цветных палочках. Сейчас я вырос и использую чёрно-белые цифры.

На Хабре в комментариях к статьям о выходе новых версий операционных систем, выпуске новых моделей ноутбуков, накопителей данных, модулей памяти и т.п. регулярно высказывается мнение о том, что только наипоследнейшая версия операционной системы известного вендора даёт возможность современному гику не скатиться в унылое г… очувствовать себя человеком, и только тот, у кого стоитустановлена Windows 8, 10, 11, 9000 (нужное подчеркнуть), будет пользоваться популярностью у девушекработодателей и клиентов. По причинам изложенным ниже я полагаю таковое мнение глубоко ошибочным и даже ущербным, показывающем неспособность владельца компьютера оптимально использовать имеющиеся в его распоряжении аппаратные и программные ресурсы.

Во время очередного спора знакомый озвучил мысль, которая меня очень сильно задела. «В большинстве популярных ЯПов существует очень много разных путей сделать одно и то же. Это приводит к проблемам. А вот в Go всё не так. Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом. Поэтому их код легко читаем, предсказуем и надежен. И поэтому крупный бизнес выбирает Go». Это достаточно мощный аргумент, над которым нужно как следует поразмыслить, прежде чем опровергать.

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

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

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

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

Пол Грэм написал не одну статью и даже книгу о преимуществах Лиспа. На момент написания этой статьи Lisp занимает 33-е место в рейтинге TOIBE (в три раза мертвее мёртвого Delphi). Возникает вопрос: почему язык так мало распространён если он так удобен? Приблизительно два года использования дали несколько намёков на причины.

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

Язык визуального программирования — это такой язык, который позволяет программисту создавать программы, манипулируя графическими элементами, а не печатая текстовые команды. Известным примером является Scratch, язык визуального программирования родом из MIT, который используется для обучения детей. Его преимущества заключаются в том, что он делает программирование более доступным для новичков и не-программистов.

В 1990-х годах было очень популярное движение по внедрению визуального программирования в корпоративную среду с помощью так называемых CASE-инструментов, где корпоративные системы можно было бы определять с помощью UML и генерировать [их код] без необходимости в привлечении обученных разработчиков программного обеспечения. Это связано с концепцией «round tripping» («туда и обратно»), где система может быть смоделирована визуально, программный код будет генерироваться из полученных моделей, а любые изменения кода могут быть возвращены обратно в модель. Увы, подобные инструменты так и не смогли выполнить свою миссию, и большинство из экспериментов [по их внедрению] в настоящее время в значительной степени заброшены.

Привычный хаос в названиях коммитов. Знакомая картина?

Наверняка вы знаете git-flow. Это отличный набор соглашений по упорядочиванию работы с ветками в Git. Он хорошо документирован и широко распространен. Обычно мы знакомы с правильным ветвлением и много говорим об этом, но, к сожалению, уделяем слишком мало внимания вопросу наименования коммитов, поэтому часто сообщения в Git пишутся бессистемно.

Меня зовут Ержан Ташбенбетов, я работаю в одной из команд Яндекс.Маркета. И сегодня я расскажу читателям Хабра, какие инструменты для создания осмысленных коммитов мы используем в команде. Приглашаю присоединиться к обсуждению этой темы.

Питон изумителен.

Удивительно, но это довольно неоднозначное заявление. Что я имею ввиду под “Питоном”? Может, абстрактный интерфейс Питона? Или CPython, распространенная реализация Питона (не путать с похожим по названию Cython)? Или я имею ввиду что-то совсем иное? Может, я косвенно ссылаюсь на Jython, или IronPython, или PyPy. Или может я отвлекся так сильно, что говорю о RPython или RubyPython (которые очень сильно отличаются).

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

При работе с Питоном я столкнулся с кучей таких технологий. Инструменты *ython. Но лишь недавно я уделил время, чтобы разобраться, что они собой представляют, как они работают и почему они (каждая по-своему) необходимы.

В этом посте я начну с нуля и пройдусь по разным реализациям Питона, а закончу подробным введением в PyPy, за которым, по моему мнению, будущее языка.

Все начинается с понимания того, чем на самом деле является “Питон”.

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


Только за последние 18 лет люди придумали множество языков, среди которых, вероятно, самыми популярными стали Swift, Kotlin и Go. При этом отличительная черта языка программирования 21 века — это отсутствие каких-либо отличительных черт. Самое приятное в работе с такими языками — за изучением одного из них можно провести выходные и под конец заявить, что вам удалось освоить популярную новинку, по факту же не узнав ничего нового. В них действительно нет ничего нового. Все современные языки созданы на основе какой-либо правильной и проверенной формулы, имя которой, вероятнее всего, Objective-C, Java или C.

«Отсутствие новизны» можно считать ценной чертой, но подобная ситуация вызывает один вопрос. Действительно ли перед нами языки нового, 21 века, или все это — просто отражение плохих привычек программирования 20 века?

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

Долой синтаксис!

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

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

Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.

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

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

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

И сейчас, когда вот-вот выйдет Kotlin 1.3, мы расспросили «самого главного» Андрея Бреслава не про корутины, а про совсем другое: от того, чем он занимался до Kotlin, до того, чем полезна психотерапия.

Здравствуй, Хабр!

Предлагаю Вам обратить внимание на проект «Сделано в России» — отечественного языка для веб-разработки. Проект разработан в Екатеринбурге, а не является локализация западного, что большая редкость, так как языков программирования разрабатываемых у нас не много.

WBASIC — Акроним Web Beginner's All-purpose Symbolic Instruction Code.
Высокоуровневый язык программирования применяемый для разработки серверных веб-приложений.

Это диалект языка BASIC, разработаный с учетом работы в сети Интернет в 2017 году, а сам синтаксис языка в 1964.



Философия языка — это должно быть просто для начинающих. И надеюсь, мне это удалось. Вся документация по языку умещается на сегодня всего в 9 разделах и освоить их можно за один-два дня.

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

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

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

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

Закон Амдала

В 1967 году Джин Амдал представил довод против параллельных вычислений. Он утверждал, что рост производительности ограничен, поскольку только часть задачи поддаётся распараллеливанию. Размер остальной «последовательной части» отличается в разных задачах, но она есть всегда. Этот довод стал известен как закон Амдала.

Если построить график «ускорения» выполнения задачи в зависимости от количества выделенных ей параллельных процессоров, вы увидите следующее:


Это асимптотический график для фрагмента, который не поддаётся распараллеливанию («последовательная часть»), поэтому существует верхний предел максимального ускорения

Правда ли, что Meltdown и Spectre слишком фундаментальны для того, чтобы выпустить для них патч? Один эксперт считает именно так.

Как определить и исправить такие ошибки, как Spectre и Meltdown? Этот вопрос был самой горячей темой среди энтузиастов микропроцессоров в этом году. На одном из главных академических событий индустрии, конференции Hot Chips, эксперты согласились, что окончательное решение проблемы может потребовать – да, ещё больше разговоров.

На встрече в Купертино профессора Марка Хилла из Висконсинского университета попросили порассуждать о последствиях атак по сторонним каналам или атак на спекулятивное выполнение команд у современных процессоров, которые изготавливают компании ARM, Intel, и другие. Он перечислил такие решения, как специализированные ядра, сброс кэша при смене контекста и бизнес-идеи вроде увеличения платы за эксклюзивные виртуальные машины.

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

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

Типичный запрос в техподдержку Voximplant: «Почему видеозвонок между двумя Chrome выглядит лучше, чем видеозвонок между MS Edge и нативным iOS-приложением»? Коллеги обычно отвечают нейтральное — «потому что кодеки». Но мы, айтишники, любопытны. Даже если я не разрабатываю новый Skype-for-web, чтение «какой браузер что может» и как они разбивают одно видео на несколько потоков разного качества обогащает картину мира и дает свежую тему для обсуждения в курилке. Удачно подвернувшаяся статья от широко известного в узких кругах Dr Alex (с лучшим объяснением термина «media engine» из всех, что я видел), немного нашего опыта, пара вечеров в «Циферблате» — и адаптированный для Хабра перевод ждет под катом!

Привет, Хабр! Меня зовут Максим Лютцау, в Промсвязьбанке я работаю product owner’ом. Почти год разработка нового интернет-банка «Мой бизнес» у нас идет по фреймворку Scrum, и в связи с этим я уже успел набить шишек. В этом посте я хотел бы рассказать о самых болезненных из них, а также о том, какие средства нам в итоге помогли. Чтобы вы смогли избежать подобных неприятностей.

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

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

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

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

Указатель ссылается на ячейку памяти, а разыменовать указатель — значит считать значение указываемой ячейки. Значением самого указателя является адрес ячейки памяти. Стандарт языка C не оговаривает форму представления адресов памяти. Это очень важное замечание, поскольку разные архитектуры могут использовать разные модели адресации. Большинство современных архитектур использует линейное адресное пространство или аналогичное ему. Однако даже этот вопрос не оговаривается строго, поскольку адреса могут быть физическими или виртуальными. В некоторых архитектурах используется и вовсе нечисловое представление. Так, Symbolics Lisp Machine оперирует кортежами вида (object, offset) в качестве адресов.