Тем кто изначально отнесся скептически, хочу сказать, что я не собирался и не собираюсь агитировать кого-либо за тот или иной язык. Написал же я просто с одной искренней целью: поделится радостью открытия. Когда прёт (а с возрастом прёт все реже и реже, тем более от такой, вроде, мелочи по жизни, как язык программирования) хочется поделится. Вот такое вот редкое и детское желание: ребята, смотрите как круто! Тем более что я действительно ждал, искал, и переживал из-за вопроса долгие годы, и ответ от него не был мне очевиден, хоть я и не раз проходил мимо.
Я очень благодарен вам всем, и просто обязан (хотя бы перед частью думающей и чего-то желающей молодежи) закончить статью, и может в их головах появится больше полезных мыслей, а дерьма в эти головы в любом случае накидает жизнь и интернет. Поэтому я продолжу в скучную, не техническую сторону, мне кажется неправильным продолжать, не задав дискурс:
Язык программирования — зачем?
Все согласятся с тем, что язык программирования — инструмент, средство выражения мысли (если мысль, конечно, есть). Поскольку мысли можно выражать по разному поводу, я уточню что выражать мысли мне, как правило, интересно интересен только для решения поставленных задач. Инструмент, с помощью которого создают программное обеспечение. В таком случае единственное логичное требование которое можно, и нужно, предъявлять к языку программирования — это увеличение производительности программиста здесь и сейчас. В краткосрочной, среднесрочной, и долгосрочной перспективе.
Множество языков общего назначения одинаково применимо к большинству задач (поэтому из и называют общего назначения), и я не буду рассматривать случаи когда язык однозначно заточен на решение поставленной задачи. В этих случаях все более менее понятно, а если и возникают споры, то они более предметны. Интересен же наиболее частый случай — когда задача вполне нормально решается на десятках языков (а это как раз обычная ситуация). Ну вот например в вопросе: что выбрать для сервера из списка 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 секунд? Это прекрасно — чувствовать всю мощь железных технологий под капотом, мощь, которой вы управляете по собственному желанию, и вся эта мощь делает то, что вы хотите, и так как вы хотите. А еще это называется свобода.
Пока,
Платов
Комментарии (233)
sferrka
12.06.2015 20:28+8Языки и технологии дают вам конкурентное преимущество, а если вы сидите на тех же самых языках и технологиях, что и половина программистов вокруг — о каком технологическом преимуществе может идти речь?
В таком случае, как объяснить ваше желание рассказать всем о «дешевых акциях» — переизбыток чувств, глупость или скрытые мотивы (пропихнуть всем ложное направление, а самому купить реальные акции :-)?
platoff Автор
12.06.2015 20:44Сразу видно, что на бирже вам делать нечего :) надо быть проще и честнее и тогда все будет. Я уже в дешевых акциях и получаю дивиденды. Если акция хорошая — она будет расти, со мной или без меня. И это хорошо для меня. Рост долгий, и если люди туда заходят быстро, то хорошо, заходят долго — тоже неплохо
sferrka
12.06.2015 21:09Если вы успели купить достаточное количество акций, значит они уже не такие дешевые) Видимо, о количестве ваших строк кода на Nim будет в третьей части, ждемс…
fshp
12.06.2015 20:53+14Во всем интернете нет ни строчки его кода, разве что портированные чужие либы с чего-нибудь на Haskell, или с PHP на Perl.
Мне кажется, я знаю о ком идёт речь…
bolk
13.06.2015 12:47+8Интрига! О ком? )
fshp
13.06.2015 22:15+1Так, что бы не надумали там себе всего.
Я имел ввиду уважаемого afiskon.
Я ничуть не сомневаюсь в его профессионализме и никоим образом не хочу его обидеть. Но его посты в блоге и темы подкаста очень напоминают описание из статьи.
afiskon
13.06.2015 22:51Я когда читал у меня самого возникло чувство, что речь обо мне. Но на самом деле не сходится. Я на Perl за деньги писал три года назад и тогда подкаста не было, о блоге никто не слышал, да и ФП, насколько помню, я вроде бы не особо расхваливал, сам только разбирался во всем. Есть подозрения, что образ, описанный господином platoff является собирательным. Или нет? ;)
qnikst
12.06.2015 21:31+12С такими характеристиками стоит на zadolba.li писать, а истории про себя правильного на ithappens. А этот сайт ведь когда-то чисто техническим считался, где хорошим тоном было писать статьи без ложных предпосылок, не забывая четкие аргументы, а при сравнения объективно рассматривать обе стороны в рамках своего понимания.
bolk
13.06.2015 12:48+19Ну слушайте, что аргументов нет — заметно, но язык-то, язык! Большое удовольствие читать. «Хабр» и так уже стал невыносимо пресным, просто тошно.
SerafimArts
12.06.2015 21:32+21Кстати, на моей памяти есть один язык, который действительно создавался с целью упростить жизнь программистам и сделать их более эффективными. И этот язык, как бы не забавно это прозвучало — PHP, как можно заметить, судя по статистике — с задачей он своей справляется «на ура».
platoff Автор
12.06.2015 21:55+6Не только PHP. Один из первых — Forth. Автор Чак Мур искал продуктивности всю жизнь и так появился и эволюционировал его язык. История тут www.colorforth.com/HOPL.html а вообще да, PHP правильная вещь
SerafimArts
12.06.2015 21:56+3Увы, историю форта, в отличие от сабжевого я не знаю. Надо будет почитать, спасибо.
evnuh
12.06.2015 21:36+8Вы 10 лет пробовали все языки, но, если я правильно понял, С++ то вы так и не пробовали? Почему? «Пробовали» в смысле реальном, чтобы себя назвать С++ программистом. Или всё же было?
Поэтому мне удивительно, вы тут пишете про скорость, про мощь и рюшечки, а до этого заключили, что на скорость то вам и пофиг, вы же IDE пишете.
И снова, уповаете за продуктивность, чтобы просто и понятно, легко, всё было доступно, а выбрали Nim. У него хоть инфраструктура есть какая-нибудь? XML-ку там распарсить, с ОС как-нибудь удобно поработать?
Это всё я к тому, что на С++ можно писать очень быстро и продуктивно, не забираясь в дебри шаблонов, аллокаторов и т.д. даже в огромных программах. Особенно учитывая с++11 и его модель памяти.
А вообще, методология ваша хороша, и задачу вы себе поставили хорошую, но, боюсь, нерешаемую. Хоть вам и кажется, что вы нашли грааль)
0serg
13.06.2015 00:37+6Ну С++ бывает разный. Это сейчас C++11 удобен и крут и есть много примеров хорошего кода на которых можно учиться, а в 90-х годах «писать на плюсах» подразумевало как правило что-то типа архиуебищного MFC, причем нормальных компиляторов у плюсов не было, и баги когда компилятор генерировал неверный код из верной программы не были чем-то из ряда вон выходящим
Поэтому говоря о плюсах многие понимают под этим разные вещи. Особенно если начинать на плюсах доводилось в 90-х :)
rg_software
13.06.2015 07:07Я писал под платформы Borland (C++ 3.1, а затем линейка Builder) — всё было вполне ОК, уж точно, не хуже, чем сейчас.
А с MSVC было страдание, да, но никто ж не заставлял.0serg
13.06.2015 09:45Borland был весьма неплох, сам писал в бытность студентом, но имхо коммерческих проектов на нем было очень мало
Так что коммерческий софт заставлял страдать с MSVC
7voprosov
12.06.2015 22:05+1А как находка такого замечательного языка отразится на вашей конторе (хотя бы в общих чертах), особенно учитывая(на сколько я знаю), что основные продукты/заказы вы делаете на jvm-based языках (java/fantom/scala)?
platoff Автор
12.06.2015 22:43+2ровно так, как находка Java и eclipse отразилась на конторе во времена когда про eclipse мало кто знал. А eclipse foundation еще не был создан. Прекрасно отразится. Есть компании-конъюнктурщики. Как и программисты конъюнктурщики. Они подстраиваются под рынок. Есть те которые сами понимают что хорошо, а что плохо, и идут впереди рынка.
pjBooms
12.06.2015 22:07+10Очень понравились рассуждения про набор языковых фич и экосистему.
Однако, считаю, что следующая «большая вещь» будет вообще не вокруг языка. Те же (очень хорошие) примеры из этой статьи про Delphi и Java подтверждают этот тезис. И Delphi и Java — не были просто новыми языками. В тот момент когда они еще не имели экосистемы, они уже были гораздо больше платформами, чем языками. А язык был вторичен. И действительно, если продумать базис, платформу, то можно на нее хоть LISP натянуть, добавив больше или меньше фич. Та же Java — это, по-большому счету, упомянутый ранее Оберон с синтаксисом C, чья платформа была продумана на качественно новом уровне (но и сам Оберон как язык без Оберон-системы абсолютно бессмысленно рассматривать).
Жду рассказ про Nim и надеюсь, что в рассказе будет поднята также тема Nim как платформы, а не очередного языка, коих сейчас плодятся миллионами аж глаза разбегаются. Новых же платформ за последнии 10 лет, по большому счету, не появилось ни одной (или я не туда смотрю).
Идея же наслоится на существующие платформы (и для «браузера» и для «железа») мне кажется — не жилец.
leventov
13.06.2015 05:05+2Если немного отойти от понятия вычислительной платформы, то можно много чего разглядеть… Например cloud-платформы типа гугловой, микрософтовской, амазоновской.
Еще есть платформа программирования под Эппл, далвик со своим байткодом
andyN
12.06.2015 22:21+7Так забавно читать, как автор смело лепит ярлыки а ля «мудак» на человека, который действует абсолютно правильно в его личной системе ценностей… Вроде бы взрослый человек, а категоричность как у 18-летнего юнца. Просто задумайтесь на секунду, что другие люди не лучше и не хуже — они просто другие. То же самое касается и языков программирования. И мир засияет новыми красками, девушки станут Вам чаще улыбаться, мужики будут чаще здороваться, Java перестанет быть прожорливой, а C перестанет быть средством для изощренного самоубийства.
Kroid
12.06.2015 23:05+6А еще более забавно читать о том, как кто-то смеётся над двухцветной точкой зрения, заменяя её одноцветной. Это же классическая дилемма заключенного. Пока «мудак» один, он в выигрыше, но целое общество таких людей погребет само себя в пучину отчаяния.
7voprosov
12.06.2015 23:15+7Для взрослого человека (думаю и не только для взрослого) естественно иметь морально-этические принципы и делать некоторую градацию людей на их основе.
То, что сознательное завязывание проекта лично на себя, есть поступок сомнительный с этичной стороны дела, думаю согласятся многие.
P.S Люди, которые говорят что нет хорошего/плохого/правильного/не правильного/ (в рамках разумного контекста разумеется) мне всегда казались несколько странными.
Kane
12.06.2015 23:40+3Вот именно! Как будто есть что-то плохое в том, чтобы работать на не самом популярном языке, чтобы получать больше денег и иметь меньше конкуренции. Не стоит забывать, что у это есть и обратная сторона — делая ставку на не самый популярный язык, программист берёт на себя риски.
nomit
13.06.2015 08:14+2Ну смотрите вы заказчик, наняли команду условных программистов. Они вам запилили за N время базу для проекта, вроде все работает. как надо. Запилили они на каком то малоизвестном языке(вы как заказчик можете и не разбираться популярный он, удобны и т.п.). Тут вам захотелось добавить функционала в систему. Простите команду добавить простую фичу, а это добавление занимает архи много времени.(Повторить предложение N раз) Вы понимаете что не может столько времени заниматься добавление такой фичи. Или команда начинает просить немыслимую сумму на поддержку. Далее можно вставить любую проблему из-за которой вы не хотите работать с этой командой программистов. Решаете найти другую команду, а таких команд либо нет, либо совсем мало и не кто не хочет браться за ваш проект.(Причина возможно цена, или команда сильно занята и не готова уделять нужное кол-во времени проекту).
Вот как назвать людей из первой команды? Конечно мудаки. Я думаю вот именно о таких людях автор говорит.
solver
13.06.2015 16:40+6Так автор же сам из этой же группы.
Он выбрал язык, на котром пишет, во всем мире, хорошо если несколько сотен человек.
Что делать его клиентам?
Он заставит своих сотрудников изучтать… вернее покупать акции неизвестной компании.
Которая, как ему кажется, вырастет в цене.
А люди будут покупать эти акции за самый дорогой ресурс в мире, за свое собственное время.
Сколько там игроков на бирже сливается в пух и прах?
Вот такой же процент людей, в его конторе, пойдет по миру с этими акциями.
stepik777
12.06.2015 22:21+6Продуктивность вовсе не единственный критерий. Есть ещё, например, безопасность. Если язык гарантирует, что в написанной программе не будет целого класса уязвимостей, то это большой плюс.
zharikovpro
13.06.2015 18:22+2> Если язык гарантирует, что в написанной программе не будет целого класса уязвимостей, то это большой плюс.
Это также означает, что этот язык продуктивнее других с точки зрения написания менее уязвимых программ. Просто какие-то языки продуктивнее в этом разрезе, какие-то в другом. В итоге все сведется к человеко-часам на разработку продукта в целом. Поэтому общая продуктивность процесса разработки главный критерий. Так же как и в бизнесе ROI.
stas3k
12.06.2015 23:01Глянул на Nim. Похож на Python по синтаксису. Будет теперь альтернатива для питона только на компиляторе уже. :)
Dimchansky
13.06.2015 01:37А мне почему-то на Pascal больше похож, хотя от Python он отступы взял конечно.
veveve
13.06.2015 07:22Для Питона тоже есть компиляторы, если что.
Просто Питон по другому пути идёт.
mnemosha
12.06.2015 23:22+4Статья категорически не понравилась, слишком много пафоса. Но идея, которую автор хочет донести, возможно стоящая.
dyadyaSerezha
16.06.2015 20:47+2«слишком много пафоса» — слишком много букв. Такое ощущение, что автор хряпнул кружечек 6-8 пива, а потом стал писать статью в невыносимом желании попи@деть. :) Все можно было выразить раз в 5 короче и яснее.
zharikovpro
12.06.2015 23:40Очень интересно узнать ваше мнение про Ruby. На данный момент он к сожалению практически не пригоден для написания десктоп-приложений с GUI, но для web приложений работает очень хорошо. Консольные утилиты писать тоже неплохо. Что примечательно — как раз создавался с идеей быть выразительным, легким и приятным в использовании, продуктивным с точки зрения быстроты написания кода.
platoff Автор
12.06.2015 23:51+15Языки с динамической типизацией дают какой-то положительный эффект в смысле продуктивности на старте, но очень быстро (с ростом размеров проекта) этот эффект проходит и обращается в проблемы. Большой проект на таком языке (включая Ruby) требует больше усилий на написание тестов, а программисту приходится помнить гораздо больше вещей, типа объекты какого типа принимает тот или иной метод. В общем для маленьких и быстрых проектов, типа консольных утилит, для прототипов и небольших веб-приложений, в качестве скриптового языка внутри некоей большой системы — да, Ruby и его коллеги очень хороший выбор. Для больших систем, я бы Ruby не брал.
extempl
13.06.2015 08:43+3Допустим, держать в голове нужно больше. А если вдруг, у вас есть дурацкая привычка комментировать методы с указанием типов принимаемых/возвращаемых аргументов и ваша любимая ИДЕ подсказывает если вы передаёте неправильный тип или на стадии вызова метода с помощью хоткея говорит, какой тип нужно передать? Тогда мы и производительность получаем от динамической типизации и от проблем «незнания» уходим. Да, компилятор/интерпретатор не сломается из-за неправильного типа, но это уже нужно рассматривать подходы к программированию, а не, опять же, языки.
qw1
13.06.2015 09:21А если вдруг, у вас есть дурацкая привычка комментировать методы с указанием типов принимаемых/возвращаемых аргументов и ваша любимая ИДЕ подсказывает
Это какой-то костыль… Хороший язык должен уметь, для некоторых особых случаях, динамическую типизацию, и статическую во всех прочих.
В принципе, на java можно эмулировать, передавая везде object.
А в c# 4.0 так вообще завели тип dynamic, который мало того, что хранит что угодно, так ещё и диспетчеризирует в подходящую ф-цию при вызове.
Скрытый текстvoid test(dynamic a) { Run(a); } void Run(int z) { ... } void Run(string s) { ... }
BlessMaster
13.06.2015 19:29+2Не знаю, как на Ruby, но на том же Python местами приходится «комментировать» код нездоровым количеством ассертов, которые перегружают реализацию, выполняется двойная и тройная работа, продуктивность серьёзно проседает. Да, гибкость, за которую многое можно отдать. Но в крупном проекте — сложность растёт в итоге не только от сложности самого проекта и цена выходит за всякие разумные рамки, так что даже IDE тебя начинает посылать, приходится от «гибкости» отказываться везде, где действительно можно обойтись без неё — приходит просветление и трансцендентное осознание концепции KISS.
Mixim333
13.06.2015 11:02>В общем для маленьких и быстрых проектов, типа консольных утилит, для прототипов и небольших веб-приложений, в качестве скриптового языка внутри некоей большой системы — да, Ruby и его коллеги очень хороший выбор.
Что Вы подразумеваете под «консольными утилитами»? Сам использую C#, но лично у меня логика реализации GUI-приложений следующая: создаю солюшен, в него добавляю консольное приложение и библиотеку; тут же в консольном приложении делаю ссылку на эту библиотеку; создаю в библиотеке классы, тут же их отлаживаю из консоли, а затем, когда все отлажено и проверено, создаю «GUI-клиента» к этой библиотеке с кнопочками и рюшечками — так и код библиотеки читать проще и обертки над графическим интерфейсом не путаются с функциональным кодом.
lega
13.06.2015 21:54-5а программисту приходится помнить гораздо больше вещей, типа объекты какого типа принимает тот или иной метод.
Это домыслы разработчиков статической типизации, на практике (конкретно в Питоне) проблем обычно не возникает, даже если залезть в чужой проект.
Даже если вы знаете какой тип передавать (со стат. типизацией), это не всегда поможет.
mjr27
12.06.2015 23:54+7В принципе, у меня достаточно однозначный принцип определения субъективного «качества» языка — это тот же code quality measurement, что и для качества кода
XKCD, если кто не знает
overmes
13.06.2015 02:49Есть мнение, что Rust более строгий и дисциплинированный чем Nim:
habrahabr.ru/post/259993BlessMaster
13.06.2015 19:42+8Фишка Rust в том, что он выносит приличную долю ловли блох на этап компиляции, а не отладки. У кого-то это создаёт впечатление сложности самого языка, который тяжело заставить собрать программу. Но на практике это означает лишь то, что программист, мнящий, что он ЗНАЕТ все входы и выходы в своей программе, на самом деле тешит себя в иллюзиями и будет собирать эти грабли чуть позже на этапе закрытия тяжелоуловимых багов, возможно вместо выходных, поскольку упало именно на продакшене и закрыть период нужно было ещё вчера.
Что ж, я так понимаю, в ближайшее время мы будем наблюдать захватывающий этап становления нескольких достойных языков, каждый из которых предлагает свой компромисс между простотой и дисциплиной и каждый по своему нацеленных на продуктивность.
serf
12.06.2015 23:58+8Что я понял из статьи, пока хипстеры и всякая школота занимаются своими хипстерскими делами настоящие инженеры ипошат код не шурша.
А если серьезно очень интерсно было почитать рассужедния опытного инженера, благодраю.
jlbyrey
13.06.2015 00:05+3Бесполезный tl;dr про кодорелигию.
platoff Автор
13.06.2015 00:13+2Как раз наоборот, про материалистический атеизм
jlbyrey
13.06.2015 00:52+8Программирование — это решение задач на языке программирования. Критерии могут применяться только к двум вещам — задачам и решениям. Все остальное вам показалось.
mjr27
13.06.2015 00:59-4Программирование, как и любая работа, это по большей части неприятное времяпровождение, за которое платят деньги.
К степени «неприятности» критерии тоже могут применяться.
MaximChistov
13.06.2015 11:40+5>это по большей части неприятное времяпровождение
Только у тех, кто туда шел ради денег, а не потому что нравится процесс в первую очередь )mjr27
13.06.2015 12:32-4Ну не знаю, как показывает мой небольшой опыт, если моя работа мне в радость, то либо я работаю спустя рукава, либо я делаю совсем не то, что нужно заказчику, либо заказчик я сам.
В обычном режим работы — нужно качественно, вчера, и соответствовать вон тому взаимоисключающему списку требований от маркетолога — чувство «приятного времяпровождения» обычно значит, что ты занимаешьсяхернейсамообразованием вместо работы.MaximChistov
13.06.2015 12:51+3Всегда можно найти такую работу, где не придется ненавидеть начальство и делать что-то интересное, вопрос лишь в Вашем желании что-то менять, а не сидеть на пригретом месте без преспектив годами)
mjr27
13.06.2015 14:12-1Спасибо за совет, но я и есть начальство. А любая интересная работа это 95% рутины, по другому результата не достичь. И «сидеть на одном месте без перспектив годами» — настоящая работа делается именно так, что бы там ни писали вышеупомянутые микроблоггеры.
MaximChistov
14.06.2015 10:37+1я и есть начальство
В обычном режим работы — нужно качественно, вчера, и соответствовать вон тому взаимоисключающему списку требований от маркетолога
Весло вам, чо )
robert_ayrapetyan
13.06.2015 00:12+19Отлично, оказывается мир программистов делится на три категори: мудаки, микроблогерры и «прочие заболевания». При этом автор относит себя ко всем трем одновременно… Весьма недурно.
Что до «лучшего языка» с «иконкой как у миранды» и недоросшим даже до пресловутой версии 1.0 — лет через 10 будет хоть что-то по нему ясно наверняка, пока нужно быть полным «микроблоггером», чтоб на него пересесть.solver
13.06.2015 16:46+1Необязательно микроблогером.
Первая категория тоже отлично вписывается в выбор)
kvark
13.06.2015 17:24+3Про 10 лет, Вы, конечно, преувеличили. Но вот «прямо сейчас», о чём так настойчиво говорит автор, ехать на этом феррари как-то рискованно, учитывая, что двигатель и колёса могут ещё пару раз заменить прямо на ходу.
mnemosha
13.06.2015 00:26+1Автор, так если вы так одержимы идеей идеального языка программирования, почему вы не создали свой?
mjr27
13.06.2015 00:30Помимо картинки про 19 стандартов — это еще большая ответственность, и куча потраченного времени и денег, именно в таком порядке.
7voprosov
13.06.2015 00:37+2Думаю он просто не достаточно умен для этого.
Ну правда же звучит глупо — «Я знаю как создать идеальный язык, но я боюсь ответственности и мне жалко времени и денег»platoff Автор
13.06.2015 00:52+7- Автор статьи действительно не знает, каким должен быть идеальный язык программирования, он знает лишь для чего ему язык, и как он отличает плохой язык от хорошего. Поэтому автор в статьях пишет, что он искал язык
- Как человек который делал продукты, которым пользуются другие люди я прекрасно понимаю mjr27, имеется ввиду что создав язык вы берете на себя ответственность его поддерживать, развивать, общаться с пользователями, учить и так далее. Вы будуте ответственны перед людьми, которые в вас поверили и положились на ваш продукт. И это помимо времени (и денег) которых действительно жалко. Время в жизни ограниченно и у меня есть много более приоритетных хотелок. Не знаю зачем я вам ответил, вы очевидно даже близко не оказывались в таких ситуациях, когда люди боятся ответственности, и жалеют время
7voprosov
13.06.2015 01:27+2Почему это не оказывался? Оказывался. Просто по характеру ваших сообщений мне показалось, что если бы вы были уверены, что знаете как сделать идеальный язык — вы бы этих вещей не пожалели.
В конце концов вы писали про 20 лет занятием программирования за деньги, и на сколько я мог понять этот способ заработка вам вполне нравится (с точки зрения получения удовольствия от работы).
Mixim333
13.06.2015 11:13+1ИМХО, «идеального языка» просто не существует и никогда не появится в природе! Невозможно сделать «молоток», который будет и «гвозди забивать» и выдавать звуки как «скрипка Страдивари».
Не люблю использовать академические цитаты, но по-моему у Макконела в Совершенном коде было что-то вроде: «Для программиста не важен язык программирования, он должен видеть архитектуру алгоритма!»
Alexufo
13.06.2015 00:52+1А еще это называется свобода.
Нет, сэр, это ваша зависимость, а не свобода)
rboots
13.06.2015 01:40+6Судя по обилию негатива в статье автор явно на кого-то обижен. Бывает, не с теми людими работал.
У меня другая ситуация по сложности понимания кода — коллеги не успевают за уровнями абстракции, так как им лень учиться, и поэтому считают мой код сложным, хотя продуктивность зашкаливает. Редкие языки/паттерны выбираются, всё же, чаще не для того, чтобы кого-то ввести в заблуждение, а чтобы решить задачу естественно и подходящими для неё средствами. Точно так же, как хороший писатель обладает большим словарным запасом, Войну и мир не описать в 1000 слов. Если у читателя словарный запас меньше — значит нужно тянуться вверх, а не ныть.
mrjj
13.06.2015 02:22+8> С одной стороны все выглядет красиво, качественно, я бы сказал восхитительно, с другой стороны — вот тут же можно было переиспользовать, и тут, и тут, вот тут вообще чуваки сознательно копи-пастят.
Ничего страшного, у начинающего программиста половина кода это быдлокопипаста. А почему? Потому что она ему понятна и понятно как ее делать и править, он не пытается казаться умнее чем он есть.
У зрелого программиста все высушено до предела.
У настоящего профессионала копипаста — это инструмент со своими плюсами и ограничениями без предвзятого отношения. Он понимает что преждевременный DRY — это преждевременная оптимизация, он дает дублирующимся кускам отстояться, вдруг они все-таки разъедутся при дальнейших изменениях и умеет определять места с такими рисками, чтобы, например не разгребать потом деревья из классов, в каждом из которых поменялось по строчке в каждом из методов. А какая мякотка какие ни будь корневые классы в приложении, на которые просто стараются не дышать, так как никто не сможет предсказать последствия по всему дереву наследования.
Или есть два продукта, из них кусок кода был вынесен в либу с низкой сцепленностью того что она делает, просто чтобы код не дублировать. Для одного из продуктов возникла необходимость в либе кое-что поправить. Сколько продуктов при этом нужно будет тестировать, один или два?
Основная задача программиста — снижать сложность, если избавление от копипасты сложность увеличивает, а поддерживаемость уменьшает, то, возможно, оно не нужно.kvark
13.06.2015 17:20+1Так… автор же об этом и пишет в последующем абзаце:
то для людей создающих платформу, на которой предполагается одновременный запуск сотен плагинов, различных версий и от десятка не знающих друг о друге вендоров любая лишняя зависимость — зло
autobusiness
13.06.2015 03:26-1Сколько надо бухнуть чтобы все это с комментариями дочитать до конца?))Пойду…
Foxcool
13.06.2015 10:25-5Ты мне все больше нравился до этой статьи (:
А тут ненаязчиво наехал на перл.
А если по делу, стоит еще не забывать, что многие выпускники или студенты, приходящие в конторы, заражаются говнецом в тех же вузах. А проблема всегда одна и та же — подверженность авторитетам. Он всегда найдет, как утенок, за кем топать.
Вот раньше была трава зеленеее были хакерские форумы, где интересующаяся молодежь попадала в гностический рай: куча молодых и не очень людей, объединяющихся в свободное сообщество любящих получать знания. Обменивающиеся информацией, пишущие статью и о программировании, администрировании, взломе и т.д. На таком огромном объеме разнородной информации и формировались собственные вкусы, выборы языка, профессиональное мировоззрение. Плюсом прививались полезные вещи вроде стремления писать качественный код, безопасные инструменты, применять и создавать свободные решения. Конечно, бизнесу нет особой потребности в хакерах, поэтому нынче есть ит-спецухи в вузах и хабрахабр (:
Googolplex
13.06.2015 10:57+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). Исключать эти вещи, говоря про продуктивность, по меньшей мере недальновидно.mjr27
13.06.2015 11:36+1К этому хочу добавить, что, по моему мнению, хороший язык достаточно строг для того, чтобы своим синтаксисом/библиотекой направлять человека в сторону best practices, делая следование им проще и удобней, чем ортогональный им код.
И под языком я сейчас имею совокупность самого языка, инфраструктуры и библиотек.
Вот, например, PHP. Хороший пример языка, в котором долгие годы «лучшие практики» было проще не использовать, чем пытаться внедрять. Ну как пример — мне года три назад достался проект, написанный, по ощущениям, матёрым C-шником с функциями по 1500 строк и классами как неймспейсами для функций. Так вот даже PHP в последние годы продвинулся вперед настолько, что диву даешься. Спасибо composer, спасибо разработчикам, довевшим до ума ООП до актуального состояния вместо карго-культа 4 и 5.0 версий. И огромное спасибо разработчикам человеческих фреймворков на смену ZF, Symfony 1, Doctrine и прочему трешу.
mjr27
13.06.2015 11:39+1И тем не менее, у языка есть _изначальные_ проблемы, которые каждый программист должен преодолевать over and over again. После версии 1.0 никакими позднейшими доработками это не исправишь. Как строковые функции в PHP, как работа со строками в пайтоне 3.х и т.п. Так что язык тоже определяет продуктивность.
itforge
13.06.2015 12:07А что в пайтоне 3? Мне очень нравится, как там строки сделали, по сравнению с python 2.
mjr27
13.06.2015 12:26Может в 3.2+ что-от изменилось, не особо слежу в последний год, но до этого новые строки очень плохо жили в реальном мире битых и неизвестных кодировок.
Вот немного чужого батхёрта на эту тему
Throwable
16.06.2015 12:01+2Если под продуктивностью понимать способность решить задачу за минимальное время при помощи данной технологии, то не следует забывать, что решение задачи состоит из следующих фаз:
Архитектура
Прототипирование
Написание кода
Тестирование
Поддержка
Язык как таковой может оптимизировать фазу написания кода, однако не факт, что сопутствующая технология проявит себя так же хорошо в остальных фазах.
Автор упомянул экосистему. Это как раз решающий фактор производительности, когда кусок кода можно заменить одним вызовом сторонней библиотеки. Библиотеки и фреймворки расширяют язык новым функционалом. Экосистема Java одна из самых развитых, и пробовать что-либо вне ее достаточно рискованно, если это не очень узкоспециализированная задача.
На сегодняшний день проблема Java как языка в отсутствии возможности семантического расширения, иначе говоря создания DSLей. Стандартное решение ввиде аннотированного кода плохо: из одних аннотаций невозможно создать семантически связанную струтуру. Альтернатива не лучше: использовать сторонний дескриптор XML, который хоть и связан семантически (XSD), но никак не связан с аннотируемым кодом.
ShadowsMind
13.06.2015 11:23+4Что-то я сомневаюсь, что Martin Odersky преследовал какие-то цели в духе «навредить, разрушить, сделать назло и т.д.». Человек просто экспериментировал и пытался создать хороший язык с кучей фич. И надо сказать ему это удалось. На Scala уже написано очень много всего, как либ/фрэймворков так и проектов. Если говорить о продуктивности, я сомневаюсь что Twitter решили переписать свою экосистему на непродуктивном и чересчур сложном языке…
На Nim пока не видно крупных проектов(ну или может быть я не в курсе). Время покажет насколько это «идеальный» язык…
stranger777
13.06.2015 11:55+2Сначала статья очень понравилась. Нашёл в себе злобствующего микроблогера, очень злобствующего… буду «лечиться». До хеш-таблиц с другой планеты не дошло, я не безнадёжен, слава Богу, но реально написал катастрофически мало рабочего кода, почти весь в теории, в планах, в поиске волшебной палочки, был. И вот за это — большое и искреннее спасибо. Люблю C#. Плохой код не люблю. Поэтому торможу с практикой. Но в итоге мог бы превратиться в совсем кошмарного микроблогера. А это гадостно.
Но без ложки дёгтя не обойдётся. В какой-то момент мне показалась предвзятость к дженерикам. По-моему всё проще: «Не нравится — не ешь», а нравится и подходит если, то и хорошо. То есть раз уж ЯП инструмент, то разным инструментам и руки разные. Кто-то любит гонять до 100 за 5 секунд, а кто-то — ювелир. А кто-то пианист, а кто-то — шахтёр. И так далее…
И вообще, некая антипатия к плюсам, корнями из тех самых девяностых, видимо. Есть же boost, есть Qt. Есть гора Линуксового кода, уже готового.
Вот как-то так. И ещё раз спасибо. Большое.
FreeMind2000
13.06.2015 11:59+1Самая короткая дорога — та которую знаешь.
Знаешь хорошо C++ и умеешь его использовать — быстрее и качественнее напишешь на C++.
Знаешь хорошо Java и умеешь его использовать — быстрее и качественнее напишешь на Java
и т.д…
Думаю, что автор, утверждая:
«Ну да ладно, вот и я как бы повелся, что надо бы писать на плюсах, наелся гавна (в том смысле что вместо того, чтобы программировать — думал за компилятор, скрещал библиотеки, и так далее). Слава богу у меня была производственная возможность плюнуть на все и переписать на Java»
просто констатирует, что на тот момент не знал хорошо C++ и не умел его использовать (не знал тонкостей компилятора и подключения библиотек). Посему выбрал для себя самое верное решение — освоить что-нибудь попроще… и Java оказалась именно такой.
Поэтому непререкаемый вывод:
1. В работе используй только то — что хорошо знаешь и умеешь
2. В свободное время — увеличивай новые знания и умения до уровня «хорошо», чтоб можно было использовать в п.1
3. Если ничего не знаешь и не умеешь — ищи самое простое и быстрое, чему можешь научиться для решения поставленной задачи и переходи на п.2.
Языки программирования и их ЭКО-среда — это как раз, то, что надо хорошо знать и уметь быстро использовать, если Вы отваживаетесь называть себя величественным словом «Программист» ;)vladon
16.06.2015 14:18Но, согласитесь, коллега, в C++ есть проблема с подключением библиотек, не так ли? :)
FreeMind2000
16.06.2015 20:47-2Если человек не знает, как подключить НУЖНЫЕ для решения задачи библиотеки — то конечно, проблема есть.
Если человек знает — проблемы нет.
Весь вопрос в том — обладает ли человек необходимыми знаниями? ;)
То, что некоторые библиотеки плохо совместимы — это часть знаний человека.
То, что существует много библиотек и в проекте лучше использовать хорошо известные и совместимые библиотеки — тоже часть знаний человека.
И наконец, если уж очень при очень требуется использовать в одном проекте плохо совместимые библиотеки (что практически сразу является огромным просчетом в архитектуре проекта) — то их адаптация, это тоже — часть знаний человека
Отсюда вывод:
Если человек — это программист C++, то он по определению обладает этими знаниями и у него проблем нет.
Если человек — это НЕ программист C++, то у него будут проблемы, пока он не получит нужных знаний и не станет программистом C++ :)
Труд — делает из обезьяны человека.
Знания — делают из человека программиста ;)
Antelle
13.06.2015 12:17Посмотрел на ним, выглядит заманчиво, но по мне, так использовать его пока что рано.
Язык программирования — это как валюта. Он живёт из-за авторитета создателей и использующих его. Как это можно сейчас серьёзно использовать, я пока не знаю. Зашёл на hh — 0 вакансий, 0 резюме. Зашёл на freelancer.com — тоже пусто. Версии 1.0 — нет. Официальной поддержки в какой-нибудь известной IDE — тоже нет.
Автор, вы всерьёз утверждаете, что это идеальный язык?zharikovpro
13.06.2015 12:49+1Ну все с чего-то начинается. Когда я начинал изучать и использовать node.js, он считался крайне далеким от stable, редко используемым, экзотическим и т.п. Success story было крайне мало. Прошло несколько лет и теперь достаточно много заказчиков, которые хотят node.js и готовы платить приличные деньги. А у меня уже приличный опыт работы с ним, что замыкает цикл. В общем, поживем-увидим, что будет с Nim.
Antelle
13.06.2015 13:03Согласен, с чего-то всё начинается. Я скорее удивляюсь тому, что автор променял java, и что там ещё был в прошлых статьях (говоря в общем — взрослые языки с уверенностью в будущем, готовые к использованию в продакшне) — на это, причём утверждалось это с таким негодованием, что я ждал чего-то фундаментального (хотя на самом деле не ждал). Я правда не понимаю, как такое бывает.
Так — поиграться, посмотреть, поизучать, что это — не отрицаю, мне даже стало интересно, что за язык такой.
kr41
13.06.2015 13:58+2Хотелось бы узнать мнение автора о D, особенно в сравнения с Nim. Дело в том, что я тоже года два назад столкнулся с вопросом поиска идеального языка и для себя нашел D.
Kane
13.06.2015 14:07+1Насколько я понял мнение автора, если человек использует D, то он мудак
ZloyDyadka
13.06.2015 16:33+1Разве автор не имел в виду мудаками тех, кто умышленно использует неизвестный язык программирования для собственной выгоды? Чтобы только этот «удак» и мог обслуживать код.
Imira_crai
14.06.2015 21:52+2Кстати, в таком контексте первые разработчики на Nim для всех остальных будут полными му… ами
sferrka
14.06.2015 22:26Не обязательно, есть же не только на заказ проекты, а для души, и для себя, и для обучения. В общем, без злого умысла :)
kvark
13.06.2015 16:22+10Простите, но тут сплошной разброд и шатание, а не статья. Автор бегает вокруг, брюзжет на всё подряд, попутно не забывая показать свой многолетний опыт и навыки.
Слово «продуктивность» упоминается чуть ли не в каждом предложении, в то время как качеству, надёжности и производительности почти не уделено внимание (типа, железо уже сильное, не парьтесь). Создаётся вполне определённое впечатление о том, какого рода код пишет автор и его команда. Это код, измеряемый строчками в секунду… Быстрее, больше, ещё больше!solver
13.06.2015 17:01+2Естественно продуктивность будет в каждом предложении.
Видел я таких «продуктивных» разработчиков. Не один раз.
Из разряда «Я за три дня зафигарил проект».
Смотришь в код и видишь там 1 класс и 4 метода… на 9000 строк кода)
Но начальник (заказчик) просто ссыыт кипятком, какой крутой инженер, всем брать с него пример!mjr27
13.06.2015 17:06+2Справедливости ради — если проект не будет поддерживаться, то почему нет?
solver
13.06.2015 17:11+3Если только ради справедливости.
Ибо мы все прекрасно знаем, что такие проекты единичны и на них не стоит делать общие выводы.
P.S. Если только вы не считаете игровой сервер для ммо социалки или систему документооборота для предприятия или аналогичные по сути проекты, не требующими поддержки.
Londoner
13.06.2015 22:06+1Ха, я видел наоборот, когда на 100 строк необходимого кода восемь слоёв абстракции и два десятка интерфейсов, ещё в два раза больше классов, в каждом туча бесполезных методов. Если что-то надо добавить, то править приходится сквозь все восемь уровней абстракции.
worklez
14.06.2015 16:54+1Иногда в продуктивность вкладывают качество получающегося продукта. Если на выходе нет качества, о какой продуктивности может идти речь?
Это Архитекторы и Performance Гики могут после «продуктивной» работы деливерить тормозящие абстрактные фабрики для прошивки утюга и неподдерживаемые системы документооборота на ассемблере.
AVil
13.06.2015 18:44Спасибо за статью. Возможно, взгляд субъективный, но заряд, который заложен в этом порыве субъективности — это бомба. Зарядили на новые свершения.
На мой взгляд, мысли верные и применимы во всем. Двигатель внутреннего сгорания создавался автором вовсе не для того, чтобы им любовались, а для трех конкретных вещей: перестать мучать лошадей, в разы поднять производительность и как следствие — скорость, и третье — улучшить процессы, с этим связанные.
VlK
14.06.2015 00:20+2Сумбурное, эмоциональное и немного скомканное изложение трех тезисов в трех статьях:
1. Автору не нравятся динамические языки.
2. Автору нравятся стройные языки.
3. Автор нашел новую любовь, Nim.
:-) А вообще да, Nim ничего, конечно, приятный, особенно после Scala и, тем более, Java. Не боитесь, что Rust его задавит?Foxcool
14.06.2015 13:52вот да, ничего не имею против того, что люди или я могу писать на ниме, но ощущается, как очередное выставление своего субъективного в объективного. ЯП — это скорее способы мышления в контексте разработки ПО. И привычнее полагать, что люди разные. Соответственно, инструменты разные, и для разных людей тот или иной инструмент может быть или удобен или нет. Я не имею ввиду нарушения логики, но скорее более «высокоуровненые» вещи. Все, как всегда, сводится к фразе: «На вкус и цвет фломастеры разные». Но в целом статьи неплохие. Человек изначально показал свои установки и ценности в данном контексте. Далее он просто перебирал языки и «примерял» их на себя. Как минимум бует полезно для программистов со схожими взглядами.
schetchik
14.06.2015 03:16Так получилось, что прочитал все три части в один день, практически друг за другом. И постоянно в голове крутилась картинка, в которой автор читает свой текст, как монолог. Причем делает это очень нервно, эмоционально, порой сбивчиво, с большими паузами и ударениями, в стиле тарантиновских, наверное, персонажей.
Но в целом было интересно, спасибо, хоть автор и перл мимоходом обидел :)
xakpc
14.06.2015 05:53+1Мне кажется что выбор ЯП имеет довольно опосредованное влияние на производительность программиста.
На первом месте все равно будут инструменты: это в первую очередь IDE, юнит-тесты, CI.
В этом смысле например swift или F# очень круты, так как позволяют сразу увидеть результат. Но это не столько заслуга языка, сколько его interpreter.
Например, в моём случае (.net) освоение решарпером удвоило мою производительность.VlK
14.06.2015 11:33Вдвое? Ох, любят люди громкие слова :)
Flammar
14.06.2015 20:38Человек фактически открыл для себя рефакторинг. Немудрено. Могло и больше, чем удвоить.
VlK
15.06.2015 10:22-2Подозреваю, дело было не в умении реструктурировать или чистить код… :-)
Flammar
15.06.2015 13:59-1А в чём? Хотя, по моему опыту, умение писать быстрее, писать лучше и постоянно поддерживать код в хорошем состоянии вырабатывается довольно быстро при освоении средств автоматизированного рефакторинга.
VlK
15.06.2015 14:13+1Мне просто интересно стало, почему вдруг необходимость поддерживать код в адекватном состоянии стала связана с доступностью того или иного вспомогательного инструмента.
Это я к связи фраз «человек фактически открыл для себя рефакторинг» и «освоение решарпера».Flammar
15.06.2015 17:54+1Насколько я понял, именно о «необходимости» речи не шло, только о способности — про необходимость освоения решарпера или повышения производительности в исходном комментарии написано не было. Была бы необходимость — сразу бы специально объяснили или приняли бы другие меры. А тут — просто человек вдруг узнал, что чистый код можно писать довольно легко и не отходя от практики «скачала пиши код, потом 'причёсывай' его». Имея возможность легко улучшать дизайн кода после его написания, человек поупражнялся и в дизайне кода самом по себе и приобрёл навыки написания более чистого когда сразу, «с листа».
nsinreal
14.06.2015 23:37А расскажите, пожалуйста, что сейчас в решарпере вы используете? А то я внезапно отказался от решарпера полгода назад по причинам плохой производительности компьютера и до сих у меня есть только две основные проблемы: инжект зависимостей через конструктор и выделение класса в новый файл (но на это есть легковесный плагин). Раньше без него жизнь не мыслил, а сейчас не могу вспомнить, что ж там такое офигенное было.
TelnovOleg
15.06.2015 06:39-3Исходя из теоремы Гёделя о неполноте, можно заключить, что не существует языка программирования крутость (эффективность, красивость, элитарность… нужное подчеркнуть) которого можно доказать только исходя из анализа фич, синтаксиса и чего угодно еще только лишь этого языка. Крутость языка начинает иметь смыслы только с введением внешней системы, то есть с добавлением программиста. Следовательно, для разных пар «язык — программист» доказано будет крутость разных языков. Так о чем спор? ;)
kovalexius
15.06.2015 16:33Ну не знаю.
Меня C++ вполне устраивает.
Ведь для него же есть Qt! Значит 3-30 кнопок я — одним махом!) С любой логикой)
Плюс огромная потенциальная мощь, которую я пользую 10%, но она есть!
Да GC нет, но он мне как то и не особо нужен, к тому же есть умные указатели, к тому же есть вроде как фреймворки с GC на борту. К тому же GC в плюсы грядет в 17 стандарте (или выше).
Не хочу я перескакивать на др. язык, тем более что 90% библиотек, фреймворков и т.д. написаны либо на C либо на плюсах.vladon
16.06.2015 14:15В чём преимущество GC перед RAII со смарт-поинтерами? C++11/14 — уже всё, если забыть про raw pointers, то утечек быть не должно (только вместе с мозгом быдлокодера).
kovalexius
16.06.2015 17:28GC разрешает проблему циклических ссылок.
Реализовано примерно так:
В отдельном потоке крутится в цикле со спячками или без некий код, который проходит по графу зависимостей «ссылка-объект-ссылка» пытаясь найти те объекты, до которых он не может добраться.
Ну например, есть объект A, который держит объект B, который держит объект C, который держит объект B. Удаляем B из A (закончилась область действия A) — GC декрементирует счетчик и если счетчик не станет нулем, попытается в отдельном потоке добраться из корня графа до B, если не сможет или такого корня нет, то удалит B, а затем и C.
Как то так.
Политик управления можно множество придумать.
Ну и ничто же ведь не мешает написать фреймворк/библиотечку со смарт-поинтерами и запускающимся GC в отдельном потоке. (ну там и аллокатор памяти, разумеется). Три-в-одном.
Хочешь, подключай инклуд и пользуйся, хочешь подключай инклуд — не пользуйся этими смартами, — GC будет просто спать.
qw1
16.06.2015 17:34+1У смарт-поинтеров, реализованных подсчётом ссылок, низкая производительность (при передаче указателя куда-то нужно делать запись в объект, увеличивая число ссылок), для многопоточных систем использовать блокирующий Interlocked*
GC разбирает циклические ссылки, которые в случае со смарт-поинтерами надо делать указателями разных типов.
В этом случае надо понимать, кто чем владеет и использовать правильные типы. То есть, есть шанс ошибиться, когда в языках с gc можно вообще эти тонкости не держать в голове.vladon
16.06.2015 17:36Подождите. Да, подсчёт ссылок накладывает какой-то overhead. Не будем спорить, какого его влияние. Но очевидно же, что GC всегда и во всех языках будет гораздо дороже, чем refcounting, я правильно мыслю?
(Про многопоточность: управляющий блок shared_ptr'а потокобезопасен, основан на атомиках.)qw1
16.06.2015 18:22+1Но очевидно же, что GC всегда и во всех языках будет гораздо дороже, чем refcounting
Мне не очевидно. Наверняка есть ситуации, когда памяти хватает и до сборки мусора дело просто не дойдёт.
Кроме того, malloc/free вызываются часто и понемногу, а gc работает «оптом»
управляющий блок shared_ptr'а потокобезопасен, основан на атомиках
И это плохо, потому что atomic, или же interlocked-операции, медленные (см. «главный злодей» тут). Если известно, что некоторые объекты не участвуют в конкурентном доступе, стандартный shared_ptr для них не оптимален.0serg
16.06.2015 20:26atomic-операции медленные только в контексте отдельных ассемблерных инструкций.
На практике в подавляющем большинстве случаев оверхед очень мал, примерно между L1 cache miss и L2 cache miss. Проблемы возникают в основном при наивной реализации spinning mutex-ов когда один из потоков начинает непрерывно проверять залоченную кем-то память через атомики.
Применительно к плюсам — у shared_ptr проблем с производительностью при грамотном использовании нет. Достаточно не копировать shared_ptr без необходимости (скажем передавая его by-value повсюду) и все будет ОК. Банально нету ни в одной разумной программе такого количества операций «take/release ownership» чтобы это начало существенно сказываться на производительности.qw1
16.06.2015 22:02Это так. Я пришёл к более радикальному выводу, что передавать смарт-поинтеры в качестве параметра ф-ции никогда не нужно, ни по ссылке, ни по значению. Достаточно обычного
[const] T*
Вызывающий ф-цию код владеет объектом, поэтому до окончания вызова объект не исчезнет.0serg
16.06.2015 23:03Если ф-я меняет state а не просто возвращает значение, то иногда все же нужно передавать туда смарт-поинтер который она где-нибудь сохранит. Но в целом да, подавляющему большинству функций удобно передавать на вход ссылки, реже — указатели.
vladon
17.06.2015 11:01Передавать можно, а иногда и нужно (когда он там дальше передаётся).
Передавать лучше поT&&(если в шаблонную).
qw1
16.06.2015 18:27+1Избыточные write-операции, которые приходится делать счётчику ссылок, это плохо. Объясню, почему. Например, имеем большую коллекцию не изменяющихся объектов (которая вся не помещаются в кеш), на объекты делаются смарт-указатели. Если бы указатели были без подсчёта ссылок, при вытеснении старых объекток из кеша, на их место были бы загружены новые. Но с подсчётом ссылок кеш-линия помечается как изменившаяся и при вытеснении сначала её надо выгрузить в RAM.
0serg
16.06.2015 21:07+1Ну а сборка мусора у GC вынуждает обходить практически всю аллоцированную память, и? Мало того что это изначально дает изрядные периодические тормоза которые далеко не везде допустимы, так это еще и создает поистине эпические проблемы при попытке задействования своп-файлов. На плюсах при необходимости можно эффективно работать с десятками гигабайт памяти через memory-mapped файлы при небольших объемах физической тогда как та же Java практически вынуждена довольствоваться только доступной физической памятью.
grossws
16.06.2015 21:39+1Ну а сборка мусора у GC вынуждает обходить практически всю аллоцированную память, и?
Давно не так. Есть поколения, есть dirty checking.
еще и создает поистине эпические проблемы при попытке задействования своп-файлов. На плюсах при необходимости можно эффективно работать с десятками гигабайт памяти через memory-mapped файлы при небольших объемах физической тогда как та же Java практически вынуждена довольствоваться только доступной физической памятью.
В тех задачах, где хочется использовать mmap в java используется nio (FileChannel, ByteBuffer etc) и off-heap storage (который может быть написан с использованием nio или native расширений).0serg
16.06.2015 22:59Давно не так. Есть поколения, есть dirty checking.
Ну, я не специалист по Java, но беглый поиск показывает что пользователи java вынуждены «тюнить» настройки GC под свои задачи, а при определенных условиях full gc может занимать десятки секунд — и это в Java 7 с G1 GC. Для 2011-12 на вид проблема была весьма себе актуальной — не везде, конечно, но тем не менее. Я допускаю что ситуация к 2015 изменилась, но я хочу обратить внимание на две вещи:
1. Проблема сборки мусора гораздо сложнее чем её обычно изображают и сейчас для её решения используются крайне сложные методы среди которых нет универсально хорошо работающего во всех случаях жизни
2. Продвинутые GC вынуждены записывать довольно большое количество дополнительной информации типа тех же dirty cards и это может давать проблемы схожие с описанной выше qw1 проблеме неэффективной работы reference counter-ов с кэшем
В тех задачах, где хочется использовать mmap в java используется nio (FileChannel, ByteBuffer etc) и off-heap storage (который может быть написан с использованием nio или native расширений).
Верю. Проблема в том что в плюсах это делается и проще и эффективнее.grossws
16.06.2015 23:59+4То, что вы говорите — абсолютно верно. С одной существенной оговоркой: на большинстве задач большинства пользователей этих проблем нет. И принципиально ситуация до java 8 не изменилась (на jre 8 — не знаю — пока у нас её почти нет в production).
Основная масса знакомых мне случаев, требовавших тюнинга GC укладывается в следующие категории:
— несоответствие профиля работы с памятью настройкам GC: другие времена жизни (объекты слишком быстро уезжают в oldgen и висят мертвым грузом до major gc), слишком маленькие eden/survival (частые минорные сборки и отправка объектов в oldgen);
— паттерны работы с памятью не укладывающиеся в модель generational GC: очень активное переиспользования долгоживущих объектов (соответственно много активно изменяющихся объектов в oldgen), использование крупных короткоживущих объектов (которые сразу уезжают в oldgen, т. к. не помещаются в eden);
— работа с большой кучей (большое время major gc).
Первая «проблема» лечится профилированием и настройкой GC. И не является проблемой, по большому счёту. Она сродни настройке размеров пулов потоков, соединений, размеров буферов, очередей и т. п. Обычно ничего катастрофического не происходит при неоптимальной настройке.
Вторая и третья проблемы лечатся по разному (в зависимости от задачи): изменением алгоритмов и структур данных, использованием offheap storage, выносом в нативные расширения (например, в heliosearch часть расчётов на больших короткоживущих массивах делается именно в нативном коде), распиливанием на компоненты меньшего размера, избеганием major gc (вплоть до перезапуска приложения вместо gc). Но это уже сильно зависит от задачи и имеющихся ресурсов.
В общем, GC в Java далеко не идеален, но довольно сильно оптимизирован и неплохо справляется в большинстве задач. Но не серебренная пуля, конечно.
0serg
16.06.2015 20:45unique_ptr работает в >90% случаев и не требует использования interlocked или ведения счетчиков ссылок
Еще чаще смарт-поинтеры вообще не нужны, поскольку лишь ничтожное меньшинство операций с указателями как-то пересекается с идиомой владения
Системы где были бы реально нужны циклические ссылки на практике лично мне вообще пока не встречались.
Смарт-поинтеры в плюсах требуют определенной культуры использования и при ее нарушении могут создавать проблемы, но эта культура там весьма простая и у сколь-либо опытного разработчика её соблюдение происходит автоматически без малейших сознательных усилийvladon
17.06.2015 11:03> Еще чаще смарт-поинтеры вообще не нужны, поскольку лишь ничтожное меньшинство операций с указателями как-то пересекается с идиомой владения
Почти все raw указатели можно смело менять на unique_ptr, я даже не могу представить случая, когда raw pointer нельзя будет заменить на unique_ptr.
JC_Piligrim
16.06.2015 01:56+21. Скачал установщик Nim под Windows
2. При установке отметил все галочки (компилятор и IDE)
3. Запустил «китовую» IDE
4. Скопировал туда helloworld с первой страницы документации
5. Компилирую и запускаю helloworld из IDE — вместо вывода в консоль «введите своё имя» и ожидания ввода — чёрное окно с намертво повисшим процессом.
Вывод: и ЭТО вы считаете идеальным языком? Там даже helloworld не работает. :(
Рановато, мне думается, вы ему рекламу дали. Может, ложки-то и найдут, но осадочек у многих пацанов с раёна Хабровцы останется.
96467840
16.06.2015 08:37не язык делает нас продуктивными. хотя и он не на последнем месте! продуктивными нас делает опыт, либы, окружение.
Ojow
16.06.2015 12:54+3К Скале, к сожалению, нужен особый подход. Нужно либо чутьё и понимание замысла создателей (это не какой-то редкий дар, я видел много таких людей), либо кто-то, кто знает, куда лучше не лезть.
Новички (и не только «неопытная молодёжь», как наглядно показано) всегда нарываются на scalaz и shapeless, потому что про них больше всего трёпа в интернете. А пользоваться ими в типичных «конторских» проектах вообще нельзя.
Для Type Classes библиотеки не нужны.Ojow
16.06.2015 13:02P.S. Я не считаю Скалу идеальным языком. Наверняка кто-то уже рассмотрел все свойства языков и доказал, что идеального быть не может, потому что для разных целей нужны противоречащие друг другу свойства.
Vitter
17.06.2015 01:03+2Термин "продуктивность программистов" понятен, но оценить язык по этому критерию можно лишь эмпирическим путём.
Думаю, хорошим аналогом анализа самого языка будет критерий "уменьшение рутины".
И вычислять, например, отношением «важных строк» к «строкам согласования» (они же «строки склейки»). Чем больше %, тем меньше рутины и более продуктивней язык.
olegchir
17.06.2015 12:03+2nim? это точно не тонкий троллинг?
можешь описать картину замысла (холст, масло)?
чем чисто практически, для производства, это лучше жабы, которая уже «просто работает»
ты нарисовал бы Эклипсу на ниме быстрее, чем на жабе?vladon
17.06.2015 16:34+1Жаба не работает, а
тормозитсобирает мусорgurinderu
17.06.2015 16:48+2Угу, именно поэтому на нем написан Eclipse,Idea..., чтоб тормозило.
vladon
17.06.2015 16:50+2Так они и тормозят ведь, будьте честны сами с собой.
overmes
17.06.2015 16:54У меня не тормозит
vladon
17.06.2015 16:57Я работаю в Visual Studio (2013) под Windows и в CLion (по сути, IDEA) под Ubuntu. Машины идентичные.
VS быстрее, и это заметно невооружённым глазом.
Расскажите о конфигурации вашей рабочей машины.
Объективно Java-код не может работать быстрее нативного. Вы же не будете с этим спорить?overmes
17.06.2015 17:34Обычный десктоп — i5, 8ГБ, HDD
На другой машине у меня еще SSD есть, там быстрее работает
Но и без SSD не тормоитvladon
17.06.2015 17:58+1А, ну значит, вам просто не с чем сравнить, если вы работали только в IDE, написанных на Java.
0serg
17.06.2015 21:18А у Вас какой размер проекта? Хотя бы тысяча файлов наберется?
На маленьких-то проектах конечно ничего не тормозит :)
MaximChistov
17.06.2015 17:34Объективно может, ведь «нативный» код на самом деле не нативный — он сделан чтоб выполняться на куче разных процессоров, а вот код который делает jit оптимизирован под конкретное железо(в оптимальном случае),
vladon
17.06.2015 17:58Т.е. посредник в виде jit не накладывает никакого оверхеда, по-вашему?
Ещё и GC там работает.EjikVTumane
17.06.2015 18:23+2И в чем же может быть оверхед при исполнении нативного кода, сгенерированного jit'ом?
nsinreal
17.06.2015 18:32Если не прогонять программу через что-то типа ngen, то как минимум будет замедление, потому что сначало нужно скомпилировать промежуточный код в ассемблер. И это если у вас компиляция метода происходит при первом вызове метода.
Вот интересный вопрос: а сколько компилится код с помощью JIT? Не должен слишком долго, а поэтому часть оптимизаций отсекается. Не может быть почти моментальным, иначе не будет никаких оптимизаций.
Тут умные дядьки придумали делать оптимизации сначала на компиляторе Java/C# -> промежуточный код. А потом на компиляторе промежуточный код -> ASM. Вы уверены, что при двойной компиляции мы не теряем часть полезной информации, которую можно было заюзать для оптимизации?
А вот еще момент. А если программа запускается несколько раз, не будет ли разумным сохранять результаты работы JIT? А если так, то когда? И во сколько нам обойдется работа с файловой системой?EjikVTumane
17.06.2015 18:55+1Если не прогонять программу через что-то типа ngen, то как минимум будет замедление, потому что сначало нужно скомпилировать промежуточный код в ассемблер....
Правильно, оверхеда нет — есть единовременные затраты на jit компиляцию ;)
Спорить от тормозящих IDE я не хочу — у меня просто зацепился глаз за утверждение про «оверхэд» выполнения нативного кода.
Единственно, что отмечу про VisualStudio, применительно к плюсам, — меня всегда огорчал предоставляемый ей функционал по рефакторингу кода, где не было даже элементарного переименования методов и классов «из коробки». Поэтому никогда не удивлялся тому, что при этом она работает быстрее.
Тут умные дядьки придумали делать оптимизации сначала на компиляторе Java/C# -> промежуточный код. А потом на компиляторе промежуточный код -> ASM. Вы уверены, что при двойной компиляции мы не теряем часть полезной информации, которую можно было заюзать для оптимизации?
Можно я просто сошлюсь на других «умных дядек» успешно занимающихся Clang и LLVM? ;)qw1
17.06.2015 19:43Правильно, оверхеда нет — есть единовременные затраты на jit компиляцию ;)
У меня есть наглядный пример — жирное enterprise приложение на c#.
Когда открываешь окошко, которое в текущей сессии ещё не открывалось, оно пол-секунды «компилирует». Конструктор диалога почти пустой, в базы не ходит. Разве что ресолвит зависимости из di-контейнера.
А поскольку окошек всяких разных много и типичный девелопер обычно не работает долго в одном, а открывает приложение при необходимости что-то глянуть и переходит в некоторое окно, тормоза раздражают постоянно.EjikVTumane
17.06.2015 19:58+1Стоп-стоп! Еще раз прошу перечитать мое сообщение :)
Коротко:
а) Оверхеда на выполнение уже скомпилированного кода нет
б) Время на jit-компиляцию тратится
в) Речь не о том, что тормозит или не тормозит, а о не смешивании всего в одну кучу.qw1
17.06.2015 23:37Я о том и говорю. Теоретически всё хорошо. На практике — запускаешь managed-программу и фейспалмишь.
EjikVTumane
17.06.2015 23:57Я, как Java-разработчик ;), полностью доволен тем как работает JVM (ее производительностью и средствами для разработки которые она предоставляет).
grossws
18.06.2015 03:32+4Вот интересный вопрос: а сколько компилится код с помощью JIT? Не должен слишком долго, а поэтому часть оптимизаций отсекается. Не может быть почти моментальным, иначе не будет никаких оптимизаций.
Если говорить за JVM, то она JITит методы только если они вызываются достаточно много раз (10к в server mode, если правильно помню), с учётом набранной статистики вызовов. И может переключить в интерпретируемый режим обратно (разJITить), если ей что-то не понравится.
Это приводит к тому, что:
— JIT компилирует не всё, а только горячие участки кода (снижая суммарные затраты времени на компиляцию),
— JIT использует довольно агрессивные варианты оптимизации исходя из статистики реальных вызовом метода (в частности, специализированные методы, dead path elimination, агрессивный inline).
Такой подход приводит к тому, что результирующее приложение после «прогрева» может работать быстрее, чем аналогичное, написанное на компилируемом языке или, тем более, на интерпретируемом с использованием AOT. Именно поэтому, увидев java-бенчмарки без прогрева, стоит гнать их авторов ссаными тряпками.
lexxpavlov
18.06.2015 19:23но, получается, что jvm куда-то сохраняет эту статистику по каждому вызову каждого метода. И это уже может ыбть приличным оверхедом.
grossws
18.06.2015 19:32+1Да, естественно это даёт некоторый оверхед (и по памяти, и по cpu). Но то, что скомпилированно JITом уже не имеет этого оверхеда, если не сваливается в slow path (при невыполнении параметров, при которых оно заоптимизированно).
Опять же, подробную статистику по методу JVM может собирать не сразу, а после накопления некоторого количества его вызовов, чтобы уменьшить оверхед на сбор статистики на холодных методах.
kovalexius
19.06.2015 13:42Нативный код — нативный.
Особенно на языках типа C, C++, Delphi и т.п.
При компиляции этого кода хороший компилятор может производить оптимизацию под конкретное железо. Если задать ему соотв. ключи.
С другой стороны — вы правы, проги ведь распространяются обычно в собранном виде.
Если собирались для amd, а выполняются на intel'е, то вообще даже могут не выполниться.
Опрос железа и несколько вариантов сборок помогут. Костыль однако.
gurinderu
17.06.2015 18:12+4А ты смешной.
Не смущает что VS написано с использование с#, где тоже есть gc? Не смущает, что у Java есть Jit, который в теории может дать пифоманс горячего кода даже лучше, чем у c++? Улыбнуло насчет тормозит вообще. Ничего что люди на Java пишут почти real-time приложения? ))qw1
17.06.2015 18:25Тут дело не в том, что java теоретически может дать, а в том, как пишется реальный код.
На c++ разработчик потратит 3 дня на компонент, вручную освобождая память сразу, как только она не нужна, размещая короткоживущие объекты на стеке, не используя string, когда достаточно char* и т.д. На java всё это напишется за день, но без обдумывания низкоуровневых деталей, всё на автомате и по дефолту.
На java можно написать супер-производительный код «на спор», обдумывая его не меньше, чем код с++, но в большинстве случаев язык позволяет меньше думать. Значит, в программу вложено меньше знаний о специфике конеретной ситуации, значит, хуже производительность.vladon
17.06.2015 18:28Кстати, в современных компиляторах использование std::string будет незаметно по сравнению с char*.
Вот честно — по сути это то же самое, можно даже код ассемблерный посмотреть.
А на маленьких строчках даже быстрее будет из-за Small String Optimization (память для маленьких строк берётся прямо в стэке, а не аллоцируется в куче).
0serg
17.06.2015 21:35+2На c++ разработчик потратит 3 дня на компонент, вручную освобождая память сразу, как только она не нужна, размещая короткоживущие объекты на стеке, не используя string, когда достаточно char* и т.д. На java всё это напишется за день, но без обдумывания низкоуровневых деталей, всё на автомате и по дефолту.
В плюсах все пишется за тот же день и на том же автомате. Смарт-поинтеры там где нужно, использовать std::string везде. И результат будет при этом гарантированно работать без утечек и сегфолтов, причем уже даже в таком тупом варианте «из коробки» он будет быстрее чем в Java. Дальше, если кусок очень performance-critical можно потратить дня три на его вылизывание, но даже при этом работа будет сосредоточена на алгоритмической и логической оптимизации, а не на возню с памятью. Это я как разработчик серьезного CAD/CAM и тяжелого высокопроизводительного real-time говорю.
Да, к сожалению, в плюсах можно и пострелять себе в ногу, а куча литературы учит работать на плюсах «в стиле C». Но это, прямо скажем, делать не обязательно и научиться хорошим практикам труда не составляет :).
nsinreal
17.06.2015 18:25+1Не смущает что VS написано с использование с#, где тоже есть gc
1. Вы уверены, что VS вся написана на C#?
2. В C# есть структуры и нормальные generics, поэтому нагрузка на GC меньше.
Не смущает, что у Java есть Jit, который в теории может дать пифоманс горячего кода даже лучше, чем у c++
«пифоманс», блять. Java и C# еще не доросли до такого уровня, чтобы выдавать подобные характеристики. Я имею в виду не в теории теории, а в реальной теории.
Улыбнуло насчет тормозит вообще
Так тормозит же. Холодный запуск очень медленный, gc stops the world.
Ничего что люди на Java пишут почти real-time приложения?
Пруфы, пожалуйста.gurinderu
17.06.2015 20:091. А я не говорил, что вся)
2. Не знаю как это может помочь уменьшить нагрузку на GC
3. Возможно и доросли. Ведь для Java есть и AOT компиляторы
4. Спорный вопрос, ибо в Java динамическая подгрузка классов. Естественно первый раз нужно прогрузить rt.jar, но это не так долго
5. Ничего конкретного сказать не могу, но есть проект Javalution, который якобы нужен для real-time. И на jug встречах Роман Елизаров (насколько я это помню) рассказывал о своем приложений.nsinreal
18.06.2015 11:302. Не знаю как это может помочь уменьшить нагрузку на GC
Структуры не учавствуют в процессе сборки мусора. Они хранятся либо на стеке, либо внутри объекта. На структуру тупо нету указателя, соответственно нет необходимости в GC — их удаление просчитано еще в compile-time. Нормальные честные generics приводят к тому, что структуры хранящиеся внутри коллекции не надо заворачивать в объект.
3. Возможно и доросли. Ведь для Java есть и AOT компиляторы
Почему код может быть быстрым после компиляции? Есть два варианта: нету тупорылых рантайм проверок и оптимизация на уровне смысла кода. Первый вариант в джаве и шарпе не прокатывает, а выразительность на уровне языка не сильно возрасла.
На 4-й пункт ничего не могу сказать, есть только личные впечатления.
Ivanhoe
17.06.2015 20:22> Ничего что люди на Java пишут почти real-time приложения?
Вроде да, пишут. Но ЕМНИП там довольно жесткие ограничения на использование памяти, в том числе запрет на создание объектов в куче и, соответственно, никакого GC.
Пруфы, пожалуйста.
grossws
18.06.2015 03:47Пруфы, пожалуйста.
Скорее тут стоит говорить про NRT, т. к. на обычной JRE жесткий RT невозможен. Из забавных NRT-проектов есть Apache Storm (ранее Twitter Storm), игрища вокруг Apache Spark, всякие Apache Zookeeper, Apache Kafka, асинхронка на Akka.
Другой пример производительного кода на Java — Apache Lucene (правда, код местами сильно напоминает аналогичный на Си, но программист на Фортране может писать на Фортране на любом языке, да). Но такие вещи часто пишутся с учётом особенностей JVM, с кучей низкоуровневых оптимизаций, с использованием примитивных типов данных и массивов примитивов. Иногда и с выносом частей кода в нативные расширения, если совсем припрёт, как, например, heliosearch. Йоника до этого довели проблемы с gc, т. к. для некоторых запросов (построение фасеток) необходимо выделять большие (от сотен мегабайт до единиц гигабайт) короткоживущие (обычно до сотен миллисекунд) объекты на каждый запрос, что приводит к быстрому загаживанию oldgen и major gc (с присущей ему stw-паузой).
erthad
18.06.2015 22:30+1Люди RTB на Clojure пишут devopsdeflope.ru/posts/2015/018.html (только аудио, без текста).
EjikVTumane
17.06.2015 18:26-2Его также не смущает, что студия без Resharper'а (и иже с ним) не далеко ушла от блокнота в возможностях по работе с кодом, сравнивая с IDE от JetBrains.
vladon
17.06.2015 18:29Во-первых, студия с C++ Resharper'ом всё равно тормозит меньше, чем чистый CLion. (Но больше, чем без решарпера.)
Во-вторых, вы видели VS 2015 RC?overmes
17.06.2015 18:38-3студия с C++ Resharper'ом всё равно тормозит
может хватит мучиться?
переходите уже на Notepad++ или что-нибудь попроще, vim например(только без плагинов)
vladon
17.06.2015 18:35В CLion работа GC очень заметна, особенно на больших проектах. Просто раз в N минут всё приложение тупо зависает :-)
overmes
17.06.2015 18:39Это бага студии, она действительно есть, это не gc, с какой-то версии так стало происходить
У меня последний PyCharm, такого больше не наблюдаю
vladon
17.06.2015 18:35Ничего что люди на Java пишут почти real-time приложения? ))
Кстати, вполне возможно, что и пишут. Но отличие в том, что на C++ уже написали, и эти приложения реально работают почти real-time :-)solver
17.06.2015 19:32+2Для тех 0.001% приложений, для которых этот «жосткийрилтайм» нужен, используют С++, все верно.
Остальные же 99.999% приложений, люди спокойно пишут на Java и иже с ним, за день.
И смотрят снисходительно на тех упоротых, которые неделями выжимают никому не нужные проценты производительности. А потом еще недели тратят на борьбу с сегфолтами и утечками.
Попутно отхватывая проблем с кросплатформенностью…
Кстати, если IDEA на Java такая тормозная гадость, а С++ такой вот весь из себя быстрый и крутой, где IDE уровня IDEA написанные на нем?vladon
17.06.2015 22:18Т.е. всё-таки нет «почти риалтайм» приложений на Java? :-)
IDE уровня IDEA — Visual Studio 2015.
Но, вообще, это не аргумент. Точно так же можно спросить «Где [куча приложений, существующих на C++], написанные на Java?»gurinderu
17.06.2015 23:21+1Реалтайм это крайне широкое понятие. Для кого-то это наносекунды, для кого-то миллисекунды. Слово «почти» я использовал тут, потому что не бывает реального реалтаима)
burjui
18.06.2015 12:40В ОС общего назначения не бывает, да. А в RTOS очень даже бывает, и тем более совсем без ОС, на голом железе. К слову, на Java тоже можно писать настоящий real-time, просто дефолтный GC для этого не подходит.
gurinderu
18.06.2015 12:46Настоящий реалтайм — это тот который происходит в тот же момент времени. Однако процессор работает по тактам => не бывает в цифровой технике настоящего реалтайма.
Однако бывает условный. Я уже писал, что для кого-то и ответ в 10секунд будет «реал-таймом», а для кого-то 10 наносекунд будет «ой как медленно».grossws
18.06.2015 13:03Настоящий, жесткий real time — это предсказуемое и лимитированное максимальное время реакции на событие.
Реакция ASAP — не является realtime. Реакция «за время не более 100 us», если так написано в ТЗ — является.
burjui
18.06.2015 13:35+2
grossws
18.06.2015 04:04+1Для тех 0.001% приложений, для которых этот «жосткийрилтайм» нужен, используют С++, все верно.
Хороший пример на тему — народ в какой-то момент, накурившись статей про bigtable и dynamodb написал Cassandra на Java, но нашлись добрые люди, решившие, что БД писать на Java — это не кошерно, работает медленно и всё такое. И запилили свой Hypertable на C++. К моменту, когда у кассандры был опыт боевой эксплуатации, большое количество пользователей, нормальный набор фич, у Hypertable была сырая пре-альфа в течении кучи времени, в которую залить пару сотен Гб без сегфолта было сложно. Зато на C++. В итоге, у кассандры уже второй стабильный major релиз, а hypertable ползёт к 1.0, но использовать её пока стрёмно.
Остальные же 99.999% приложений, люди спокойно пишут на Java и иже с ним, за день.vladon
18.06.2015 12:23Посмотрел их код. Чуваки решили переизобрести STL, судя по всему. И везде raw pointers. В общем, неудивительно. Это ничего не говорит о языке.
grossws
18.06.2015 13:00+2Это скорее говорит о людях, которые начинают бездумно переписывать что-либо на C++ «патамушта быстрее». В каких-то задачах C или C++ будет предпочтительнее, в каких-то почти неизбежен, но есть большой класс производительных/NRT задач, которые не требуют реализации на Си++. На современной jvm можно решать задачи, требующие высокой производительности в смысле throughput или avg latency (до некоторого предела).
Когда требуется совсем маленькие latency или предсказуемая максимальная задержка (жесткое rt), то без C/C++ (или ещё чего-нибудь без рантайма, накладывающего ограничения на предел снижения максимальной latency или его детерминированность) уже не обойтись.
Мой пример про cassandra/hypertable был обратным к вашему «Но отличие в том, что на C++ уже написали, и эти приложения реально работают почти real-time».
Другой аналогичный пример — lucene vs clucene vs lucene4c. Оригинал на java живёт и активно развивается, lucene4c (на Си) загнулся довольно давно, т. к. нафиг никому не нужен. Clucene (порт на C++) в стабильной версии соответствует lucene 1.9 (2006 год), в нестабильный — lucene 2.3.2 (2008 год). Средняя жизнь в рассылке clucene — менее 3 сообщений в месяц, открытые баги висят в работе с 2006 года. Как написал один из разработчиков на вопрос мертв ли проект в рассылке:Answer is probably yes. I'm still fixing bugs time to time but nobody else seems to be active here
Цена развития и поддержки проекта на C++ часто оказаться слишком большой, и проект, в лучшем случае, буксует.vladon
18.06.2015 14:47Стремление всё переписать вообще многое говорит о людях. Не надо переписывать. Ни с Java на C++, ни наоборот.
grossws
18.06.2015 15:26+1В данном случае, под «переписать» имелось ввиду реализовать идеи гуглового bigtable, а не портировать 1-в-1. Кроме того, портирование под другой язык иногда оправдано. Это уже от задачи.
olegchir
22.06.2015 12:50+3Забавно, какое бурление вызвал этот комментарий.
Меня не волнует, что джава тормозит компьютер, т.к. торможение незначительное, и в моих задачах это не играет роли. Значительные тормоза контролируются.
Что касается константной платы за запуск JVM, глубину иерархии клссов итп — планка оперативки и кингстоновский SSD, то и другое по 60 баксов у ближайшего барыги, стоят неизмеримо дешевле времени работы разработчиков.
Когда будете из своего кармана платить за то, чтобы кодер на Крестах месяц разрабатывал одну кнопочку, или команда нодо-поклонников джва месяца пыталась разобрать, какой динамической лапши наворотили их предшественники, вот тогда и вспомните.
Throwable
17.06.2015 17:56+5Внимательно посмотрел я этот Nim. Это фактически Паскаль с питоньим синтаксисом и модными плюшками. У меня ощущение не особо приятное. Синтаксическое core языка достаточно громоздко. Вместо элегантного расширения при помощи API и типов, функционал зашит в синтаксис. Система типов посредственная. Когда одни языки используют концепты immutability, null-safety, value types, Nim пытается заставить нас вспомнить как правильно работать со сцылками. Одни zero-terminated mutable strings чего стоят! Язык прямо из коробки идет с кучей прикладной магии ввиде pragmas, шаблонов и макросов.
Вобщем, этакий невзрачный язык технического уровня наряду с D, Vala, etc…
ruslanys
18.06.2015 00:18+5Стоит признать, что статьи этого цикла интересно читать: была какая-то интрига, да, и слог легкий, что-то цепляло. Но лично мне, очень неприятна настолько агрессивная и радикальная позиция автора во многих вопросах. Тем более, я бы не стал в статье такой тематики и контекста употреблять бранных слов…
В любом случае, почему начались такие войны в комментах? Человек нашел свой «идеальный» язык. Любая точка зрения субъективна. И для его взглядов на задачи, их решения, Nim — это «идеальный» язык. Можно подумать о его клиентах, в глазах которых он будет выглядеть как «один не очень хороший знакомец». Но если какие-то свои проекты, или внутренние. Если он полностью справляется с его задачами и предпочтениями, почему нет?! И за него стоит только порадоваться!
Я, например, работаю на Java. И несмотря на то, что последнее время мало услышишь положительных отзывов о ней, я ее не меньше люблю. Она полностью справляется с задачами, которые я решал, и решаю: нагруженные веб-системы, корпоративные решения, смартфоны, даже программирование для контроллера EHS6 (кстати, скоро будут платы с этими штуками!). Но если мне придется решать задачу, с которой Java не справится, я буду изучать другой язык, в чем проблема?
Мне кажется, что единственный качественный и объективный показатель для языка — это количество свободных вакансий, и уровень ЗП для разработчика, владеющего этим языком. Я вряд ли буду продолжать работать на Java, если разработчикам Nim/Go и др., в среднем будут платить в 3-5 раз больше 0_0, и вакансий будет куча)
Ну, опять-таки, это лишь моё субъективное мнение…kvark
18.06.2015 17:22+3У нас тут не портал начинающих писателей, знаете ли, а технический ресурс. Автор виновен не только в бранности, но прежде всего — в несостоятельности своей позиции. Nim — замечательный язык, надежда многих разработчиков на хорошую смесь C++ и Питоном, но говорить о продуктивности здесь и сейчас как-то странно, учитывая нестабильность языка и неразвитость экосистемы.
olegchir
22.06.2015 13:03+3Заметил одну крутую оптимизацию. Если человек с первого абзаца придирается к бранным словам, то с ним не получится работать дольше 5 минут. Хотя бы потому, что после моего вопроса «чепушило, какой жопой ты писал этот писец?», пойдет не конструктивный диалог об особенностях решения, а какой-то бред про бранные слова.
> В любом случае, почему начались такие войны в комментах? Человек нашел свой «идеальный» язык.
потому что автор хотел войны в комментах, очевидно же. Это забавно. Спорим на что-нибудь бесполезное (например, проигравший читает и делает туториал по Nim), никакого идеального языка он не находил, а просто хочет потроллить больных синдромом поиска глубинного смысла языка программирования.
> Я вряд ли буду продолжать работать на Java, если разработчикам Nim/Go и др., в среднем будут платить в 3-5 раз больше 0_0, и вакансий будет куча)
и чем же данные языки так хороши, что они окажутся популярней джавы? И почему за них будут платить в 3-5 раз больше, если они настолько популярны?ruslanys
22.06.2015 13:34+1Заметил одну крутую оптимизацию. Если человек с первого абзаца придирается к бранным словам, то с ним не получится работать дольше 5 минут. Хотя бы потому, что после моего вопроса «чепушило, какой жопой ты писал этот писец?», пойдет не конструктивный диалог об особенностях решения, а какой-то бред про бранные слова.
Ну, во-первых, рабочий процесс — это одно, а статьи на техническом ресурсе — это другое. В любом случае, по Вашей логике можно любые претензии выражать в бранной форме? Это как минимум не этично, даже если
чепушило, жопой писал этот писец
—Спорим на что-нибудь бесполезное
Нет, не спорим, тем более на что-нибудь бесполезное.
и чем же данные языки так хороши, что они окажутся популярней джавы? И почему за них будут платить в 3-5 раз больше, если они настолько популярны?
Вы слишком буквально приняли мои слова. Смысл глубже. Это лишь пример, описывающий мою позицию в указанном контексте.
P.S. Выделяете цитаты символом ">" — привычка RedMine?)grossws
22.06.2015 13:37+2P.S. Выделяете цитаты символом ">" — привычка RedMine?)
Почувствовал себя старым пердуном, до сих пор пользующимся plain text email.
netslavehq
23.06.2015 21:11Продуктивность? Да, важна, но что если язык вообще не подходит под задачу?
Хотелось бы услышать авторитетное мнение platoff о Erlang`е. Так как сейчас «болею» именно ним.
develop7
24.06.2015 08:09+1Крайне позитивно влияют на продуктивность pattern matching, binary syntax и list/binary comprehensions. Негативно на продуктивность влияют общая примитивность синтаксиса, системы типов и фрагментированность экосистемы (последнее отчасти вызвано высокой продуктивностью :) ).
grey_kristy
24.06.2015 13:24+1Надо откровенно признать, что Erlang это нишевый язык. В своей нише — распределенные отказоустойчивые сервисы он очень хорош. Конкурентов почти нет.
Но писать на нем приложение для смартфона или, скажем, графичечкий редактор — теоретически наверно можно, но явно не нужно
afiskon
Аааа, думал не дождусь продолжения :)
dordzhiev
Ну после того комментария странно было бы не увидеть продолжения :)