Собеседования - Что вам не нравится в X?

Синтаксис то это как раз ерунда и действительно лечится чтением документации и просто опытом работы.

А вот как быть с:

1) Только ручное управление памятью

2) Отсутствие синтаксического сахара для ООП (== при необходимости нагородить ООП требуется писать кучу boiler plate кода)

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

Однако, есть и достоинства:

1) Из-за ручного управления памятью можно добиться оптимального потребления этой самой памяти, а не жрать память как не в себя. Плюс нет подвисаний при работе GC.

2) Низкоуровневые структуры данных позволяют абсолютно точно контролировать каждый байт каждой структуры.

Фактически, эти достоинства и недостатки являются следствием одних и тех же свойств языка, но с разных точек зрения. Знание этих фактов позволяет легко определить область применимости языка:

1) Там где важна скорость написания кода - Си такое себе решение

2) Там где важна супер-производительность и предсказуемость поведения на низком уровне - Си отличное решение.

Недостатки это не всегда плохо. Это нормально.

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

Только ручное управление памятью

Есть куча реализаций GC под C. И под конкретную задачу написать свою, при желании, не сложно.

Отсутствие синтаксического сахара для ООП (== при необходимости нагородить ООП требуется писать кучу boiler plate кода)

Нормальное ООП не требует кучи boiler plate кода, даже на Си. На C++ и Java код тоже часто превращается в спагетти, это когда сахар есть - а понимания нет.

Только ручное управление памятью

А что ты ещё ожидал от С? Но тем не менее, есть сторонние библиотеки со сборщиками мусоар.

Отсутствие синтаксического сахара для ООП (== при необходимости нагородить ООП требуется писать кучу boiler plate кода)

Если тебе позарез нужен ООП с сахаром, пиши на С++

Утверждение «питон медленный» опять же не имеет смысла вне контекста. Язык в принципе не может быть медленным. Медленной может быть только его реализация. CPython медленнее PyPy в каких то задачах, да. Для каких то задач - медленной может быть и реализация на C (собственно далеко за примером не надо ходить, вон он в предыдущем предложении).

Ну правда же, не имея конкретной задачи указывая области применения можно только синтаксис и отсутствие generic'ов сравнивать :-(.

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

Вывод: универсальных инструментов нет, каждый хорош в одной области и плох в другой. Но IRL слишком много инструментов и они слишком разные, а вот в IT часто многие вещи более формализуемые.

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

1) Компилируемый-интерпретируемый. Первое - производительность в рантайме, второе - скорость разработки и гибкость языка (например, возможность лёгкой генерации кода в рантайме).

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

3) Батарейки. Если есть - скорость разработки, отсутствие необходимости изобретать велосипед, если нет - скорее всего менее жирный рантайм.

4) Качество оптимизаций компилятора/производительность интерпретатора. Тут уже актуально только в сравнении с другими вариантами. Например, JavaScript быстрее Python, а C/C++ быстрее JavaScript (разумеется, при одинаковом качестве кода).

5) Количество прикладных библиотек. Опять же в сравнении с аналогами. В некоторых случаях может быть принципиально наличие конкретной библиотеки. Например, писать графический тулкит с нуля - не самое приятное удовольствие. Так что выбирать для графического приложения язык, для которого нет соответствующей библиотеки - в 99% плохая идея.

6) Поддержка многопоточности. Варианты: нет (JS), да, но с ограничениями (Python), полная (C, C++, Java и т. д.).

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

Ответ на вопрос без конкретной задачи позволяет понять способность мыслить абстрактно, а также понимать реальные причины выбора. А то спросишь такой «мы хотим писать веб-приложение на plain C, хорошая ли это идея?», а кандидат ответит «нет» просто потому что ему так на ЛОРе сказали, а не потому что он знает реальные достоинства и недостатки Си и наложил их на задачу.

А что ты ещё ожидал от С?

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

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

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

Любое свойство может быть достоинством или недостатком. Нужно просто посмотреть под правильным углом.

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

Ну, во-первых, кроссплатформенные фреймворки вполне имеют право на существование. Чтобы с минимальными изменениями запускаться хоть на Android, хоть на iOS. Выглядит не таким родным, иногда имеет меньшую производительность (если мы говорим про какую-нибудь Cordova), зато в разы дешевле и быстрее в выпуске.

Во-вторых, написание отдельной версии под разные ОС можно обосновать хотя бы тем фактом, что у разных мобильных ОС разные гайдлайны по дизайну и механике управления. Так что разница для юзера таки видна. А вот какой у юзера процессор в телефоне - arm, arm64, mips или x86 юзеру совершенно наплевать (максимум, он поведётся на рекламу «теперь у нас в 2 раза больше разрядность процессора, чем у конкурентов - 64 бита вместо 32», но всё равно осознавать суть не будет, кроме того, что 64 больше чем 32, а значит несомненно лучше). Точно также как он не заметит разницу в пару процентов в производительности.

Написание отдельной версии приложения - время и деньги. Зачем тратить время и деньги на заметные для юзера вещи (родной вид приложения для его платформы юзеру заметен и приятен) - понятно. Зачем тратить время и деньги на незаметные для юзера вещи - не совсем понятно.

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

Про «ответ с ЛОРа» - если кандидат замялся, то можно же дальше распрашивать «почему». А с «какие недостатки» дальше только холивар :-/.

А с «какие недостатки» дальше только холивар :-/.

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

Я вот авторитетно заявляю:

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

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

Да, один фиг вся работа — удалённая :)

мало ли, вдруг пользовался tortoise hg workbench или аналогичным инструментом

Есть прямо противоположная точка зрения - большинство языков офигенны, их продумывали и дизайнили очень крутые люди. Те же C++ (с оглядкой на их мощь) говном только эмоциональный человек может назвать. Так то конечно говно, нечитаемый код, куча плохо совместимых компиляторов для разных версий языка и платформ, нормальной IDE нет кроме MSVS, лол. Только если трезво оценить сколько сил и какими людьми в эти языки вложено, то язык (простите за каламбур) уже не поворачивается. И появляется ощущение что если ты где-то чего-то не понимаешь, то это не язык говно, а просто мозгов не хватает. И фанатизм / идеализм / максимализм тут не при чем.

Из существующих сейчас не говно тот же Go, Rust, C, С++, Java, Elixir, Pony. Python и Perl - говно, ладно, уговорили.

Хотя Java с Python можно свапнуть, ничего особо не изменится.

changeset evolution

если серьёзно, то какие у него дополнительные фичи rebase кроме возможности прятать и хранить «затёртые» коммиты и насколько сильно это отличается от концепции «хранения» инфы о стёртых коммитах в reflog в git (этой фичей я пока не пользовался)?

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

Но, как я уже сказал выше, это абсолютно нормально.

какие у него дополнительные фичи rebase кроме возможности прятать и хранить «затёртые» коммиты

Нет «затертых» коммитов. Есть коммиты, с общим предком (тоже коммитом), и средства их сравнения, мержа.

насколько сильно это отличается от концепции «хранения» инфы о стёртых коммитах в reflog в git

Как GC roots от DAG. Или, если хочешь, как ворона от письменного стола.

Наверное всё же отмечу что на момент описываемого мной собеседования changeset evolution в mercurial ещё не было. Да и странное оно, как будто mercurial и без мусорных коммитов в истории мало тормозит :-P.

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

бывают же языки, от синтаксиса которых воротит

Ты опять палишься ) Синтаксис более-менее везде адекватен. Профессионал поставит синтаксис на самое-самое последнее место.

В 18-м году ЯП в первую очередь:

- должен быть со статической типизацией

- иметь мощную IDE с рефакторингом, навигацией по коду, анализом кода на потенциальные ошибки и интеллектуальным автодополнением

- иметь качественный JIT или компилятор (в зависимости от задачи, но лучше оба сразу) для продакшн ЦПУ

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

- иметь официальную систему управления зависимостями

- уметь в ООП и дженерики в частности

- предлагать удобную работу с многопотоком

Можно ещё кучу вещей перечислить, но синтаксис будет где-то на 100ом месте... В общем, подрастешь - поймёшь.

Это всего лишь замыливание взгляда

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

Чехарда с типами - менее удобный автокомплит в IDE

Это я просто для примера привёл. Это то, что я думаю, когда вижу обвинение js в проблемах с типами.

ЯП никому ничего не должен

В 18-м году ЯП в первую очередь:

Кому интересно должен? JS сейчас чуть ли не самый популярный, а под критерии не подходит.

и это всё потребности неосилятора, анскильной лалки, как сказал бы царь

Только благодаря вендорлоку. Посмотрим как изменится ситуация с распространением webasm.

Напоминает тендеры, где требования написанны ровно под одного производителя.

уметь в ООП и дженерики в частности

А это вообще фейспалм.

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

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

доктор, откуда у вас такие аналогии

Я вот не могу ответить на вопрос «что вам не нравится?» ни про Python, ни про Go, которые знаю вроде бы довольно хорошо.

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

тред полон любителей грызть кактус

Кому интересно должен?

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

JS сейчас чуть ли не самый популярный, а под критерии не подходит

У Путина тоже 146% 76%

и это всё потребности неосилятора, анскильной лалки, как сказал бы царь

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

в самой популярной софтине написанной на Go, невозможно в рамках Go runtime корректно реализовать её основную фичу

так и быть, давай ссылку, я даже схожу.

Так говоришь, как будто у тебя есть что-то получше для моих задач.

В 18-м году ЯП в первую очередь:

- должен быть со статической типизацией

Дедуля, у нас тут 2018

P.S. остальной список тоже офигенен.

Напоминает тендеры, где требования написанны ровно под одного производителя.

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

P.S. остальной список тоже офигенен.

Слабоумие и отвага - твой выбор?

- уметь в ООП и дженерики в частности

Ты сам-то умеешь в ООП и дженерики?

Навскидку: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=iputils-ping;dist=unstable

Лол, и часто ты наизусть штудируешь багтрекеры?

Ты сам-то умеешь в ООП и дженерики?

Да я то что... Главное, чтобы ЯП это умел, а научить программировать с ООП и дженериками можно и макаку, правда это неточно (гугл так не думает).

Нет, я просто адекват. А ты серьезно думаешь, что IDE и управление зависимостями тебе «должен ЯП»?

Так если тебе не нравится - смени трико. А если тебе нужно чтобы что-то заставляло тебя ходить маленькими шагами - тогда это не недостаток.

https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix

А ты серьезно думаешь, что IDE

Да, иначе этот ЯП может не взлететь, Д тоже думал(ет), что не должен и где он?

и управление зависимостями тебе «должен ЯП»?

Не обязательно разработчик ЯП (хотя и желательно), но должен быть выбран официальный лидер, не должно быть разброда и шатания.

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

Чтобы получить профит от «взлёта» надо либо иметь историю как у C++, либо простоту как у Go. Наличие IDE это скорее следствие, чем необходимость. И есть хорошие языки которые не взлетели, но их авторов это устраивает.

которые не взлетели, но их авторов это устраивает.

Да-да, не первый раз это слышу - все ***, а я Д'Артаньян - никто меня не понимает!

Тебе же на самом деле абсолютно всё пофиг. Один ли автор своим языком пользуется, тысячи ли профессионалов взяли написанный им инструмент в работу, миллионы ли хомячков пилят сайтики на каком-нибудь «недоязычке по недоразумению попавшем на каждый компьютер». Тебе же и Страуструп - Д'Артаньян. Или есть какая-то граница?

Какие недостатки у ping?

Для работы требует либо рута (suid), либо поддержку xattr с CAP_NET_RAW. Потенциальная дыра в безопасности!

если давать права на RAW сокеты всем подряд, то это ещё большая дыра будет