Как я нашел лучший в мире язык программирования. Часть Йо (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 (далеко не в первых рядах), в то время когда экосистемы была м
