Как я нашел лучший в мире язык программирования. Часть Йо (2.72)

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

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

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

    Язык программирования — зачем?


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

    Множество языков общего назначения одинаково применимо к большинству задач (поэтому из и называют общего назначения), и я не буду рассматривать случаи когда язык однозначно заточен на решение поставленной задачи. В этих случаях все более менее понятно, а если и возникают споры, то они более предметны. Интересен же наиболее частый случай — когда задача вполне нормально решается на десятках языков (а это как раз обычная ситуация). Ну вот например в вопросе: что выбрать для сервера из списка Java, Go, или JavaScript — срач обеспечен.

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

    Кроме того в дискуссиях о языках мы разбиваем языки на классы (динамическая типизация, managed runtime, и так далее), разбиваем задачи на классы, но вот почему-то практически никогда не разбиваем “программистов” на классы. Иногда, конечно, мы это делаем, но чаще всего разбивая на программистов на “новичков” и остальных «программистов», и это обычно происходит только тогда когда “новичок” сам относит себя к этому классу. Впрочем эта классификация тут же теряется, потому что даже самый махровый ламер, в ответ может начать вещать с позиции гуру, совершенно не задумываясь о том к каком классу относится он сам. Если, помимо языков и задач, начать классифицировать еще и участников дискуссии (а это надо делать), то зоопарк рисуется еще тот.

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

    Мудак

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

    Я конечно сказал что это дурдом, и что они сам себя раком поставил, да и забыл эту историю, пока не встретил знакомца в очередной раз, где-то полгода назад. Знакомец рассказал что едет в Бразилию, в командировку. Помогать бразильцам делать очень навроченную систему чего-то там на Scala. Едет он к сожалению один, поскольку для написания столь хитромудрого кода у его соратников не нашлось достаточно интеллекта, но ничего он и один справится. И в конце добавил что очень рад работать с такими умными бразильцами и восхищен их планом. План был простой: писать все на Scala обязательно, и архитектура должна быть такой, чтобы обычному человеку в голову не влезла. Что позволит им захватить маленький, но денежный нишевый рынок в Северной Америке, и жить долго и счастливо, получая ежемесячно чеки за саппорт сложнейшего продукта.

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

    Микроблоггер

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

    Есть, например, популярные в узких кругах микроблоггеры которые многие годы рассказывают о крутости всего того, что я считаю слишком умным для меня, и даже не лезу эти истории, микроблоггер же чморит всех “лохов” направо и налево, даже если вы пишете на Haskell, но не успели оценить красоту Idris (или чего-то там). Беда в том, что микроблоггера слушает молодежь, кивает и рисует в голове картину успешного программиста, который занимается умными вещами, а не бытовухой, как они и, наверное, хочет стать таким же умным. И не знают, что в реальной жизни “звезда функционального программирования”, например, копается в миллионах строк на Perl в команде из 100 человек, и практики применения всего о чем рассказывает не имеет никакой. Звезде идет четвертый десяток лет, и ни на одном месте работы его не держали более трех, да и не смог он оставить следа в жизни. Во всем интернете нет ни строчки его кода, разве что портированные чужие либы с чего-нибудь на Haskell, или с PHP на Perl.

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

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

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

    Прочие заболевания

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

    Пораженный таким вирусом юноша ведет себя, примерно, следующим образом: был у нас такой кадр, которого мы только взяли и дали отдельную задачу. Ну кадр что-то поделал пару недель и приходит посоветоваться, мол вот я тут напридумывал так и так, на доску схема не влазит, но вроде все хорошо, только вот еще пара use cases никак одновременно не получается, типа давайте выберем только один (CAP-теоретик, блин). Ну ему говорят, а давай все это твое нахер выкинем, и сделаем две такие штуки. Чувак зависает на пять минут в деадлоке, потом начинает выдавать какие-то звуки: «ну», «ну»… — «что ну?» — «ну это же слишком просто». Вирус отрубающий способность думать просто вообще распространен как простуда. Студент приходит в какую нибудь контору, там уже построен монстр который рассыпается и нужно через разные места этого монстра поддерживать, а не дай бог еще и развивать. Гавно, палки, костыли, дырки, десять человек вместо двух, и все давно заражены одним из мозговых вирусов программистов. Кстати, большинство юношей все же приходит здоровыми, поэтому мы часто слышим что «неопытные программисты стремятся переписать весь код». Но ему это сделать никто не дает, он привыкает, расслабляется, и пипец, заболел. Через пару лет у него никогда не возникнет мысли что так не должно быть. Программный продукт это сложная вещь. Программисты получают много денег за то, что эти сложные вещи делают, и по-другому не бывает.

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

    Язык программирования — почему?


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

    Как бы не так. Цели создателей языков тоже на удивление разнообразны. Вот c какой целью Odersky создавал Scala? Может быть это были сугубо академические (исследовательские) цели, и ему, как исследователю, было интересно сделать что-то новое вокруг идеи связки функционального и объектно-ориентированного программирования. Из презентации: в создании Scala он был мотивирован двумя гипотезами. Причем большинство других языков не мотивированы одной или обоими из этих гипотез. А если гипотезы не верны, то где будет Скала? А если верны то где будут другие языки? А может эти гипотезы вообще фуфло для “красоты”. Может быть он просто выполнял некий университетский “план” и типа вот вам как просите: гипотезы и брюки для птиц. А может быть Sun его чем то обидел, пока он c ними работал:

    Sun hired Martin Odersky to design Generics for Java, and the GenericJava compiler actually became the standard javac compiler shipped with the SDK as early as Java 1.2 (with the bits about generics disabled). Later on, a modified design of generics (with wildcards being the main new addition) was released with Java 1.5. Odersky, of course, went on to first design Funnel, then Scala, but his compiler still ships with Java 8.


    Почему нет? Вот представьте Мартин такой толкает Сану идеи, вот так говорит надо, а они его заворачивают. В результате вообще его работа в свет не выходит ни в 1.2 ни в 1.3. А в 1.5 выходит нечто не совсем то, что он считал правильным (у меня нет никакой информации просто вот прямо сейчас родившаяся теория заговора). Ну и он такой обозлился и типа “щас я вам, [синонимы] штопаные, покажу язык, перед которым вы будете тем что вы есть — [синоним]” и понеслось… И язык создавался совсем не для того, для чего вы думаете, а чтобы уделать кого-то, и показать кто тут главный по языкам.

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

    Вот замечательная Clojure. Родилась она изначально из замечательных идей Rich Hickey о “state, identity, value, time, types”, чувак задумался о том какие новые конструкции нужны для решения текущих и будущих проблем канкаренси и параллелизма. Изначально была проблема, идея, и решение, которое было в области Persistent Data Structures, STM, и так далее. Я абсолютно уверен что сначала появился Persistent Vector а потом язык Clojure. И то что горячо любимая некоторыми Clojure выглядит как Лисп и диалектом чего является, может быть лишь стечением обстоятельств. Вероятнее всего Лисп — был тем языком который Rich был готов реализовать максимально быстро, и который в принципе его устраивал. Сложись звезды по-другому, он мог взять или придумать другой язык. Я к тому что язык тут вообще вторичен.

    Мне хочется обозначить важность целей создателей. Вот кто-то говорит Clojure это круто потому что я могу элегантно управлять стейтом, канкаренси там бла-бля. Нет! Это не язык программирования (Clojure как диалект Лиспа) позволяет вам делать это, а идеи Рича. Язык был добавлен к этим идеям как средство использования идей. Эти концепции, будучи реализованными в других языках, а для них не нужен особый “специальный” язык, программист получит все те же радости, за которые многие любят Clojure. Нужно четко осознавать что вам нравится в языке: концепции, которые легко переносятся в другие языки, как например те же PDS во всю тащат в JavaScript или вы претесь от самого языка (диалекта Лиспа в данном случае).

    Я хочу сказать что создатели языков очень редко задаются целью создать язык с помощью которого программист будет более продуктивен. Зачастую они решают какие-то другие задачи и язык появляется как результат решения этих задач. Хороший пример JavaScript. Никто же не думает, что JavaScript сделали для того, чтобы вы повысили свою продуктивность и писали код мощнее, быстрее, качественнее. Или кто-то думает? (улыбаюсь).

    От создателя: brendaneich.com/2008/04/popularity. Вообще Brebdan Eich был приглашен в Mozilla, чтобы написать Scheme для браузера, и если бы этот изначальный план не был скорректирован то писали бы вы сейчас все на Scheme и рассказывали как это круто, можно, молодежно (простите, чуть не подавился). Почему вы сейчас пишете не на Scheme а на JavaScript — тоже никак не связанно с желанием сделать вас более продуктивными. Начиная с того, что Scheme не проканала потому что менеджмент хотел язык с синтаксисом похожим на выходящий в то же время из Sun язык Java. По массе причин вообще никак не связанным с программированием и продуктивностью вам на лопате вывалили язык сделанный в рекордно короткие сроки и сам автор даже в 2010 не понимает популярен ли он и как к этому относится, и причины популярности языка уж точно не связаны с тем что он прекрасно выполняет свое главное предназначение (в моем понимании) — увеличение производительности программиста.

    Главная и единственная цель


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

    Язык можно адекватно оценить только с одной лишь целью — производство.


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

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

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

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

    В 1999 я работал в довольно большой конторе и тогда были популярны две холиворные темы, поскольку тем было всего две, а не как сейчас десятки, то рубились не на жизнь а насмерть. Темы эти естественно Windows vs Linux и C++ vs Java. Так вот пока люди срались в курилки за Java или против я стоял в стороне и тихо ржал (а иногда громко). Причина была проста: был у меня тогда проектик, ну скажем поисковик в Intranet, или типа того. И собрался я его писать сдуру на C по причинам которые молодежь сейчас приводит как аргумент (экосистема). Так вот следуя этому аргументу, на Java писать тогда было никак нельзя (ибо 1.2 по моему была еще только в бете) а экосистема вообще никакая. А на плюсах были какие-то типа полезные либы и фреймворки.

    В мире Java даже Lucene тогда еще не было, появилась чуть позже и была в моменте никакая. Ну да ладно, вот и я как бы повелся, что надо бы писать на плюсах, наелся гавна (в том смысле что вместо того, чтобы программировать — думал за компилятор, скрещал библиотеки, и так далее). Слава богу у меня была производственная возможность плюнуть на все и переписать на Java. Чуваки сначала конечно покрутили у виска, сказали что скорости не хватит, пришлось им показать что мы только и делаем что файлуху читаем, а это вообще ни к Java ни к плюсам отношения не имеет.

    На творческую переработку того, что успелось сделать плюсами на Java у меня ушло в 10 раз меньше времени чем на оригинал (да я был конечно уже в теме, но во время написания оригинальной версии ресерча не было — благо были документы описывающие алгоритмы индексации и crawling от пары чуваков из Стенфорда — Сергей и Ларри их по-моему звали, все было просто и понятно, а их патентованый алгоритм ранжирования результатов поиска при наших объемах был не нужен, да и бесполезен. Те чуваки, кстати, как раз тогда только открыли компанию занимающуюся поиском в интернете).

    Ну и вот стою я, значит в курилке, слушаю треп за темплейты, перегрузку и переопределение чего только можно, макросы-шмакросы, аллокаторы, производительность и множественное наследование (!). Гуру C++ нападают на маленьких студентов и вываливают на них всю мощь этого языка. Типа вы тут на своей Java и так не сможете, и вот так не сможете, и вот так неполучится (как в том анекдоте, сделай меня раком). А я чо то про себя ржу, и довольно улыбаюсь. Вертел я все эти ваши аллокаторы с темплейтами на своем множественном наследовании. Какая мне разница что вы там можете, и как вы можете, если я могу писать код в 10 раз быстрее вас, ну хорошо, опытный С++ программист у которого уже всё в крови и других частях тела будет писать быстрее, значит я буду быстрее его в 5 раз. Да хотя бы в 2-3 раза. Если я буду делать то же самое в 2 раза быстрее какое мне дело что у него там за темплейты. А ограничения? Да их нет — скорости нам хватало, памяти тоже, а ядра операционок мы писать не собирались.

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

    Таких ярких вспышек, когда ты вроде бы программировал как обычно, тяжело, как на стройке кирпичи таскают, а потом вдруг получил в руки чудесный инструмент, волшебную палочку, и кирпичи начали сами летать туда, куда ты хочешь, я испытал всего лишь пару за вот уже двадцать с лишним лет программирования за деньги. Про переход с С++ на Java я уже сказал. Примерно так же было, когда мы программировали десктопные аппликухи на Visual C++ 1.0, 1.5 или около того. Тогда сделать какой-нить диалог с тремя кнопками (которые еще не скоро начнут работать как надо) была большая задача, на денек так. Все эти макросы, и прочая хрень, которую я к счастью не помню. Чтобы, если что, понять как на самом деле твой код общается с виндой надо было с ума сойти продравшись через горы плюсовых библиотек.

    И тут появляется Delphi. Кто то может посмеяться, но это была реальная революция (ну а тем кто опять не верит скажу, что архитектора Delphi, Anders Hejlsberg обалдевший Microsoft почти сразу переманил, и в том же Microsoft Anders был ведущим архитектором C#). Так вот, ты садишься за Delphi и делаешь что хочешь, хочешь пользовательский интерфейс, хочешь низкий уровень, все flow понятны, вызовы в операционку, можешь дописать сам чего хочешь (например поддержку новых контролов от Microsoft, не дожидаясь выхода новой версии Dephi). Понятно, и на расстоянии вытянутой руки ты видишь все вплоть до лайаута таблиц виртуальных методов в памяти (ну если вдруг надо), и самое главное, ты пишешь такой же софт, что писал раньше в 10, а то и больше раз быстрее. Ограничения? Да нет их. Вообще нет, ломануться куда нибудь в недра операционки проще чем раньше.

    Из этих двух рассказов можно сделать вывод, что я за простоту. Нет это не так и с самой простотой не все так просто :) Загнул так, что вспомнил толк замечательного Rich Hickey, скажем просто “про простоту” — очень хорошая вещь. В контексте языков программирования я не за сложность или простоту языка, а за мощь компилятора и простоту его использования. Чем лучше он меня понимает (выразительность) и чем больше за меня делает — тем лучше, при исполнении того же самого, и единственного условия: любое усложнение языка/компилятора, должно увеличивать мою производительность а не уменьшать.

    В JVM мире есть хорошие примеры. Да и сама Java — такой пример, если сравнивать Java с C++ скажем так пофичечно — Java проиграет, ну прям с разгромным счетом. Но есть внутри JVM сложная штука, которой нет в плюсах — Garbage Collector. Java без GC (хотя это было бы совсем не Java) не дала бы мне возможность писать код в разы быстрее. Как ты не упрощай дальше или не усложняй опять. Продуктивность программиста выросла в разы по большому счету благодаря сборке мусора (это когда компилятор и рантайм думают за вас, причем постоянно), а помех она не создает (разве что последнее время, в связи с дешевизной памяти и трендом писать на Java вообще всё, GC в некоторых случаях опять становится проблемой).

    Генерики в 1.5, ничуть не усложнили использование Java, а лишь увеличили продуктивность. То же самое видимо с лямбдами (но честно скажу, что уже не застал). Ровно эта причина — увеличение продуктивности, заставила меня задуматься о более продуктивном языке чем Java в 2008, и поэтому я надеялся на Fantom. Его я хочу привести как пример языка, основной идеей которого была и есть увеличение продуктивности програмииста. Ребята которые сделали Fantom главной целью ставили продуктивность, сдесь и сейчас, в нашей реальной работе:

    Fantom is designed as a practical programming language to make it easy and fun to get real work done. It is not an academic language to explore bleeding edge theories, but based on solid real world experience. During its design we set out to solve what we perceived were some real problems with Java and C#. Our background is heavily Java, but many of Java's problems are shared by C# and .NET also.


    Если кто-нибудь заморочится почитать их форум, то четко это поймет. Именно эта ориентированность на продуктивность инженера привлекла меня в языке, и духовный опыт вовлечения в язык был хоть и не так силён, но похож на опыт перехода с плюсов на Java, когда код льется из под пальцев и ты понимаешь что Java не дала бы тебе делать то же самое с такой скоростью, когда ты чувствуешь больше свободы (а Fantom ничем не ограничивает Java программиста предоставляя удобный FFI и native classes, но дает еще и браузер как платформу), и ты понимаешь — вот она, та самая доза продуктивности, которую ты ищешь, находишь, но со временем тебе ее снова перестает хватать.

    Fantom я хотел привести в пример потому что в нем нет генериков, и продуктивность, которую фантом дает программисту по сравнению с Java не связана с наличием или отсутствием генериков. Про отсутствие генериков в Фантоме я хочу сказать тому подавляющему классу программистов, которые ищут в языках фичи а не продуктивность. Неужели вы думаете, что авторы языка не смогли бы добавить в язык и генерики и черта лысого? Тем более что фантом прекрасный пример языка, который люди просто написали для себя, даже не так, для своего бизнеса. Для собственной продуктивности и продуктивности бизнеса в целом.

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

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

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

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

    Так вот, эти мои склонности к абстракциям были облиты холодным душем, когда в 2002 году я “нашел” (улыбнулся, поскольку перекликается с данной статьей) eclipse. Eclipse меня очаровал своей архитектурой и дизайном. Сейчас про eclipse к сожалению услышишь мало что хорошего, но это от тех кто никогда ее не видел внутри, а если и заглядывал, то не достачно чтобы рассмотреть.

    Я же в жизни видел единицы столь качественно задизайненых платформ, но это и не удивительно — один из архитекторов Eclipse Platform — Erich Gamma. Он же один из банды четырех — авторов популярной в те времена книжки под названием Design Patterns. Не знаю на сколько она популярна сейчас, но на рубеже 2000 годов во всех конторах как правило гоняли по дизайн паттернам на собесах.

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

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

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

    Подводя итог


    Пара слов про экосистему. Экосистема безусловно важна, но аппелировать к экосистеме — это переводить вопрос в другую плоскость. С новыми технологиями и языками — это как на бирже, обыватель сливает депозит в 90% случаев. Ну не так жестоко как на бирже, но суть та-же. Когда толпа ломится покупать актив — весь рост там уже закончен и сливки (продуктивности в том числе) давно собраны. Я взял «акции» Java в 1999 (далеко не в первых рядах), в то время когда экосистемы была мягко скажем неразвита. Но тот рост продуктивности для себя и команд, и безумный рост акций Java в следующие десять лет позволяет мне скромно улыбаться когда программисты начинают аппелировать к экосистеме. Это то же самое когда вы начинаете говорить что покупать акции Apple не стоит — потому что они очень дешевы.

    Ха-ха. Вот как раз покупать акции когда они дороги не стоит, поскольку потенциал роста там уже исчерпан. Все что вы можете купить — это относительно долгую или не долгую стабильность. Хотя для того чтобы купить правильный актив — нужно действительно понимать его ценность (несмотря на низкую цену), и быть уверенным в том, что покупка начнет приносить вам дивиденды сразу, а не в далеком будущем. Точно так же мы выросли на «акциях» eclipse с 2002 года, когда у eclipse был сумасшедший потенциал к росту, и которые подросли до максимума году к 2008. С того времени я и пытался выйти из акций Java и eclipse в другие технологии, ибо потенциал роста исчерпан, а раз так — надо выходить. Языки и технологии дают вам конкурентное преимущество, а если вы сидите на тех же самых языках и технологиях, что и половина программистов вокруг — о каком технологическом преимуществе может идти речь?

    Возвращаясь к выбору правильного языка. Мне не важны фичи языка, их может быть сколь угодно много или сколь угодно мало. Мне интересно насколько язык увеличит продуктивность меня и команды, сейчас и в будущем, для известных и неизвестных задач. Вот и все. Все остальное не важно. Как часть продуктивности, язык должен разгрузить мне голову. Я не должен думать про язык, как мне приходится на Scala или Rust. Я не хочу держать в голове кучу вещей которые можно не держать как в языках с динамической типизацией. Увидев чужой код я должен сразу понимать что тут делается а не заниматься долгими исследованиями всего, что есть вокруг, как в примере со Scala из части 2. Не потому что не могу, а потому что я не вижу в этом смысла, я не вижу как все это сделает меня более продуктивным, и соответственно не верю.

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

    Вам знакомо чувство, когда вы выходите из унылого Reno Logan, на котором таксист вез вас до стоянки, долго втапливая педаль в пол чтобы кого-то обогнать, и садитесь за руль современного автомобиля с тремя-четырьмя сотнями кобыл под капотом, который вас разгоняет до той же сотни за 5 секунд? Это прекрасно — чувствовать всю мощь железных технологий под капотом, мощь, которой вы управляете по собственному желанию, и вся эта мощь делает то, что вы хотите, и так как вы хотите. А еще это называется свобода.

    Пока,
    Платов

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

    Подробнее
    Реклама
    Комментарии 236
    • –1
      Аааа, думал не дождусь продолжения :)
      • +1
        Ну после того комментария странно было бы не увидеть продолжения :)
      • +8
        Языки и технологии дают вам конкурентное преимущество, а если вы сидите на тех же самых языках и технологиях, что и половина программистов вокруг — о каком технологическом преимуществе может идти речь?

        В таком случае, как объяснить ваше желание рассказать всем о «дешевых акциях» — переизбыток чувств, глупость или скрытые мотивы (пропихнуть всем ложное направление, а самому купить реальные акции :-)?
        • 0
          Сразу видно, что на бирже вам делать нечего :) надо быть проще и честнее и тогда все будет. Я уже в дешевых акциях и получаю дивиденды. Если акция хорошая — она будет расти, со мной или без меня. И это хорошо для меня. Рост долгий, и если люди туда заходят быстро, то хорошо, заходят долго — тоже неплохо
          • 0
            Если вы успели купить достаточное количество акций, значит они уже не такие дешевые) Видимо, о количестве ваших строк кода на Nim будет в третьей части, ждемс…
            • –1
              Не играйте на бирже :)
              • +1
                Это все равно, что вам бы вам в детстве посоветывали «Не программируйте :)».
        • +14
          Во всем интернете нет ни строчки его кода, разве что портированные чужие либы с чего-нибудь на Haskell, или с PHP на Perl.

          Мне кажется, я знаю о ком идёт речь…
          • +1
            И уже еще +7 человек знают. Интересно, они все об одном и том же «микроблогере» думают? :)
            • 0
              Если говорить о русскоязычных «микроблогерах», то несомненно да.
            • +8
              Интрига! О ком? )
              • +1
                Так, что бы не надумали там себе всего.
                Я имел ввиду уважаемого afiskon.
                Я ничуть не сомневаюсь в его профессионализме и никоим образом не хочу его обидеть. Но его посты в блоге и темы подкаста очень напоминают описание из статьи.
                • 0
                  Я когда читал у меня самого возникло чувство, что речь обо мне. Но на самом деле не сходится. Я на Perl за деньги писал три года назад и тогда подкаста не было, о блоге никто не слышал, да и ФП, насколько помню, я вроде бы не особо расхваливал, сам только разбирался во всем. Есть подозрения, что образ, описанный господином platoff является собирательным. Или нет? ;)
                  • +1
                    Конечно образ собирательный. И у каждой аудитории будут разные ассоциации.
              • 0
                Просветите. Можно в личку.
                • 0
                  Это тот, который Самизнаетекто? (На букву «Л»)?
                  • 0
                    А он разве как-нибудь относится к программированию?
                    • +1
                      Луговский?
                      • 0
                        Самизнаетекто это Лебедев. Про Луговского впервые услышал.
                      • 0
                        Пожалуй Вы правы. Чуть менее, чем никак. Тогда я без понятия о ком речь :(
                  • +37
                    — Хотите, научу вас как заинтриговать?
                    — Хочу!
                    — Завтра расскажу как.
                    • +12
                      С такими характеристиками стоит на zadolba.li писать, а истории про себя правильного на ithappens. А этот сайт ведь когда-то чисто техническим считался, где хорошим тоном было писать статьи без ложных предпосылок, не забывая четкие аргументы, а при сравнения объективно рассматривать обе стороны в рамках своего понимания.
                      • +19
                        Ну слушайте, что аргументов нет — заметно, но язык-то, язык! Большое удовольствие читать. «Хабр» и так уже стал невыносимо пресным, просто тошно.
                      • +21
                        Кстати, на моей памяти есть один язык, который действительно создавался с целью упростить жизнь программистам и сделать их более эффективными. И этот язык, как бы не забавно это прозвучало — PHP, как можно заметить, судя по статистике — с задачей он своей справляется «на ура».
                        • +6
                          Не только PHP. Один из первых — Forth. Автор Чак Мур искал продуктивности всю жизнь и так появился и эволюционировал его язык. История тут www.colorforth.com/HOPL.html а вообще да, PHP правильная вещь
                          • +3
                            Увы, историю форта, в отличие от сабжевого я не знаю. Надо будет почитать, спасибо.
                        • +8
                          Вы 10 лет пробовали все языки, но, если я правильно понял, С++ то вы так и не пробовали? Почему? «Пробовали» в смысле реальном, чтобы себя назвать С++ программистом. Или всё же было?

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

                          И снова, уповаете за продуктивность, чтобы просто и понятно, легко, всё было доступно, а выбрали Nim. У него хоть инфраструктура есть какая-нибудь? XML-ку там распарсить, с ОС как-нибудь удобно поработать?

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

                          А вообще, методология ваша хороша, и задачу вы себе поставили хорошую, но, боюсь, нерешаемую. Хоть вам и кажется, что вы нашли грааль)
                          • +6
                            Ну С++ бывает разный. Это сейчас C++11 удобен и крут и есть много примеров хорошего кода на которых можно учиться, а в 90-х годах «писать на плюсах» подразумевало как правило что-то типа архиуебищного MFC, причем нормальных компиляторов у плюсов не было, и баги когда компилятор генерировал неверный код из верной программы не были чем-то из ряда вон выходящим

                            Поэтому говоря о плюсах многие понимают под этим разные вещи. Особенно если начинать на плюсах доводилось в 90-х :)
                            • 0
                              Я писал под платформы Borland (C++ 3.1, а затем линейка Builder) — всё было вполне ОК, уж точно, не хуже, чем сейчас.
                              А с MSVC было страдание, да, но никто ж не заставлял.
                              • 0
                                Borland был весьма неплох, сам писал в бытность студентом, но имхо коммерческих проектов на нем было очень мало
                                Так что коммерческий софт заставлял страдать с MSVC
                          • +4
                            А часть Пи (3.14) будет?
                          • +1
                            А как находка такого замечательного языка отразится на вашей конторе (хотя бы в общих чертах), особенно учитывая(на сколько я знаю), что основные продукты/заказы вы делаете на jvm-based языках (java/fantom/scala)?
                            • +2
                              ровно так, как находка Java и eclipse отразилась на конторе во времена когда про eclipse мало кто знал. А eclipse foundation еще не был создан. Прекрасно отразится. Есть компании-конъюнктурщики. Как и программисты конъюнктурщики. Они подстраиваются под рынок. Есть те которые сами понимают что хорошо, а что плохо, и идут впереди рынка.
                            • +10
                              Очень понравились рассуждения про набор языковых фич и экосистему.

                              Однако, считаю, что следующая «большая вещь» будет вообще не вокруг языка. Те же (очень хорошие) примеры из этой статьи про Delphi и Java подтверждают этот тезис. И Delphi и Java — не были просто новыми языками. В тот момент когда они еще не имели экосистемы, они уже были гораздо больше платформами, чем языками. А язык был вторичен. И действительно, если продумать базис, платформу, то можно на нее хоть LISP натянуть, добавив больше или меньше фич. Та же Java — это, по-большому счету, упомянутый ранее Оберон с синтаксисом C, чья платформа была продумана на качественно новом уровне (но и сам Оберон как язык без Оберон-системы абсолютно бессмысленно рассматривать).

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

                              Идея же наслоится на существующие платформы (и для «браузера» и для «железа») мне кажется — не жилец.
                              • +2
                                Если немного отойти от понятия вычислительной платформы, то можно много чего разглядеть… Например cloud-платформы типа гугловой, микрософтовской, амазоновской.

                                Еще есть платформа программирования под Эппл, далвик со своим байткодом
                              • +7
                                Так забавно читать, как автор смело лепит ярлыки а ля «мудак» на человека, который действует абсолютно правильно в его личной системе ценностей… Вроде бы взрослый человек, а категоричность как у 18-летнего юнца. Просто задумайтесь на секунду, что другие люди не лучше и не хуже — они просто другие. То же самое касается и языков программирования. И мир засияет новыми красками, девушки станут Вам чаще улыбаться, мужики будут чаще здороваться, Java перестанет быть прожорливой, а C перестанет быть средством для изощренного самоубийства.
                                • +6
                                  А еще более забавно читать о том, как кто-то смеётся над двухцветной точкой зрения, заменяя её одноцветной. Это же классическая дилемма заключенного. Пока «мудак» один, он в выигрыше, но целое общество таких людей погребет само себя в пучину отчаяния.
                                  • +7
                                    Для взрослого человека (думаю и не только для взрослого) естественно иметь морально-этические принципы и делать некоторую градацию людей на их основе.

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

                                    P.S Люди, которые говорят что нет хорошего/плохого/правильного/не правильного/ (в рамках разумного контекста разумеется) мне всегда казались несколько странными.
                                    • +3
                                      Вот именно! Как будто есть что-то плохое в том, чтобы работать на не самом популярном языке, чтобы получать больше денег и иметь меньше конкуренции. Не стоит забывать, что у это есть и обратная сторона — делая ставку на не самый популярный язык, программист берёт на себя риски.
                                      • +2
                                        Ну смотрите вы заказчик, наняли команду условных программистов. Они вам запилили за N время базу для проекта, вроде все работает. как надо. Запилили они на каком то малоизвестном языке(вы как заказчик можете и не разбираться популярный он, удобны и т.п.). Тут вам захотелось добавить функционала в систему. Простите команду добавить простую фичу, а это добавление занимает архи много времени.(Повторить предложение N раз) Вы понимаете что не может столько времени заниматься добавление такой фичи. Или команда начинает просить немыслимую сумму на поддержку. Далее можно вставить любую проблему из-за которой вы не хотите работать с этой командой программистов. Решаете найти другую команду, а таких команд либо нет, либо совсем мало и не кто не хочет браться за ваш проект.(Причина возможно цена, или команда сильно занята и не готова уделять нужное кол-во времени проекту).

                                        Вот как назвать людей из первой команды? Конечно мудаки. Я думаю вот именно о таких людях автор говорит.
                                        • +6
                                          Так автор же сам из этой же группы.
                                          Он выбрал язык, на котром пишет, во всем мире, хорошо если несколько сотен человек.
                                          Что делать его клиентам?
                                          Он заставит своих сотрудников изучтать… вернее покупать акции неизвестной компании.
                                          Которая, как ему кажется, вырастет в цене.
                                          А люди будут покупать эти акции за самый дорогой ресурс в мире, за свое собственное время.
                                          Сколько там игроков на бирже сливается в пух и прах?
                                          Вот такой же процент людей, в его конторе, пойдет по миру с этими акциями.
                                      • +6
                                        Продуктивность вовсе не единственный критерий. Есть ещё, например, безопасность. Если язык гарантирует, что в написанной программе не будет целого класса уязвимостей, то это большой плюс.
                                        • +2
                                          > Если язык гарантирует, что в написанной программе не будет целого класса уязвимостей, то это большой плюс.

                                          Это также означает, что этот язык продуктивнее других с точки зрения написания менее уязвимых программ. Просто какие-то языки продуктивнее в этом разрезе, какие-то в другом. В итоге все сведется к человеко-часам на разработку продукта в целом. Поэтому общая продуктивность процесса разработки главный критерий. Так же как и в бизнесе ROI.
                                        • +2
                                          Окончание как в голливудских фильмах…
                                          • 0
                                            Глянул на Nim. Похож на Python по синтаксису. Будет теперь альтернатива для питона только на компиляторе уже. :)
                                          • +4
                                            Статья категорически не понравилась, слишком много пафоса. Но идея, которую автор хочет донести, возможно стоящая.
                                            • +2
                                              «слишком много пафоса» — слишком много букв. Такое ощущение, что автор хряпнул кружечек 6-8 пива, а потом стал писать статью в невыносимом желании попи@деть. :) Все можно было выразить раз в 5 короче и яснее.
                                            • 0
                                              Очень интересно узнать ваше мнение про Ruby. На данный момент он к сожалению практически не пригоден для написания десктоп-приложений с GUI, но для web приложений работает очень хорошо. Консольные утилиты писать тоже неплохо. Что примечательно — как раз создавался с идеей быть выразительным, легким и приятным в использовании, продуктивным с точки зрения быстроты написания кода.
                                              • +15
                                                Языки с динамической типизацией дают какой-то положительный эффект в смысле продуктивности на старте, но очень быстро (с ростом размеров проекта) этот эффект проходит и обращается в проблемы. Большой проект на таком языке (включая Ruby) требует больше усилий на написание тестов, а программисту приходится помнить гораздо больше вещей, типа объекты какого типа принимает тот или иной метод. В общем для маленьких и быстрых проектов, типа консольных утилит, для прототипов и небольших веб-приложений, в качестве скриптового языка внутри некоей большой системы — да, Ruby и его коллеги очень хороший выбор. Для больших систем, я бы Ruby не брал.
                                                • 0
                                                  Ясно, благодарю за подробный ответ!
                                                  • +3
                                                    Допустим, держать в голове нужно больше. А если вдруг, у вас есть дурацкая привычка комментировать методы с указанием типов принимаемых/возвращаемых аргументов и ваша любимая ИДЕ подсказывает если вы передаёте неправильный тип или на стадии вызова метода с помощью хоткея говорит, какой тип нужно передать? Тогда мы и производительность получаем от динамической типизации и от проблем «незнания» уходим. Да, компилятор/интерпретатор не сломается из-за неправильного типа, но это уже нужно рассматривать подходы к программированию, а не, опять же, языки.
                                                    • 0
                                                      А если вдруг, у вас есть дурацкая привычка комментировать методы с указанием типов принимаемых/возвращаемых аргументов и ваша любимая ИДЕ подсказывает


                                                      Это какой-то костыль… Хороший язык должен уметь, для некоторых особых случаях, динамическую типизацию, и статическую во всех прочих.
                                                      В принципе, на java можно эмулировать, передавая везде object.
                                                      А в c# 4.0 так вообще завели тип dynamic, который мало того, что хранит что угодно, так ещё и диспетчеризирует в подходящую ф-цию при вызове.
                                                      Скрытый текст
                                                              void test(dynamic a)
                                                              {
                                                                  Run(a);
                                                              }
                                                      
                                                              void Run(int z) { ... }
                                                      
                                                              void Run(string s) { ... }
                                                      • +2
                                                        Не знаю, как на Ruby, но на том же Python местами приходится «комментировать» код нездоровым количеством ассертов, которые перегружают реализацию, выполняется двойная и тройная работа, продуктивность серьёзно проседает. Да, гибкость, за которую многое можно отдать. Но в крупном проекте — сложность растёт в итоге не только от сложности самого проекта и цена выходит за всякие разумные рамки, так что даже IDE тебя начинает посылать, приходится от «гибкости» отказываться везде, где действительно можно обойтись без неё — приходит просветление и трансцендентное осознание концепции KISS.
                                                        • +1
                                                          Если у вас так много ассертов, вполне возможно вы делаете что-то не то.
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                        • –5
                                                          а программисту приходится помнить гораздо больше вещей, типа объекты какого типа принимает тот или иной метод.
                                                          Это домыслы разработчиков статической типизации, на практике (конкретно в Питоне) проблем обычно не возникает, даже если залезть в чужой проект.
                                                          Даже если вы знаете какой тип передавать (со стат. типизацией), это не всегда поможет.
                                                      • +7
                                                        В принципе, у меня достаточно однозначный принцип определения субъективного «качества» языка — это тот же code quality measurement, что и для качества кода

                                                        XKCD, если кто не знает
                                                        image


                                                        Синтаксический сахар хорош тогда и только тогда, когда он не противоречит этому правилу. Поэтому Python у меня в обороте, а Ruby нет. И Typescript, а не Coffee и прочие диалекты.

                                                        Это я к чему собственно. Третий день играюсь с Nim'ом, и у меня все сильнее создается впечатление, что у автора во многом схожий подход. Я понимаю, как оно работает; понимаю, какой C-код он мне выдаст; понимаю, где в библиотеках копать в сторону того или иного куска. И как без ненужного геморроя перейти на уровень вниз (до plain c) я тоже понимаю, а это ой как немаловажно.

                                                        Не идеал, конечно, но прагматичный язык. Очень прагматичный.

                                                        Лайк
                                                        • 0
                                                          Есть мнение, что Rust более строгий и дисциплинированный чем Nim:
                                                          habrahabr.ru/post/259993
                                                          • +1
                                                            Верное мнение, но непротиворечит ни сути статьи, ни комментарию
                                                            • +8
                                                              Фишка Rust в том, что он выносит приличную долю ловли блох на этап компиляции, а не отладки. У кого-то это создаёт впечатление сложности самого языка, который тяжело заставить собрать программу. Но на практике это означает лишь то, что программист, мнящий, что он ЗНАЕТ все входы и выходы в своей программе, на самом деле тешит себя в иллюзиями и будет собирать эти грабли чуть позже на этапе закрытия тяжелоуловимых багов, возможно вместо выходных, поскольку упало именно на продакшене и закрыть период нужно было ещё вчера.
                                                              Что ж, я так понимаю, в ближайшее время мы будем наблюдать захватывающий этап становления нескольких достойных языков, каждый из которых предлагает свой компромисс между простотой и дисциплиной и каждый по своему нацеленных на продуктивность.
                                                          • +8
                                                            Что я понял из статьи, пока хипстеры и всякая школота занимаются своими хипстерскими делами настоящие инженеры ипошат код не шурша.

                                                            А если серьезно очень интерсно было почитать рассужедния опытного инженера, благодраю.
                                                            • 0
                                                              Хорошая статья. Понравился пример с автомобилями :)
                                                              • +3
                                                                Бесполезный tl;dr про кодорелигию.
                                                                • +2
                                                                  Как раз наоборот, про материалистический атеизм
                                                                  • +8
                                                                    Программирование — это решение задач на языке программирования. Критерии могут применяться только к двум вещам — задачам и решениям. Все остальное вам показалось.
                                                                    • –4
                                                                      Программирование, как и любая работа, это по большей части неприятное времяпровождение, за которое платят деньги.
                                                                      К степени «неприятности» критерии тоже могут применяться.
                                                                      • +5
                                                                        >это по большей части неприятное времяпровождение
                                                                        Только у тех, кто туда шел ради денег, а не потому что нравится процесс в первую очередь )
                                                                        • –4
                                                                          Ну не знаю, как показывает мой небольшой опыт, если моя работа мне в радость, то либо я работаю спустя рукава, либо я делаю совсем не то, что нужно заказчику, либо заказчик я сам.
                                                                          В обычном режим работы — нужно качественно, вчера, и соответствовать вон тому взаимоисключающему списку требований от маркетолога — чувство «приятного времяпровождения» обычно значит, что ты занимаешься херней самообразованием вместо работы.
                                                                          • +3
                                                                            Всегда можно найти такую работу, где не придется ненавидеть начальство и делать что-то интересное, вопрос лишь в Вашем желании что-то менять, а не сидеть на пригретом месте без преспектив годами)
                                                                            • –1
                                                                              Спасибо за совет, но я и есть начальство. А любая интересная работа это 95% рутины, по другому результата не достичь. И «сидеть на одном месте без перспектив годами» — настоящая работа делается именно так, что бы там ни писали вышеупомянутые микроблоггеры.
                                                                              • +1
                                                                                я и есть начальство

                                                                                В обычном режим работы — нужно качественно, вчера, и соответствовать вон тому взаимоисключающему списку требований от маркетолога

                                                                                Весло вам, чо )
                                                                      • +4
                                                                        Угу, а рисование — это нанесение красок на холст наиболее подходящим для этого предметом.
                                                                        • +5
                                                                          Проблема в том, что вы действительно считаете, что привели верную аналогию с моими словами.
                                                                  • +19
                                                                    Отлично, оказывается мир программистов делится на три категори: мудаки, микроблогерры и «прочие заболевания». При этом автор относит себя ко всем трем одновременно… Весьма недурно.
                                                                    Что до «лучшего языка» с «иконкой как у миранды» и недоросшим даже до пресловутой версии 1.0 — лет через 10 будет хоть что-то по нему ясно наверняка, пока нужно быть полным «микроблоггером», чтоб на него пересесть.
                                                                    • +1
                                                                      Необязательно микроблогером.
                                                                      Первая категория тоже отлично вписывается в выбор)
                                                                      • +3
                                                                        Про 10 лет, Вы, конечно, преувеличили. Но вот «прямо сейчас», о чём так настойчиво говорит автор, ехать на этом феррари как-то рискованно, учитывая, что двигатель и колёса могут ещё пару раз заменить прямо на ходу.
                                                                      • +1
                                                                        Автор, так если вы так одержимы идеей идеального языка программирования, почему вы не создали свой?
                                                                        • 0
                                                                          Помимо картинки про 19 стандартов — это еще большая ответственность, и куча потраченного времени и денег, именно в таком порядке.
                                                                          • +2
                                                                            Думаю он просто не достаточно умен для этого.
                                                                            Ну правда же звучит глупо — «Я знаю как создать идеальный язык, но я боюсь ответственности и мне жалко времени и денег»
                                                                            • +7
                                                                              1. Автор статьи действительно не знает, каким должен быть идеальный язык программирования, он знает лишь для чего ему язык, и как он отличает плохой язык от хорошего. Поэтому автор в статьях пишет, что он искал язык
                                                                              2. Как человек который делал продукты, которым пользуются другие люди я прекрасно понимаю mjr27, имеется ввиду что создав язык вы берете на себя ответственность его поддерживать, развивать, общаться с пользователями, учить и так далее. Вы будуте ответственны перед людьми, которые в вас поверили и положились на ваш продукт. И это помимо времени (и денег) которых действительно жалко. Время в жизни ограниченно и у меня есть много более приоритетных хотелок. Не знаю зачем я вам ответил, вы очевидно даже близко не оказывались в таких ситуациях, когда люди боятся ответственности, и жалеют время
                                                                              • +2
                                                                                Почему это не оказывался? Оказывался. Просто по характеру ваших сообщений мне показалось, что если бы вы были уверены, что знаете как сделать идеальный язык — вы бы этих вещей не пожалели.

                                                                                В конце концов вы писали про 20 лет занятием программирования за деньги, и на сколько я мог понять этот способ заработка вам вполне нравится (с точки зрения получения удовольствия от работы).
                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                          • +1
                                                                            Зря не поставили тэг «философия программирования», поддержали жизнь в тэге.
                                                                            • +1
                                                                              А еще это называется свобода.

                                                                              Нет, сэр, это ваша зависимость, а не свобода)
                                                                              • +6
                                                                                Судя по обилию негатива в статье автор явно на кого-то обижен. Бывает, не с теми людими работал.
                                                                                У меня другая ситуация по сложности понимания кода — коллеги не успевают за уровнями абстракции, так как им лень учиться, и поэтому считают мой код сложным, хотя продуктивность зашкаливает. Редкие языки/паттерны выбираются, всё же, чаще не для того, чтобы кого-то ввести в заблуждение, а чтобы решить задачу естественно и подходящими для неё средствами. Точно так же, как хороший писатель обладает большим словарным запасом, Войну и мир не описать в 1000 слов. Если у читателя словарный запас меньше — значит нужно тянуться вверх, а не ныть.
                                                                                • 0
                                                                                  Стоит ли ожидать IDE от твоей компании для этого языка в ближайшее время?
                                                                                  • 0
                                                                                    Не знаю :) это как компания решит. У меня лично пока такого плана нет, но посмотрим
                                                                                    • +8
                                                                                      Стало быть ждем статью «как я искал идеальную IDE для Nim»? )
                                                                                  • +8
                                                                                    > С одной стороны все выглядет красиво, качественно, я бы сказал восхитительно, с другой стороны — вот тут же можно было переиспользовать, и тут, и тут, вот тут вообще чуваки сознательно копи-пастят.

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

                                                                                    У зрелого программиста все высушено до предела.

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

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

                                                                                    Основная задача программиста — снижать сложность, если избавление от копипасты сложность увеличивает, а поддерживаемость уменьшает, то, возможно, оно не нужно.
                                                                                    • +1
                                                                                      Так… автор же об этом и пишет в последующем абзаце:
                                                                                      то для людей создающих платформу, на которой предполагается одновременный запуск сотен плагинов, различных версий и от десятка не знающих друг о друге вендоров любая лишняя зависимость — зло
                                                                                    • –1
                                                                                      Сколько надо бухнуть чтобы все это с комментариями дочитать до конца?))Пойду…
                                                                                      • 0
                                                                                        platoff, а почему в списке всего нету dart?
                                                                                        • 0
                                                                                          По-моему он довольно однозначно выразился обо всех языках с динамической типизацией.
                                                                                          • 0
                                                                                            Dart provides a static checker that can warn you about potential problems, without getting in your way.
                                                                                        • –5
                                                                                          Ты мне все больше нравился до этой статьи (:

                                                                                          А тут ненаязчиво наехал на перл.

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

                                                                                          Вот раньше была трава зеленеее были хакерские форумы, где интересующаяся молодежь попадала в гностический рай: куча молодых и не очень людей, объединяющихся в свободное сообщество любящих получать знания. Обменивающиеся информацией, пишущие статью и о программировании, администрировании, взломе и т.д. На таком огромном объеме разнородной информации и формировались собственные вкусы, выборы языка, профессиональное мировоззрение. Плюсом прививались полезные вещи вроде стремления писать качественный код, безопасные инструменты, применять и создавать свободные решения. Конечно, бизнесу нет особой потребности в хакерах, поэтому нынче есть ит-спецухи в вузах и хабрахабр (:
                                                                                          • +8
                                                                                            Хотелось бы заметить, что продуктивность хоть и связана с языком довольно тесно, но не определяется им (как только языком) на 100%.

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

                                                                                            Кроме того, для многих языков получается, что, как только начинаешь с ними работать, продуктивность находится на достаточно низком уровне, но затем, по мере их использования и погружения в сам язык и экосистему, продуктивность очень сильно и быстро возрастает. Лично я отметил это на опыте работы со Scala и Rust, но, я думаю, это верно и для других языков тоже. Например, я долгое время считал, что Scala — это C++ из мира JVM, слишком сложный и перегруженный язык, которым невозможно пользоваться. Такое мнение у меня сложилось, когда я в течение около месяца попытался на нём что-то накодить. Однако, поработав немного на Java и попробовав написать на Scala проект посерьёзнее, моё мнение изменилось на противоположное. Сейчас моим основным рабочим языком является Scala, и я до смерти рад, что мне больше практически не приходится писать на Java. После «вхождения» в язык, изучения его экосистемы и best practices, принятых в коммьюнити, продуктивность работы на языке очень сильно возросла. Как я уже говорил в комментарии к предыдущей статье, у Scala ещё есть множество болячек и неудобных мест, и да, как язык он довольно сложный и «фичастый», но это не меняет того, что код на ней пишется легко и просто, а сложные задачи получается решать весьма продуктивно.

                                                                                            Примерно то же самое я могу сказать про Rust. Я следил за этим языком довольно долго, ещё с того времени, когда он был полностью рантаймовый и со встроенным GC (хотя от встроенных каналов уже успели отказаться), и мне тоже казалось, что он весьма странный и излишне переусложнённый, с его кучей видов указателей. Потом, когда он стал ближе к существующему виду, большую боль вызывала «война» с компилятором и его borrow checker'ом, писать работающий код получалось только с большим трудом. Но после того, как я попытался написать на нём достаточно существенный проект; после того, как поучаствовал в коммьюнити и изучил best practices; после того, как привык к его правилам и начал их применять уже практически неосознанно (и, соответственно, «война» с компилятором прекратилась полностью); после того, как экосистема языка стала достаточно развитой, и появилось множество библиотек и удобные способы работы с ними — после всего этого, что заняло, на самом деле, не так много времени (несколько месяцев привыкания и после этого около полугода до появления нормальной экосистемы и инструментов вроде cargo, а также относительной стабилизации языка), мне писать на Rust очень легко, и я могу решать с его помощью более сложные задачи весьма продуктивно.

                                                                                            Собственно, всё что я хотел сказать — да, язык определяет продуктивность программиста, который на нём пишет, но далеко не на полностью. Огромную роль также играет привычность к правилам языка, знание общепринятых best practices на нём, объём и качество коммьюнити, наличие экосистемы библиотек, наличие инструментов (например, менеджеров зависимостей и IDE). Исключать эти вещи, говоря про продуктивность, по меньшей мере недальновидно.
                                                                                            • +1
                                                                                              К этому хочу добавить, что, по моему мнению, хороший язык достаточно строг для того, чтобы своим синтаксисом/библиотекой направлять человека в сторону best practices, делая следование им проще и удобней, чем ортогональный им код.

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

                                                                                              Вот, например, PHP. Хороший пример языка, в котором долгие годы «лучшие практики» было проще не использовать, чем пытаться внедрять. Ну как пример — мне года три назад достался проект, написанный, по ощущениям, матёрым C-шником с функциями по 1500 строк и классами как неймспейсами для функций. Так вот даже PHP в последние годы продвинулся вперед настолько, что диву даешься. Спасибо composer, спасибо разработчикам, довевшим до ума ООП до актуального состояния вместо карго-культа 4 и 5.0 версий. И огромное спасибо разработчикам человеческих фреймворков на смену ZF, Symfony 1, Doctrine и прочему трешу.

                                                                                              • +1
                                                                                                И тем не менее, у языка есть _изначальные_ проблемы, которые каждый программист должен преодолевать over and over again. После версии 1.0 никакими позднейшими доработками это не исправишь. Как строковые функции в PHP, как работа со строками в пайтоне 3.х и т.п. Так что язык тоже определяет продуктивность.
                                                                                                • 0
                                                                                                  А что в пайтоне 3? Мне очень нравится, как там строки сделали, по сравнению с python 2.
                                                                                              • +2
                                                                                                Если под продуктивностью понимать способность решить задачу за минимальное время при помощи данной технологии, то не следует забывать, что решение задачи состоит из следующих фаз:
                                                                                                Архитектура
                                                                                                Прототипирование
                                                                                                Написание кода
                                                                                                Тестирование
                                                                                                Поддержка
                                                                                                Язык как таковой может оптимизировать фазу написания кода, однако не факт, что сопутствующая технология проявит себя так же хорошо в остальных фазах.

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

                                                                                                На сегодняшний день проблема Java как языка в отсутствии возможности семантического расширения, иначе говоря создания DSLей. Стандартное решение ввиде аннотированного кода плохо: из одних аннотаций невозможно создать семантически связанную струтуру. Альтернатива не лучше: использовать сторонний дескриптор XML, который хоть и связан семантически (XSD), но никак не связан с аннотируемым кодом.
                                                                                              • +4
                                                                                                Что-то я сомневаюсь, что Martin Odersky преследовал какие-то цели в духе «навредить, разрушить, сделать назло и т.д.». Человек просто экспериментировал и пытался создать хороший язык с кучей фич. И надо сказать ему это удалось. На Scala уже написано очень много всего, как либ/фрэймворков так и проектов. Если говорить о продуктивности, я сомневаюсь что Twitter решили переписать свою экосистему на непродуктивном и чересчур сложном языке…
                                                                                                На Nim пока не видно крупных проектов(ну или может быть я не в курсе). Время покажет насколько это «идеальный» язык…
                                                                                                • +2
                                                                                                  Сначала статья очень понравилась. Нашёл в себе злобствующего микроблогера, очень злобствующего… буду «лечиться». До хеш-таблиц с другой планеты не дошло, я не безнадёжен, слава Богу, но реально написал катастрофически мало рабочего кода, почти весь в теории, в планах, в поиске волшебной палочки, был. И вот за это — большое и искреннее спасибо. Люблю C#. Плохой код не люблю. Поэтому торможу с практикой. Но в итоге мог бы превратиться в совсем кошмарного микроблогера. А это гадостно.
                                                                                                  Но без ложки дёгтя не обойдётся. В какой-то момент мне показалась предвзятость к дженерикам. По-моему всё проще: «Не нравится — не ешь», а нравится и подходит если, то и хорошо. То есть раз уж ЯП инструмент, то разным инструментам и руки разные. Кто-то любит гонять до 100 за 5 секунд, а кто-то — ювелир. А кто-то пианист, а кто-то — шахтёр. И так далее…
                                                                                                  И вообще, некая антипатия к плюсам, корнями из тех самых девяностых, видимо. Есть же boost, есть Qt. Есть гора Линуксового кода, уже готового.
                                                                                                  Вот как-то так. И ещё раз спасибо. Большое.
                                                                                                  • +1
                                                                                                    Самая короткая дорога — та которую знаешь.
                                                                                                    Знаешь хорошо C++ и умеешь его использовать — быстрее и качественнее напишешь на C++.
                                                                                                    Знаешь хорошо Java и умеешь его использовать — быстрее и качественнее напишешь на Java
                                                                                                    и т.д…

                                                                                                    Думаю, что автор, утверждая:

                                                                                                    «Ну да ладно, вот и я как бы повелся, что надо бы писать на плюсах, наелся гавна (в том смысле что вместо того, чтобы программировать — думал за компилятор, скрещал библиотеки, и так далее). Слава богу у меня была производственная возможность плюнуть на все и переписать на Java»

                                                                                                    просто констатирует, что на тот момент не знал хорошо C++ и не умел его использовать (не знал тонкостей компилятора и подключения библиотек). Посему выбрал для себя самое верное решение — освоить что-нибудь попроще… и Java оказалась именно такой.

                                                                                                    Поэтому непререкаемый вывод:
                                                                                                    1. В работе используй только то — что хорошо знаешь и умеешь
                                                                                                    2. В свободное время — увеличивай новые знания и умения до уровня «хорошо», чтоб можно было использовать в п.1
                                                                                                    3. Если ничего не знаешь и не умеешь — ищи самое простое и быстрое, чему можешь научиться для решения поставленной задачи и переходи на п.2.

                                                                                                    Языки программирования и их ЭКО-среда — это как раз, то, что надо хорошо знать и уметь быстро использовать, если Вы отваживаетесь называть себя величественным словом «Программист» ;)
                                                                                                    • 0
                                                                                                      Но, согласитесь, коллега, в C++ есть проблема с подключением библиотек, не так ли? :)
                                                                                                      • 0
                                                                                                        Нету, есть biicode
                                                                                                        • +2
                                                                                                          Оно справляется с совместным включением в проект Qt5 и X11/Xlib.h без костылей?
                                                                                                          • 0
                                                                                                            Я думаю это возможно, поскольку biicode работает с cmake файлом. Однако это будет не тривиальным решением.
                                                                                                        • –2
                                                                                                          Если человек не знает, как подключить НУЖНЫЕ для решения задачи библиотеки — то конечно, проблема есть.
                                                                                                          Если человек знает — проблемы нет.
                                                                                                          Весь вопрос в том — обладает ли человек необходимыми знаниями? ;)

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

                                                                                                          Отсюда вывод:
                                                                                                          Если человек — это программист C++, то он по определению обладает этими знаниями и у него проблем нет.
                                                                                                          Если человек — это НЕ программист C++, то у него будут проблемы, пока он не получит нужных знаний и не станет программистом C++ :)

                                                                                                          Труд — делает из обезьяны человека.
                                                                                                          Знания — делают из человека программиста ;)
                                                                                                      • 0
                                                                                                        Посмотрел на ним, выглядит заманчиво, но по мне, так использовать его пока что рано.
                                                                                                        Язык программирования — это как валюта. Он живёт из-за авторитета создателей и использующих его. Как это можно сейчас серьёзно использовать, я пока не знаю. Зашёл на hh — 0 вакансий, 0 резюме. Зашёл на freelancer.com — тоже пусто. Версии 1.0 — нет. Официальной поддержки в какой-нибудь известной IDE — тоже нет.
                                                                                                        Автор, вы всерьёз утверждаете, что это идеальный язык?
                                                                                                        • +1
                                                                                                          Ну все с чего-то начинается. Когда я начинал изучать и использовать node.js, он считался крайне далеким от stable, редко используемым, экзотическим и т.п. Success story было крайне мало. Прошло несколько лет и теперь достаточно много заказчиков, которые хотят node.js и готовы платить приличные деньги. А у меня уже приличный опыт работы с ним, что замыкает цикл. В общем, поживем-увидим, что будет с Nim.
                                                                                                          • 0
                                                                                                            Согласен, с чего-то всё начинается. Я скорее удивляюсь тому, что автор променял java, и что там ещё был в прошлых статьях (говоря в общем — взрослые языки с уверенностью в будущем, готовые к использованию в продакшне) — на это, причём утверждалось это с таким негодованием, что я ждал чего-то фундаментального (хотя на самом деле не ждал). Я правда не понимаю, как такое бывает.
                                                                                                            Так — поиграться, посмотреть, поизучать, что это — не отрицаю, мне даже стало интересно, что за язык такой.
                                                                                                        • +2
                                                                                                          люблю такие статьи от души, благодарю
                                                                                                          • +2
                                                                                                            Хотелось бы узнать мнение автора о D, особенно в сравнения с Nim. Дело в том, что я тоже года два назад столкнулся с вопросом поиска идеального языка и для себя нашел D.
                                                                                                            • +1
                                                                                                              Насколько я понял мнение автора, если человек использует D, то он мудак
                                                                                                              • +1
                                                                                                                Разве автор не имел в виду мудаками тех, кто умышленно использует неизвестный язык программирования для собственной выгоды? Чтобы только этот «удак» и мог обслуживать код.
                                                                                                                • +2
                                                                                                                  Кстати, в таком контексте первые разработчики на Nim для всех остальных будут полными му… ами
                                                                                                                  • 0
                                                                                                                    Не обязательно, есть же не только на заказ проекты, а для души, и для себя, и для обучения. В общем, без злого умысла :)
                                                                                                              • +10
                                                                                                                Простите, но тут сплошной разброд и шатание, а не статья. Автор бегает вокруг, брюзжет на всё подряд, попутно не забывая показать свой многолетний опыт и навыки.

                                                                                                                Слово «продуктивность» упоминается чуть ли не в каждом предложении, в то время как качеству, надёжности и производительности почти не уделено внимание (типа, железо уже сильное, не парьтесь). Создаётся вполне определённое впечатление о том, какого рода код пишет автор и его команда. Это код, измеряемый строчками в секунду… Быстрее, больше, ещё больше!
                                                                                                                • +2
                                                                                                                  Естественно продуктивность будет в каждом предложении.
                                                                                                                  Видел я таких «продуктивных» разработчиков. Не один раз.
                                                                                                                  Из разряда «Я за три дня зафигарил проект».
                                                                                                                  Смотришь в код и видишь там 1 класс и 4 метода… на 9000 строк кода)
                                                                                                                  Но начальник (заказчик) просто ссыыт кипятком, какой крутой инженер, всем брать с него пример!
                                                                                                                  • +2
                                                                                                                    Справедливости ради — если проект не будет поддерживаться, то почему нет?
                                                                                                                    • +3
                                                                                                                      Если только ради справедливости.
                                                                                                                      Ибо мы все прекрасно знаем, что такие проекты единичны и на них не стоит делать общие выводы.

                                                                                                                      P.S. Если только вы не считаете игровой сервер для ммо социалки или систему документооборота для предприятия или аналогичные по сути проекты, не требующими поддержки.
                                                                                                                    • +1
                                                                                                                      Ха, я видел наоборот, когда на 100 строк необходимого кода восемь слоёв абстракции и два десятка интерфейсов, ещё в два раза больше классов, в каждом туча бесполезных методов. Если что-то надо добавить, то править приходится сквозь все восемь уровней абстракции.
                                                                                                                    • +1
                                                                                                                      Иногда в продуктивность вкладывают качество получающегося продукта. Если на выходе нет качества, о какой продуктивности может идти речь?
                                                                                                                      Это Архитекторы и Performance Гики могут после «продуктивной» работы деливерить тормозящие абстрактные фабрики для прошивки утюга и неподдерживаемые системы документооборота на ассемблере.
                                                                                                                    • 0
                                                                                                                      Спасибо за статью. Возможно, взгляд субъективный, но заряд, который заложен в этом порыве субъективности — это бомба. Зарядили на новые свершения.
                                                                                                                      На мой взгляд, мысли верные и применимы во всем. Двигатель внутреннего сгорания создавался автором вовсе не для того, чтобы им любовались, а для трех конкретных вещей: перестать мучать лошадей, в разы поднять производительность и как следствие — скорость, и третье — улучшить процессы, с этим связанные.
                                                                                                                      • +2
                                                                                                                        Сумбурное, эмоциональное и немного скомканное изложение трех тезисов в трех статьях:

                                                                                                                        1. Автору не нравятся динамические языки.

                                                                                                                        2. Автору нравятся стройные языки.

                                                                                                                        3. Автор нашел новую любовь, Nim.

                                                                                                                        :-) А вообще да, Nim ничего, конечно, приятный, особенно после Scala и, тем более, Java. Не боитесь, что Rust его задавит?
                                                                                                                        • 0
                                                                                                                          вот да, ничего не имею против того, что люди или я могу писать на ниме, но ощущается, как очередное выставление своего субъективного в объективного. ЯП — это скорее способы мышления в контексте разработки ПО. И привычнее полагать, что люди разные. Соответственно, инструменты разные, и для разных людей тот или иной инструмент может быть или удобен или нет. Я не имею ввиду нарушения логики, но скорее более «высокоуровненые» вещи. Все, как всегда, сводится к фразе: «На вкус и цвет фломастеры разные». Но в целом статьи неплохие. Человек изначально показал свои установки и ценности в данном контексте. Далее он просто перебирал языки и «примерял» их на себя. Как минимум бует полезно для программистов со схожими взглядами.
                                                                                                                        • 0
                                                                                                                          Так получилось, что прочитал все три части в один день, практически друг за другом. И постоянно в голове крутилась картинка, в которой автор читает свой текст, как монолог. Причем делает это очень нервно, эмоционально, порой сбивчиво, с большими паузами и ударениями, в стиле тарантиновских, наверное, персонажей.
                                                                                                                          Но в целом было интересно, спасибо, хоть автор и перл мимоходом обидел :)
                                                                                                                          • +1
                                                                                                                            Мне кажется что выбор ЯП имеет довольно опосредованное влияние на производительность программиста.
                                                                                                                            На первом месте все равно будут инструменты: это в первую очередь IDE, юнит-тесты, CI.
                                                                                                                            В этом смысле например swift или F# очень круты, так как позволяют сразу увидеть результат. Но это не столько заслуга языка, сколько его interpreter.

                                                                                                                            Например, в моём случае (.net) освоение решарпером удвоило мою производительность.
                                                                                                                            • 0
                                                                                                                              Вдвое? Ох, любят люди громкие слова :)
                                                                                                                              • 0
                                                                                                                                «Как я увеличила свой бюст на три дюйма»
                                                                                                                                • 0
                                                                                                                                  Человек фактически открыл для себя рефакторинг. Немудрено. Могло и больше, чем удвоить.
                                                                                                                                  • –2
                                                                                                                                    Подозреваю, дело было не в умении реструктурировать или чистить код… :-)
                                                                                                                                    • –1
                                                                                                                                      А в чём? Хотя, по моему опыту, умение писать быстрее, писать лучше и постоянно поддерживать код в хорошем состоянии вырабатывается довольно быстро при освоении средств автоматизированного рефакторинга.
                                                                                                                                      • +1
                                                                                                                                        Мне просто интересно стало, почему вдруг необходимость поддерживать код в адекватном состоянии стала связана с доступностью того или иного вспомогательного инструмента.

                                                                                                                                        Это я к связи фраз «человек фактически открыл для себя рефакторинг» и «освоение решарпера».
                                                                                                                                        • +1
                                                                                                                                          Насколько я понял, именно о «необходимости» речи не шло, только о способности — про необходимость освоения решарпера или повышения производительности в исходном комментарии написано не было. Была бы необходимость — сразу бы специально объяснили или приняли бы другие меры. А тут — просто человек вдруг узнал, что чистый код можно писать довольно легко и не отходя от практики «скачала пиши код, потом 'причёсывай' его». Имея возможность легко улучшать дизайн кода после его написания, человек поупражнялся и в дизайне кода самом по себе и приобрёл навыки написания более чистого когда сразу, «с листа».
                                                                                                                                • 0
                                                                                                                                  А расскажите, пожалуйста, что сейчас в решарпере вы используете? А то я внезапно отказался от решарпера полгода назад по причинам плохой производительности компьютера и до сих у меня есть только две основные проблемы: инжект зависимостей через конструктор и выделение класса в новый файл (но на это есть легковесный плагин). Раньше без него жизнь не мыслил, а сейчас не могу вспомнить, что ж там такое офигенное было.
                                                                                                                                • –3
                                                                                                                                  Исходя из теоремы Гёделя о неполноте, можно заключить, что не существует языка программирования крутость (эффективность, красивость, элитарность… нужное подчеркнуть) которого можно доказать только исходя из анализа фич, синтаксиса и чего угодно еще только лишь этого языка. Крутость языка начинает иметь смыслы только с введением внешней системы, то есть с добавлением программиста. Следовательно, для разных пар «язык — программист» доказано будет крутость разных языков. Так о чем спор? ;)
                                                                                                                                  • 0
                                                                                                                                    Ну не знаю.
                                                                                                                                    Меня C++ вполне устраивает.
                                                                                                                                    Ведь для него же есть Qt! Значит 3-30 кнопок я — одним махом!) С любой логикой)
                                                                                                                                    Плюс огромная потенциальная мощь, которую я пользую 10%, но она есть!
                                                                                                                                    Да GC нет, но он мне как то и не особо нужен, к тому же есть умные указатели, к тому же есть вроде как фреймворки с GC на борту. К тому же GC в плюсы грядет в 17 стандарте (или выше).

                                                                                                                                    Не хочу я перескакивать на др. язык, тем более что 90% библиотек, фреймворков и т.д. написаны либо на C либо на плюсах.
                                                                                                                                    • 0
                                                                                                                                      В чём преимущество GC перед RAII со смарт-поинтерами? C++11/14 — уже всё, если забыть про raw pointers, то утечек быть не должно (только вместе с мозгом быдлокодера).
                                                                                                                                      • 0
                                                                                                                                        GC разрешает проблему циклических ссылок.
                                                                                                                                        Реализовано примерно так:
                                                                                                                                        В отдельном потоке крутится в цикле со спячками или без некий код, который проходит по графу зависимостей «ссылка-объект-ссылка» пытаясь найти те объекты, до которых он не может добраться.
                                                                                                                                        Ну например, есть объект A, который держит объект B, который держит объект C, который держит объект B. Удаляем B из A (закончилась область действия A) — GC декрементирует счетчик и если счетчик не станет нулем, попытается в отдельном потоке добраться из корня графа до B, если не сможет или такого корня нет, то удалит B, а затем и C.
                                                                                                                                        Как то так.
                                                                                                                                        Политик управления можно множество придумать.

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

                                                                                                                                        Хочешь, подключай инклуд и пользуйся, хочешь подключай инклуд — не пользуйся этими смартами, — GC будет просто спать.
                                                                                                                                        • 0
                                                                                                                                          std::weak_ptr тоже решает проблему циклических ссылок.
                                                                                                                                        • +1
                                                                                                                                          У смарт-поинтеров, реализованных подсчётом ссылок, низкая производительность (при передаче указателя куда-то нужно делать запись в объект, увеличивая число ссылок), для многопоточных систем использовать блокирующий Interlocked*

                                                                                                                                          GC разбирает циклические ссылки, которые в случае со смарт-поинтерами надо делать указателями разных типов.
                                                                                                                                          В этом случае надо понимать, кто чем владеет и использовать правильные типы. То есть, есть шанс ошибиться, когда в языках с gc можно вообще эти тонкости не держать в голове.
                                                                                                                                          • 0
                                                                                                                                            Подождите. Да, подсчёт ссылок накладывает какой-то overhead. Не будем спорить, какого его влияние. Но очевидно же, что GC всегда и во всех языках будет гораздо дороже, чем refcounting, я правильно мыслю?

                                                                                                                                            (Про многопоточность: управляющий блок shared_ptr'а потокобезопасен, основан на атомиках.)
                                                                                                                                            • +1
                                                                                                                                              Но очевидно же, что GC всегда и во всех языках будет гораздо дороже, чем refcounting

                                                                                                                                              Мне не очевидно. Наверняка есть ситуации, когда памяти хватает и до сборки мусора дело просто не дойдёт.
                                                                                                                                              Кроме того, malloc/free вызываются часто и понемногу, а gc работает «оптом»

                                                                                                                                              управляющий блок shared_ptr'а потокобезопасен, основан на атомиках

                                                                                                                                              И это плохо, потому что atomic, или же interlocked-операции, медленные (см. «главный злодей» тут). Если известно, что некоторые объекты не участвуют в конкурентном доступе, стандартный shared_ptr для них не оптимален.