Конференции Олега Бунина (Онтико) corporate blog
Python
Perfect code
Development Management
Comments 54
+12
>Например, если использовать Webpack, появляется возможность писать функцию `import()`
Вообще-то это часть спецификации языка.

>Управлять сложностью тяжело, когда язык меняется от установки Babel или плагинов к нему.
Фейспалм.

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

>в коде проекта JS смешиваются сразу несколько сущностей, которые не относятся к самому языку
И на два абзаца ниже рассказ о том, что если добавить в Python библиотеку AsyncIO, то все сильно усложняется.

>Хочешь использовать синхронную библиотеку для работы с БД — пожалуйста. А хочешь асинхронную — ее нет.
Вот если бы только был такой язык, в котором по-умолчанию все асинхронное.

«Делайте лучше сервисы».
+1
from gevent import monkey
monkey.patch_all()
— и все, весь синхронный код становиться асинхронным (почти шутка)
+1
> Вот если бы только был такой язык, в котором по-умолчанию все асинхронное.
Посмотри на Erlang, он почти смог
+2
Вот если бы только был такой язык, в котором по-умолчанию все асинхронное.


Erlang довольно близко подошел к такому. И у него свой собственный подводный сад граблей :)
0
Не будет сада — не нужно садовников)
А так, вполне вменяемо. Уже не первый год использую для разного.
0
> Вообще-то это часть спецификации языка.

Вообще часть спецификации языка это import js-модулей, а вебпак нам несет еще и import для ассетов, css и прочего, вероятнее всего это и имел ввиду автор.
+18
Влияет ли на управление сложностью то, что в программировании сейчас довольно много людей со слабой технической базой?

Конечно. Для таких людей даже специальный язык программирования придумали. Называется Go. Я не шучу. ....

Нельзя вот так вот навешивать ярлыки и обобщать!
Я лично большую часть статьи расцениваю как плевок в лицо всем разработчикам в мире в не зависимости от используемого языка программирования и уровня квалификации,
а высказывание выше — прямым оскорбление всего сообщества golang разработчиков!

Все люди не умеют писать код

Прям все?
Конечно, Никита Соболев, являясь техническим директором компании «Мы делаем сервисы» может внутри компании ненавидеть всех своих подчинённых и всех разработчиков, по должности он не обязан уметь писать код и скорее всего это именно так, но выносить это в паблик, обобщать, навешивать ярлыки и делать выводы это уже откровенное оскорбление!
А со стороны Онтико это явно провокация, не достойная уважения, фу! фу! фу! Онтико! Грязно!

Друзья, спешим напомнить, что до нашей Moscow Python Conf++ осталось меньше месяца. В этом году на ней будет более трех десятков выступлений и целая серия митапов. Финальная программа будет анонсирована на днях, а пока можно ознакомиться с общим списком докладов.

Задумайтесь, если вот такие доклады будут на «Moscow Python Conf++», стоит ли посещать такое мероприятие?
Вот такие вот люди как Никита Соболев будут там что-то «вещать» со сцены за ваши же деньги… Хм…
+2
Все люди разные. Все люди одинаковы. И то и другое правда. В некотором смысле.
Все люди не умеют писать код. В этом он прав. В некотором смысле.
У каждого программиста есть свой предел сложности, за которым начинаются проблемы. Что делать, если этот предел многократно превышен? Что делать, если этот предел превышен для фирмы в целом? Человек, который занимается этими вопросами не может закладываться на то, что программисты напишут правильно работающий код. И совершенно точно постулирует отправную точку своей работы: «Все люди не умеют писать код.»
За всю жизнь я один раз (если не считать учебных задачек и спортивного программирования) видел правильно написанный с первого раза код. Мы около часа обсуждали алгоритм решения практической задачи. Потом мой коллега сел к терминалу и набил около 200 строк на фортране. Когда это с первого раза скомпилировалось я очень удивился. Но оно еще и заработало именно так, как мы хотели. С тех пор прошло ужасно много лет, но ничего похожего я не видел.
+14
Товарищ озвучивает довольно спорные тезисы.

Где можно ознакомиться с его достижениями, которые свидетельствовали бы об авторитетности таких заявлений?
+10
Краткое исследование показало, что компания «Мы делаем сервисы», находится в стадии ликвидации — zachestnyibiznes.ru/company/ul/1177746045070_7708308765_OOO-MY-DELAEM-SERVISY

Может качество кода не связано напрямую с коммерческим успехом, но разве технический директор не отвечает за оптимальное соотношение цены/качества в контексте коммерческой целесообразности?
-2
Забавная штука, не подозревал что так можно. Вангую, что это механизмы работы с юридическими вопросами, к успешности и финансовым показателям компании в целом не имеющие никакого отношения :)
+8
Достижения легко гуглятся:
github.com/sobolevn
github.com/wemake-services
habr.com/users/sobolevn/posts
medium.com/@sobolevn
www.moscowjs.ru/speaker/nikita-sobolev
events.yandex.ru/lib/talks/4858
theoryandpractice.ru/presenters/45416-nikita-sobolev/courses
freelansim.ru/freelancers/sobolevn
elixir-lang.moscow/speakers/nikita-sobolev-wemake-services
facebook.com/expertfridays/videos/1964415190439615
it-events.com/events/7360
hype.codes/n-sobolev-i-elixir-addition-python
www.conferencecast.tv/speaker/8086/nikita-sobolev
dev.to/sobolevn
bigxp.ru/experts/46


Думаю этого достаточно чтобы по достоинству оценить «эксперта» и технического директора компании «Мы делаем сервисы» Никиту Соболева.

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

P.S.
Кто может, тот делает. Кто не может, тот учит. ©Чак Паланик
Твой учитель — это не тот, кто тебя учит, а тот, у кого учишься ты. ©Ричард Дэвис Бах
Кто умеет — делает, кто не умеет — учит, кто не умеет учить — руководит. ©Джордж Бернард Шоу.
+2
Думаю этого достаточно чтобы по достоинству оценить «эксперта» и технического директора компании «Мы делаем сервисы» Никиту Соболева.


Вот не понимаю я такой манеры общения, хочется, чтобы хабр был профессиональным и конструктивным, но будем обвинять всех в тупости?
Вы привели ссылки на публикации, и что?

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

Ни в коем случае не утверждаю, что критиковать работу другого человека можно только, если у вас индекс Хирша, список публикаций на хабре, опыт в годах, количество созданных пулреквестов больше, но если вы хотите читать профессиональные статьи, то может и критиковать их стоит профессионально?
+4
Можно поинтересоваться, что именно вы считаете спорным?

Синтаксис языка должен определяться только спецификацией, а не флагами или конфиг-файлами, это бесспорно. Всякие `php.ini` и `use strict` − это плохой дизайн.

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

Следовать стайлгайдам необходимо. И управлять сложностью кода в проектах, то есть, грубо говоря, заставлять «рок-звёзд» писать код, понятный джунам − это тоже очень важно.
0
Go был создан для того, чтобы опустить уровень вхождения в компилируемые ЯП. Роб Пайк это прямо подтверждает.

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

-2
Давайте начнем с

Нам дают не нормальный язык программирования, а его очень урезанную версию — в нем нет практически никаких сложных концептов by design. Нет дженериков, нет такого понятия, как исключения и т.д. И поклонников такого подхода много.


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

Как минимум отсутствует определение нормальности и полноты(неурезанности), потому что если под полнотой подразумевать общеупотребимую полноту по Тьюрингу, то приведенное утверждение не спорное, а прямо таки ложное.
+5
Я честно скажу: я не знаю Go, и не скажу, «нормальный» он на мой вкус или нет. Но когда я слышу: «дженерики не нужны», «лямбды запутывают», «зачем свойства, если есть геттеры и сеттеры», «множественное наследование − бред», «что плохого в бойлерплейтах, есть ведь кодогенерация в IDE» и всё такое, то я сразу вспоминаю дедушку Симпсона из серии про лимонное дерево. Помните?
“Lemons being the sweetest fruit available at the time.”
0
Это хорошая метафора, но метафоры не имеют доказательной силы и воздействуют скорее на эмоции, нежели на разум. Чтобы говорить о разумной дискуссии надо определить понятия и строить логические цепочки.

Ведь, согласитесь, не бывает просто «нужны» или «не нужны» в вакууме. Бывает «нужно для чего то».
0
Я не понимаю, как вы хотите, чтобы вам доказали необходимость дженериков или, скажем, каррирования? Метаматематически? Или с точки зрения психофизиологии?

Всё нужно. Нужно расти над собой, узнавать новые вещи. Человеку нужно, а не программе.
0
Согласен, нужно расти над собой.

Именно поэтому я интересуюсь, имеют ли приведенные тезисы под собой объективное основание, либо это мнения, о которых спорить глупо.

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

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

Без определения понятия дискуссия не может быть цивилизованной.
0
Обычно имеют в виду выразительные средства.

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

Соответственно, если Brainfuck нужен, чтобы факать мозги, то он прекрасен в этой области.

Если же разговор об абстрактной полноте/урезанности, то нужно не мое мнение, а критерии полноты/урезанности.

Разве не так?
0
чрезвычайно желательно, чтобы выразительные свойства языка были не шире и не уже, чем нужно для решения поставленных перед языком задач.


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


Я всегда был уверен, что сначала формулируется задача, а потом создается/дорабатывается язык для решения этой задачи. Разве нет?
0

Увы. Долгий эволюционный процесс, длящийся годами и десятилетиями. Постоянно реагирующий на изменения обстановки. Часто — с неожиланными поворотами сюжета (никто не ожидал, что type annotations вылются в gradual typing)

0
Я бы предпочёл, чтобы язык был достаточно мощным, чтобы я мог сам себе создавать выразительные средства и ограничения под задачу вместо изучения нового языка под задачу. Ну там, чистота функций, монадический синтаксис, вот это всё. Но это, опять же, если разговор идёт о субъективном мнении.

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

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

Можете, пожалуйста, пояснить про проблемы?
И привести пример полной по Тьюрингу системы типов (не очень себе представляю, что это по отношению к типам).
0
Forth это умеет.

Forth умеет немного не то. Вы, вероятно, про околосинтаксические конструкции, а я про систему типов.

Можете, пожалуйста, пояснить про проблемы?

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

И привести пример полной по Тьюрингу системы типов (не очень себе представляю, что это по отношению к типам).

Возьмите любой язык с зависимыми типами (вроде агды или идриса) и выкиньте требование тотальности функций в type-level language.

Ну или вполне конкретный пример вот. Вот прям там, где «Here, for example, is a program that would make the typechecker loop».
0

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


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

+1
Обычно эта фраза значит, что существует класс задач, который в этом языке делается через жопу. Вам нужно развернуть определение «делается через жопу»?


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

Мы этого не видим.
0
Очень странное рассуждение: отсутствием идеала вы показываете что?
Давайте так: я утверждаю, что brainfuck еще более кастрированный.
Не кажется ли вам странным, что ваше рассуждение не позволяет мне утверждать про кастрированность {uglyLang}, только потому, что другие языки имеют свои слабые стороны?
Или brainfuck — норм язык?
+1
А почему никто до сих пор не написал аналог V8 для Python? C API виновато?
+4
Действительно, целью создания языка Go была попытка вовлечения в написание кода студентов и стажеров Google, которые не могут освоить C++.

А я думал основная фишка Го, это процессы, реализованные средствами рантайма, которые по сравнению с обычными процессами ОС занимают намного меньше ресурсов, и их можно запускать миллионами на одной машине, выжимая тем самым из нее максимум производительности.
А оказывается дело в синтаксисе.
Век живи, век учись…
-4
Увы, дело действительно в синтаксисе. Green threads много у кого есть. У того же Ruby.
+1
green threads в руби нет со времен версии 1.9, т.е уже почти 12 лет.
+5
Вы путате причины появления языка и фишки языка. Корутины были придуманы очень-очень задолго до создания go, и прекрасно реализцются на assm, С и С++ и производительности выжимают больше. Но сделать это ненаделав кучу ошибок гораздо тяжелее. Целью создания go, изначально, была имено простота использования, о чём Роб Пайк и рассказывал: web.stanford.edu/class/ee380/Abstracts/100428-pike-stanford.pdf
+3
Си создали потому, что ленивые и глупые студенты не могут освоить ассемблер в силу слабой технической базы?
-2
Ну нет, совсем другая история. «C» был разработан в процессе переписывания Unix под новую архитектуру. С целью сделать переписывание комфортным для разработчиков. Он решает ровно те задачи, которые у них были на момент работы. К студентам не имеет никакого отношения.
+6
Товарищ, вы просто не знакомы с тем, что жив еще Вирт, что есть «параллельный» мир modula, pascal, oberon. И сказали какую-то глупость о go.
Он не для того, чтобы вчерашних студентов в сеньоры пихать. И, видимо, не знаком с тем, что может сделать сложность с большим проектом.
Может даже узнаете о том, что «примитивный» pascal сделал для java…
Может откроете, что почему-то иногда простота языка важна и за эту простоту начали биться во времена, когда не была массовой профессия программиста и не стояло задачи нанимать «студентов».
Может, однажды вы, эксперт, тоже чему-то научитесь.
+1
прекрасно реализцются на assm, С ..
насколько я понимаю, это надо либо расставлять операторы типа «yield» (и/или работать с прерываниями и/или стеком) вручную, либо написать написать и вставить в свое приложение вытесняющую многозадачность, чтобы пропущеный yield не подвешивал все потоки, бегущие в процессе. Плюс, Го распределяет бегущие корутины на имеющиеся процессы ОС, чего не делают многие из перечисленных альтернатив.
Поэтому, да, целью Го была простотая работа вот с этим вот всем, но уж никак не ради стажеров, которые не могут освоить синтаксис.
+5
Самый страшный пример, который я видел, продемонстрировал мне, что внутри цикла на сотню итераций можно определить функцию. Если честно, когда я на это смотрел, у меня внутри интерпретатор сломался. Я догадывался, но не знал, что так можно.

Ну что тут можно сказать…
0
Я думаю, что это все-таки сложившиеся разработчики, потому что начинающие программисты еще не сформировали своего четкого мнения. Хотя и им будет интересно послушать и высказаться. Они точно являются нашими пользователями.

Странно, нет четкого мнения у начинающих программистов, но они уже


наши пользователи

Вряд ли

Only those users with full accounts are able to leave comments. , please.