Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 236
Аааа, думал не дождусь продолжения :)
Языки и технологии дают вам конкурентное преимущество, а если вы сидите на тех же самых языках и технологиях, что и половина программистов вокруг — о каком технологическом преимуществе может идти речь?
В таком случае, как объяснить ваше желание рассказать всем о «дешевых акциях» — переизбыток чувств, глупость или скрытые мотивы (пропихнуть всем ложное направление, а самому купить реальные акции :-)?
Сразу видно, что на бирже вам делать нечего :) надо быть проще и честнее и тогда все будет. Я уже в дешевых акциях и получаю дивиденды. Если акция хорошая — она будет расти, со мной или без меня. И это хорошо для меня. Рост долгий, и если люди туда заходят быстро, то хорошо, заходят долго — тоже неплохо
Во всем интернете нет ни строчки его кода, разве что портированные чужие либы с чего-нибудь на Haskell, или с PHP на Perl.
Мне кажется, я знаю о ком идёт речь…
И уже еще +7 человек знают. Интересно, они все об одном и том же «микроблогере» думают? :)
Интрига! О ком? )
Так, что бы не надумали там себе всего.
Я имел ввиду уважаемого afiskon.
Я ничуть не сомневаюсь в его профессионализме и никоим образом не хочу его обидеть. Но его посты в блоге и темы подкаста очень напоминают описание из статьи.
Я имел ввиду уважаемого afiskon.
Я ничуть не сомневаюсь в его профессионализме и никоим образом не хочу его обидеть. Но его посты в блоге и темы подкаста очень напоминают описание из статьи.
Я когда читал у меня самого возникло чувство, что речь обо мне. Но на самом деле не сходится. Я на Perl за деньги писал три года назад и тогда подкаста не было, о блоге никто не слышал, да и ФП, насколько помню, я вроде бы не особо расхваливал, сам только разбирался во всем. Есть подозрения, что образ, описанный господином platoff является собирательным. Или нет? ;)
Просветите. Можно в личку.
Это тот, который Самизнаетекто? (На букву «Л»)?
— Хотите, научу вас как заинтриговать?
— Хочу!
— Завтра расскажу как.
— Хочу!
— Завтра расскажу как.
С такими характеристиками стоит на zadolba.li писать, а истории про себя правильного на ithappens. А этот сайт ведь когда-то чисто техническим считался, где хорошим тоном было писать статьи без ложных предпосылок, не забывая четкие аргументы, а при сравнения объективно рассматривать обе стороны в рамках своего понимания.
Кстати, на моей памяти есть один язык, который действительно создавался с целью упростить жизнь программистам и сделать их более эффективными. И этот язык, как бы не забавно это прозвучало — PHP, как можно заметить, судя по статистике — с задачей он своей справляется «на ура».
Не только PHP. Один из первых — Forth. Автор Чак Мур искал продуктивности всю жизнь и так появился и эволюционировал его язык. История тут www.colorforth.com/HOPL.html а вообще да, PHP правильная вещь
Вы 10 лет пробовали все языки, но, если я правильно понял, С++ то вы так и не пробовали? Почему? «Пробовали» в смысле реальном, чтобы себя назвать С++ программистом. Или всё же было?
Поэтому мне удивительно, вы тут пишете про скорость, про мощь и рюшечки, а до этого заключили, что на скорость то вам и пофиг, вы же IDE пишете.
И снова, уповаете за продуктивность, чтобы просто и понятно, легко, всё было доступно, а выбрали Nim. У него хоть инфраструктура есть какая-нибудь? XML-ку там распарсить, с ОС как-нибудь удобно поработать?
Это всё я к тому, что на С++ можно писать очень быстро и продуктивно, не забираясь в дебри шаблонов, аллокаторов и т.д. даже в огромных программах. Особенно учитывая с++11 и его модель памяти.
А вообще, методология ваша хороша, и задачу вы себе поставили хорошую, но, боюсь, нерешаемую. Хоть вам и кажется, что вы нашли грааль)
Поэтому мне удивительно, вы тут пишете про скорость, про мощь и рюшечки, а до этого заключили, что на скорость то вам и пофиг, вы же IDE пишете.
И снова, уповаете за продуктивность, чтобы просто и понятно, легко, всё было доступно, а выбрали Nim. У него хоть инфраструктура есть какая-нибудь? XML-ку там распарсить, с ОС как-нибудь удобно поработать?
Это всё я к тому, что на С++ можно писать очень быстро и продуктивно, не забираясь в дебри шаблонов, аллокаторов и т.д. даже в огромных программах. Особенно учитывая с++11 и его модель памяти.
А вообще, методология ваша хороша, и задачу вы себе поставили хорошую, но, боюсь, нерешаемую. Хоть вам и кажется, что вы нашли грааль)
Ну С++ бывает разный. Это сейчас C++11 удобен и крут и есть много примеров хорошего кода на которых можно учиться, а в 90-х годах «писать на плюсах» подразумевало как правило что-то типа архиуебищного MFC, причем нормальных компиляторов у плюсов не было, и баги когда компилятор генерировал неверный код из верной программы не были чем-то из ряда вон выходящим
Поэтому говоря о плюсах многие понимают под этим разные вещи. Особенно если начинать на плюсах доводилось в 90-х :)
Поэтому говоря о плюсах многие понимают под этим разные вещи. Особенно если начинать на плюсах доводилось в 90-х :)
А часть Пи (3.14) будет?
А как находка такого замечательного языка отразится на вашей конторе (хотя бы в общих чертах), особенно учитывая(на сколько я знаю), что основные продукты/заказы вы делаете на jvm-based языках (java/fantom/scala)?
ровно так, как находка Java и eclipse отразилась на конторе во времена когда про eclipse мало кто знал. А eclipse foundation еще не был создан. Прекрасно отразится. Есть компании-конъюнктурщики. Как и программисты конъюнктурщики. Они подстраиваются под рынок. Есть те которые сами понимают что хорошо, а что плохо, и идут впереди рынка.
Очень понравились рассуждения про набор языковых фич и экосистему.
Однако, считаю, что следующая «большая вещь» будет вообще не вокруг языка. Те же (очень хорошие) примеры из этой статьи про Delphi и Java подтверждают этот тезис. И Delphi и Java — не были просто новыми языками. В тот момент когда они еще не имели экосистемы, они уже были гораздо больше платформами, чем языками. А язык был вторичен. И действительно, если продумать базис, платформу, то можно на нее хоть LISP натянуть, добавив больше или меньше фич. Та же Java — это, по-большому счету, упомянутый ранее Оберон с синтаксисом C, чья платформа была продумана на качественно новом уровне (но и сам Оберон как язык без Оберон-системы абсолютно бессмысленно рассматривать).
Жду рассказ про Nim и надеюсь, что в рассказе будет поднята также тема Nim как платформы, а не очередного языка, коих сейчас плодятся миллионами аж глаза разбегаются. Новых же платформ за последнии 10 лет, по большому счету, не появилось ни одной (или я не туда смотрю).
Идея же наслоится на существующие платформы (и для «браузера» и для «железа») мне кажется — не жилец.
Однако, считаю, что следующая «большая вещь» будет вообще не вокруг языка. Те же (очень хорошие) примеры из этой статьи про Delphi и Java подтверждают этот тезис. И Delphi и Java — не были просто новыми языками. В тот момент когда они еще не имели экосистемы, они уже были гораздо больше платформами, чем языками. А язык был вторичен. И действительно, если продумать базис, платформу, то можно на нее хоть LISP натянуть, добавив больше или меньше фич. Та же Java — это, по-большому счету, упомянутый ранее Оберон с синтаксисом C, чья платформа была продумана на качественно новом уровне (но и сам Оберон как язык без Оберон-системы абсолютно бессмысленно рассматривать).
Жду рассказ про Nim и надеюсь, что в рассказе будет поднята также тема Nim как платформы, а не очередного языка, коих сейчас плодятся миллионами аж глаза разбегаются. Новых же платформ за последнии 10 лет, по большому счету, не появилось ни одной (или я не туда смотрю).
Идея же наслоится на существующие платформы (и для «браузера» и для «железа») мне кажется — не жилец.
Так забавно читать, как автор смело лепит ярлыки а ля «мудак» на человека, который действует абсолютно правильно в его личной системе ценностей… Вроде бы взрослый человек, а категоричность как у 18-летнего юнца. Просто задумайтесь на секунду, что другие люди не лучше и не хуже — они просто другие. То же самое касается и языков программирования. И мир засияет новыми красками, девушки станут Вам чаще улыбаться, мужики будут чаще здороваться, Java перестанет быть прожорливой, а C перестанет быть средством для изощренного самоубийства.
А еще более забавно читать о том, как кто-то смеётся над двухцветной точкой зрения, заменяя её одноцветной. Это же классическая дилемма заключенного. Пока «мудак» один, он в выигрыше, но целое общество таких людей погребет само себя в пучину отчаяния.
Для взрослого человека (думаю и не только для взрослого) естественно иметь морально-этические принципы и делать некоторую градацию людей на их основе.
То, что сознательное завязывание проекта лично на себя, есть поступок сомнительный с этичной стороны дела, думаю согласятся многие.
P.S Люди, которые говорят что нет хорошего/плохого/правильного/не правильного/ (в рамках разумного контекста разумеется) мне всегда казались несколько странными.
То, что сознательное завязывание проекта лично на себя, есть поступок сомнительный с этичной стороны дела, думаю согласятся многие.
P.S Люди, которые говорят что нет хорошего/плохого/правильного/не правильного/ (в рамках разумного контекста разумеется) мне всегда казались несколько странными.
Вот именно! Как будто есть что-то плохое в том, чтобы работать на не самом популярном языке, чтобы получать больше денег и иметь меньше конкуренции. Не стоит забывать, что у это есть и обратная сторона — делая ставку на не самый популярный язык, программист берёт на себя риски.
Ну смотрите вы заказчик, наняли команду условных программистов. Они вам запилили за N время базу для проекта, вроде все работает. как надо. Запилили они на каком то малоизвестном языке(вы как заказчик можете и не разбираться популярный он, удобны и т.п.). Тут вам захотелось добавить функционала в систему. Простите команду добавить простую фичу, а это добавление занимает архи много времени.(Повторить предложение N раз) Вы понимаете что не может столько времени заниматься добавление такой фичи. Или команда начинает просить немыслимую сумму на поддержку. Далее можно вставить любую проблему из-за которой вы не хотите работать с этой командой программистов. Решаете найти другую команду, а таких команд либо нет, либо совсем мало и не кто не хочет браться за ваш проект.(Причина возможно цена, или команда сильно занята и не готова уделять нужное кол-во времени проекту).
Вот как назвать людей из первой команды? Конечно мудаки. Я думаю вот именно о таких людях автор говорит.
Вот как назвать людей из первой команды? Конечно мудаки. Я думаю вот именно о таких людях автор говорит.
Так автор же сам из этой же группы.
Он выбрал язык, на котром пишет, во всем мире, хорошо если несколько сотен человек.
Что делать его клиентам?
Он заставит своих сотрудников изучтать… вернее покупать акции неизвестной компании.
Которая, как ему кажется, вырастет в цене.
А люди будут покупать эти акции за самый дорогой ресурс в мире, за свое собственное время.
Сколько там игроков на бирже сливается в пух и прах?
Вот такой же процент людей, в его конторе, пойдет по миру с этими акциями.
Он выбрал язык, на котром пишет, во всем мире, хорошо если несколько сотен человек.
Что делать его клиентам?
Он заставит своих сотрудников изучтать… вернее покупать акции неизвестной компании.
Которая, как ему кажется, вырастет в цене.
А люди будут покупать эти акции за самый дорогой ресурс в мире, за свое собственное время.
Сколько там игроков на бирже сливается в пух и прах?
Вот такой же процент людей, в его конторе, пойдет по миру с этими акциями.
Окончание как в голливудских фильмах…
Глянул на Nim. Похож на Python по синтаксису. Будет теперь альтернатива для питона только на компиляторе уже. :)
Статья категорически не понравилась, слишком много пафоса. Но идея, которую автор хочет донести, возможно стоящая.
Языки с динамической типизацией дают какой-то положительный эффект в смысле продуктивности на старте, но очень быстро (с ростом размеров проекта) этот эффект проходит и обращается в проблемы. Большой проект на таком языке (включая Ruby) требует больше усилий на написание тестов, а программисту приходится помнить гораздо больше вещей, типа объекты какого типа принимает тот или иной метод. В общем для маленьких и быстрых проектов, типа консольных утилит, для прототипов и небольших веб-приложений, в качестве скриптового языка внутри некоей большой системы — да, Ruby и его коллеги очень хороший выбор. Для больших систем, я бы Ruby не брал.
Допустим, держать в голове нужно больше. А если вдруг, у вас есть дурацкая привычка комментировать методы с указанием типов принимаемых/возвращаемых аргументов и ваша любимая ИДЕ подсказывает если вы передаёте неправильный тип или на стадии вызова метода с помощью хоткея говорит, какой тип нужно передать? Тогда мы и производительность получаем от динамической типизации и от проблем «незнания» уходим. Да, компилятор/интерпретатор не сломается из-за неправильного типа, но это уже нужно рассматривать подходы к программированию, а не, опять же, языки.
А если вдруг, у вас есть дурацкая привычка комментировать методы с указанием типов принимаемых/возвращаемых аргументов и ваша любимая ИДЕ подсказывает
Это какой-то костыль… Хороший язык должен уметь, для некоторых особых случаях, динамическую типизацию, и статическую во всех прочих.
В принципе, на java можно эмулировать, передавая везде object.
А в c# 4.0 так вообще завели тип dynamic, который мало того, что хранит что угодно, так ещё и диспетчеризирует в подходящую ф-цию при вызове.
Скрытый текст
void test(dynamic a)
{
Run(a);
}
void Run(int z) { ... }
void Run(string s) { ... }
Не знаю, как на Ruby, но на том же Python местами приходится «комментировать» код нездоровым количеством ассертов, которые перегружают реализацию, выполняется двойная и тройная работа, продуктивность серьёзно проседает. Да, гибкость, за которую многое можно отдать. Но в крупном проекте — сложность растёт в итоге не только от сложности самого проекта и цена выходит за всякие разумные рамки, так что даже IDE тебя начинает посылать, приходится от «гибкости» отказываться везде, где действительно можно обойтись без неё — приходит просветление и трансцендентное осознание концепции KISS.
а программисту приходится помнить гораздо больше вещей, типа объекты какого типа принимает тот или иной метод.Это домыслы разработчиков статической типизации, на практике (конкретно в Питоне) проблем обычно не возникает, даже если залезть в чужой проект.
Даже если вы знаете какой тип передавать (со стат. типизацией), это не всегда поможет.
В принципе, у меня достаточно однозначный принцип определения субъективного «качества» языка — это тот же code quality measurement, что и для качества кода
Синтаксический сахар хорош тогда и только тогда, когда он не противоречит этому правилу. Поэтому Python у меня в обороте, а Ruby нет. И Typescript, а не Coffee и прочие диалекты.
Это я к чему собственно. Третий день играюсь с Nim'ом, и у меня все сильнее создается впечатление, что у автора во многом схожий подход. Я понимаю, как оно работает; понимаю, какой C-код он мне выдаст; понимаю, где в библиотеках копать в сторону того или иного куска. И как без ненужного геморроя перейти на уровень вниз (до plain c) я тоже понимаю, а это ой как немаловажно.
Не идеал, конечно, но прагматичный язык. Очень прагматичный.
Лайк
XKCD, если кто не знает
Синтаксический сахар хорош тогда и только тогда, когда он не противоречит этому правилу. Поэтому Python у меня в обороте, а Ruby нет. И Typescript, а не Coffee и прочие диалекты.
Это я к чему собственно. Третий день играюсь с Nim'ом, и у меня все сильнее создается впечатление, что у автора во многом схожий подход. Я понимаю, как оно работает; понимаю, какой C-код он мне выдаст; понимаю, где в библиотеках копать в сторону того или иного куска. И как без ненужного геморроя перейти на уровень вниз (до plain c) я тоже понимаю, а это ой как немаловажно.
Не идеал, конечно, но прагматичный язык. Очень прагматичный.
Лайк
Есть мнение, что Rust более строгий и дисциплинированный чем Nim:
habrahabr.ru/post/259993
habrahabr.ru/post/259993
Верное мнение, но непротиворечит ни сути статьи, ни комментарию
Фишка Rust в том, что он выносит приличную долю ловли блох на этап компиляции, а не отладки. У кого-то это создаёт впечатление сложности самого языка, который тяжело заставить собрать программу. Но на практике это означает лишь то, что программист, мнящий, что он ЗНАЕТ все входы и выходы в своей программе, на самом деле тешит себя в иллюзиями и будет собирать эти грабли чуть позже на этапе закрытия тяжелоуловимых багов, возможно вместо выходных, поскольку упало именно на продакшене и закрыть период нужно было ещё вчера.
Что ж, я так понимаю, в ближайшее время мы будем наблюдать захватывающий этап становления нескольких достойных языков, каждый из которых предлагает свой компромисс между простотой и дисциплиной и каждый по своему нацеленных на продуктивность.
Что ж, я так понимаю, в ближайшее время мы будем наблюдать захватывающий этап становления нескольких достойных языков, каждый из которых предлагает свой компромисс между простотой и дисциплиной и каждый по своему нацеленных на продуктивность.
Что я понял из статьи, пока хипстеры и всякая школота занимаются своими хипстерскими делами настоящие инженеры ипошат код не шурша.
А если серьезно очень интерсно было почитать рассужедния опытного инженера, благодраю.
А если серьезно очень интерсно было почитать рассужедния опытного инженера, благодраю.
Хорошая статья. Понравился пример с автомобилями :)
Бесполезный tl;dr про кодорелигию.
Как раз наоборот, про материалистический атеизм
Программирование — это решение задач на языке программирования. Критерии могут применяться только к двум вещам — задачам и решениям. Все остальное вам показалось.
Программирование, как и любая работа, это по большей части неприятное времяпровождение, за которое платят деньги.
К степени «неприятности» критерии тоже могут применяться.
К степени «неприятности» критерии тоже могут применяться.
>это по большей части неприятное времяпровождение
Только у тех, кто туда шел ради денег, а не потому что нравится процесс в первую очередь )
Только у тех, кто туда шел ради денег, а не потому что нравится процесс в первую очередь )
Ну не знаю, как показывает мой небольшой опыт, если моя работа мне в радость, то либо я работаю спустя рукава, либо я делаю совсем не то, что нужно заказчику, либо заказчик я сам.
В обычном режим работы — нужно качественно, вчера, и соответствовать вон тому взаимоисключающему списку требований от маркетолога — чувство «приятного времяпровождения» обычно значит, что ты занимаешьсяхерней самообразованием вместо работы.
В обычном режим работы — нужно качественно, вчера, и соответствовать вон тому взаимоисключающему списку требований от маркетолога — чувство «приятного времяпровождения» обычно значит, что ты занимаешься
Всегда можно найти такую работу, где не придется ненавидеть начальство и делать что-то интересное, вопрос лишь в Вашем желании что-то менять, а не сидеть на пригретом месте без преспектив годами)
Угу, а рисование — это нанесение красок на холст наиболее подходящим для этого предметом.
Отлично, оказывается мир программистов делится на три категори: мудаки, микроблогерры и «прочие заболевания». При этом автор относит себя ко всем трем одновременно… Весьма недурно.
Что до «лучшего языка» с «иконкой как у миранды» и недоросшим даже до пресловутой версии 1.0 — лет через 10 будет хоть что-то по нему ясно наверняка, пока нужно быть полным «микроблоггером», чтоб на него пересесть.
Что до «лучшего языка» с «иконкой как у миранды» и недоросшим даже до пресловутой версии 1.0 — лет через 10 будет хоть что-то по нему ясно наверняка, пока нужно быть полным «микроблоггером», чтоб на него пересесть.
Автор, так если вы так одержимы идеей идеального языка программирования, почему вы не создали свой?
Помимо картинки про 19 стандартов — это еще большая ответственность, и куча потраченного времени и денег, именно в таком порядке.
Думаю он просто не достаточно умен для этого.
Ну правда же звучит глупо — «Я знаю как создать идеальный язык, но я боюсь ответственности и мне жалко времени и денег»
Ну правда же звучит глупо — «Я знаю как создать идеальный язык, но я боюсь ответственности и мне жалко времени и денег»
- Автор статьи действительно не знает, каким должен быть идеальный язык программирования, он знает лишь для чего ему язык, и как он отличает плохой язык от хорошего. Поэтому автор в статьях пишет, что он искал язык
- Как человек который делал продукты, которым пользуются другие люди я прекрасно понимаю mjr27, имеется ввиду что создав язык вы берете на себя ответственность его поддерживать, развивать, общаться с пользователями, учить и так далее. Вы будуте ответственны перед людьми, которые в вас поверили и положились на ваш продукт. И это помимо времени (и денег) которых действительно жалко. Время в жизни ограниченно и у меня есть много более приоритетных хотелок. Не знаю зачем я вам ответил, вы очевидно даже близко не оказывались в таких ситуациях, когда люди боятся ответственности, и жалеют время
Почему это не оказывался? Оказывался. Просто по характеру ваших сообщений мне показалось, что если бы вы были уверены, что знаете как сделать идеальный язык — вы бы этих вещей не пожалели.
В конце концов вы писали про 20 лет занятием программирования за деньги, и на сколько я мог понять этот способ заработка вам вполне нравится (с точки зрения получения удовольствия от работы).
В конце концов вы писали про 20 лет занятием программирования за деньги, и на сколько я мог понять этот способ заработка вам вполне нравится (с точки зрения получения удовольствия от работы).
Зря не поставили тэг «философия программирования», поддержали жизнь в тэге.
А еще это называется свобода.
Нет, сэр, это ваша зависимость, а не свобода)
Судя по обилию негатива в статье автор явно на кого-то обижен. Бывает, не с теми людими работал.
У меня другая ситуация по сложности понимания кода — коллеги не успевают за уровнями абстракции, так как им лень учиться, и поэтому считают мой код сложным, хотя продуктивность зашкаливает. Редкие языки/паттерны выбираются, всё же, чаще не для того, чтобы кого-то ввести в заблуждение, а чтобы решить задачу естественно и подходящими для неё средствами. Точно так же, как хороший писатель обладает большим словарным запасом, Войну и мир не описать в 1000 слов. Если у читателя словарный запас меньше — значит нужно тянуться вверх, а не ныть.
У меня другая ситуация по сложности понимания кода — коллеги не успевают за уровнями абстракции, так как им лень учиться, и поэтому считают мой код сложным, хотя продуктивность зашкаливает. Редкие языки/паттерны выбираются, всё же, чаще не для того, чтобы кого-то ввести в заблуждение, а чтобы решить задачу естественно и подходящими для неё средствами. Точно так же, как хороший писатель обладает большим словарным запасом, Войну и мир не описать в 1000 слов. Если у читателя словарный запас меньше — значит нужно тянуться вверх, а не ныть.
Стоит ли ожидать IDE от твоей компании для этого языка в ближайшее время?
> С одной стороны все выглядет красиво, качественно, я бы сказал восхитительно, с другой стороны — вот тут же можно было переиспользовать, и тут, и тут, вот тут вообще чуваки сознательно копи-пастят.
Ничего страшного, у начинающего программиста половина кода это быдлокопипаста. А почему? Потому что она ему понятна и понятно как ее делать и править, он не пытается казаться умнее чем он есть.
У зрелого программиста все высушено до предела.
У настоящего профессионала копипаста — это инструмент со своими плюсами и ограничениями без предвзятого отношения. Он понимает что преждевременный DRY — это преждевременная оптимизация, он дает дублирующимся кускам отстояться, вдруг они все-таки разъедутся при дальнейших изменениях и умеет определять места с такими рисками, чтобы, например не разгребать потом деревья из классов, в каждом из которых поменялось по строчке в каждом из методов. А какая мякотка какие ни будь корневые классы в приложении, на которые просто стараются не дышать, так как никто не сможет предсказать последствия по всему дереву наследования.
Или есть два продукта, из них кусок кода был вынесен в либу с низкой сцепленностью того что она делает, просто чтобы код не дублировать. Для одного из продуктов возникла необходимость в либе кое-что поправить. Сколько продуктов при этом нужно будет тестировать, один или два?
Основная задача программиста — снижать сложность, если избавление от копипасты сложность увеличивает, а поддерживаемость уменьшает, то, возможно, оно не нужно.
Ничего страшного, у начинающего программиста половина кода это быдлокопипаста. А почему? Потому что она ему понятна и понятно как ее делать и править, он не пытается казаться умнее чем он есть.
У зрелого программиста все высушено до предела.
У настоящего профессионала копипаста — это инструмент со своими плюсами и ограничениями без предвзятого отношения. Он понимает что преждевременный DRY — это преждевременная оптимизация, он дает дублирующимся кускам отстояться, вдруг они все-таки разъедутся при дальнейших изменениях и умеет определять места с такими рисками, чтобы, например не разгребать потом деревья из классов, в каждом из которых поменялось по строчке в каждом из методов. А какая мякотка какие ни будь корневые классы в приложении, на которые просто стараются не дышать, так как никто не сможет предсказать последствия по всему дереву наследования.
Или есть два продукта, из них кусок кода был вынесен в либу с низкой сцепленностью того что она делает, просто чтобы код не дублировать. Для одного из продуктов возникла необходимость в либе кое-что поправить. Сколько продуктов при этом нужно будет тестировать, один или два?
Основная задача программиста — снижать сложность, если избавление от копипасты сложность увеличивает, а поддерживаемость уменьшает, то, возможно, оно не нужно.
Сколько надо бухнуть чтобы все это с комментариями дочитать до конца?))Пойду…
Ты мне все больше нравился до этой статьи (:
А тут ненаязчиво наехал на перл.
А если по делу, стоит еще не забывать, что многие выпускники или студенты, приходящие в конторы, заражаются говнецом в тех же вузах. А проблема всегда одна и та же — подверженность авторитетам. Он всегда найдет, как утенок, за кем топать.
Вот раньше была трава зеленеее были хакерские форумы, где интересующаяся молодежь попадала в гностический рай: куча молодых и не очень людей, объединяющихся в свободное сообщество любящих получать знания. Обменивающиеся информацией, пишущие статью и о программировании, администрировании, взломе и т.д. На таком огромном объеме разнородной информации и формировались собственные вкусы, выборы языка, профессиональное мировоззрение. Плюсом прививались полезные вещи вроде стремления писать качественный код, безопасные инструменты, применять и создавать свободные решения. Конечно, бизнесу нет особой потребности в хакерах, поэтому нынче есть ит-спецухи в вузах и хабрахабр (:
А тут ненаязчиво наехал на перл.
А если по делу, стоит еще не забывать, что многие выпускники или студенты, приходящие в конторы, заражаются говнецом в тех же вузах. А проблема всегда одна и та же — подверженность авторитетам. Он всегда найдет, как утенок, за кем топать.
Вот раньше была трава зеленеее были хакерские форумы, где интересующаяся молодежь попадала в гностический рай: куча молодых и не очень людей, объединяющихся в свободное сообщество любящих получать знания. Обменивающиеся информацией, пишущие статью и о программировании, администрировании, взломе и т.д. На таком огромном объеме разнородной информации и формировались собственные вкусы, выборы языка, профессиональное мировоззрение. Плюсом прививались полезные вещи вроде стремления писать качественный код, безопасные инструменты, применять и создавать свободные решения. Конечно, бизнесу нет особой потребности в хакерах, поэтому нынче есть ит-спецухи в вузах и хабрахабр (:
Хотелось бы заметить, что продуктивность хоть и связана с языком довольно тесно, но не определяется им (как только языком) на 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). Исключать эти вещи, говоря про продуктивность, по меньшей мере недальновидно.
Например, существование большого количества разнообразных библиотек и обширное коммьюнити языка, как, например, сейчас есть у 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). Исключать эти вещи, говоря про продуктивность, по меньшей мере недальновидно.
К этому хочу добавить, что, по моему мнению, хороший язык достаточно строг для того, чтобы своим синтаксисом/библиотекой направлять человека в сторону best practices, делая следование им проще и удобней, чем ортогональный им код.
И под языком я сейчас имею совокупность самого языка, инфраструктуры и библиотек.
Вот, например, PHP. Хороший пример языка, в котором долгие годы «лучшие практики» было проще не использовать, чем пытаться внедрять. Ну как пример — мне года три назад достался проект, написанный, по ощущениям, матёрым C-шником с функциями по 1500 строк и классами как неймспейсами для функций. Так вот даже PHP в последние годы продвинулся вперед настолько, что диву даешься. Спасибо composer, спасибо разработчикам, довевшим до ума ООП до актуального состояния вместо карго-культа 4 и 5.0 версий. И огромное спасибо разработчикам человеческих фреймворков на смену ZF, Symfony 1, Doctrine и прочему трешу.
И под языком я сейчас имею совокупность самого языка, инфраструктуры и библиотек.
Вот, например, PHP. Хороший пример языка, в котором долгие годы «лучшие практики» было проще не использовать, чем пытаться внедрять. Ну как пример — мне года три назад достался проект, написанный, по ощущениям, матёрым C-шником с функциями по 1500 строк и классами как неймспейсами для функций. Так вот даже PHP в последние годы продвинулся вперед настолько, что диву даешься. Спасибо composer, спасибо разработчикам, довевшим до ума ООП до актуального состояния вместо карго-культа 4 и 5.0 версий. И огромное спасибо разработчикам человеческих фреймворков на смену ZF, Symfony 1, Doctrine и прочему трешу.
И тем не менее, у языка есть _изначальные_ проблемы, которые каждый программист должен преодолевать over and over again. После версии 1.0 никакими позднейшими доработками это не исправишь. Как строковые функции в PHP, как работа со строками в пайтоне 3.х и т.п. Так что язык тоже определяет продуктивность.
А что в пайтоне 3? Мне очень нравится, как там строки сделали, по сравнению с python 2.
Может в 3.2+ что-от изменилось, не особо слежу в последний год, но до этого новые строки очень плохо жили в реальном мире битых и неизвестных кодировок.
Вот немного чужого батхёрта на эту тему
Вот немного чужого батхёрта на эту тему
Если под продуктивностью понимать способность решить задачу за минимальное время при помощи данной технологии, то не следует забывать, что решение задачи состоит из следующих фаз:
Архитектура
Прототипирование
Написание кода
Тестирование
Поддержка
Язык как таковой может оптимизировать фазу написания кода, однако не факт, что сопутствующая технология проявит себя так же хорошо в остальных фазах.
Автор упомянул экосистему. Это как раз решающий фактор производительности, когда кусок кода можно заменить одним вызовом сторонней библиотеки. Библиотеки и фреймворки расширяют язык новым функционалом. Экосистема Java одна из самых развитых, и пробовать что-либо вне ее достаточно рискованно, если это не очень узкоспециализированная задача.
На сегодняшний день проблема Java как языка в отсутствии возможности семантического расширения, иначе говоря создания DSLей. Стандартное решение ввиде аннотированного кода плохо: из одних аннотаций невозможно создать семантически связанную струтуру. Альтернатива не лучше: использовать сторонний дескриптор XML, который хоть и связан семантически (XSD), но никак не связан с аннотируемым кодом.
Архитектура
Прототипирование
Написание кода
Тестирование
Поддержка
Язык как таковой может оптимизировать фазу написания кода, однако не факт, что сопутствующая технология проявит себя так же хорошо в остальных фазах.
Автор упомянул экосистему. Это как раз решающий фактор производительности, когда кусок кода можно заменить одним вызовом сторонней библиотеки. Библиотеки и фреймворки расширяют язык новым функционалом. Экосистема Java одна из самых развитых, и пробовать что-либо вне ее достаточно рискованно, если это не очень узкоспециализированная задача.
На сегодняшний день проблема Java как языка в отсутствии возможности семантического расширения, иначе говоря создания DSLей. Стандартное решение ввиде аннотированного кода плохо: из одних аннотаций невозможно создать семантически связанную струтуру. Альтернатива не лучше: использовать сторонний дескриптор XML, который хоть и связан семантически (XSD), но никак не связан с аннотируемым кодом.
Что-то я сомневаюсь, что Martin Odersky преследовал какие-то цели в духе «навредить, разрушить, сделать назло и т.д.». Человек просто экспериментировал и пытался создать хороший язык с кучей фич. И надо сказать ему это удалось. На Scala уже написано очень много всего, как либ/фрэймворков так и проектов. Если говорить о продуктивности, я сомневаюсь что Twitter решили переписать свою экосистему на непродуктивном и чересчур сложном языке…
На Nim пока не видно крупных проектов(ну или может быть я не в курсе). Время покажет насколько это «идеальный» язык…
На Nim пока не видно крупных проектов(ну или может быть я не в курсе). Время покажет насколько это «идеальный» язык…
Сначала статья очень понравилась. Нашёл в себе злобствующего микроблогера, очень злобствующего… буду «лечиться». До хеш-таблиц с другой планеты не дошло, я не безнадёжен, слава Богу, но реально написал катастрофически мало рабочего кода, почти весь в теории, в планах, в поиске волшебной палочки, был. И вот за это — большое и искреннее спасибо. Люблю C#. Плохой код не люблю. Поэтому торможу с практикой. Но в итоге мог бы превратиться в совсем кошмарного микроблогера. А это гадостно.
Но без ложки дёгтя не обойдётся. В какой-то момент мне показалась предвзятость к дженерикам. По-моему всё проще: «Не нравится — не ешь», а нравится и подходит если, то и хорошо. То есть раз уж ЯП инструмент, то разным инструментам и руки разные. Кто-то любит гонять до 100 за 5 секунд, а кто-то — ювелир. А кто-то пианист, а кто-то — шахтёр. И так далее…
И вообще, некая антипатия к плюсам, корнями из тех самых девяностых, видимо. Есть же boost, есть Qt. Есть гора Линуксового кода, уже готового.
Вот как-то так. И ещё раз спасибо. Большое.
Но без ложки дёгтя не обойдётся. В какой-то момент мне показалась предвзятость к дженерикам. По-моему всё проще: «Не нравится — не ешь», а нравится и подходит если, то и хорошо. То есть раз уж ЯП инструмент, то разным инструментам и руки разные. Кто-то любит гонять до 100 за 5 секунд, а кто-то — ювелир. А кто-то пианист, а кто-то — шахтёр. И так далее…
И вообще, некая антипатия к плюсам, корнями из тех самых девяностых, видимо. Есть же boost, есть Qt. Есть гора Линуксового кода, уже готового.
Вот как-то так. И ещё раз спасибо. Большое.
Самая короткая дорога — та которую знаешь.
Знаешь хорошо C++ и умеешь его использовать — быстрее и качественнее напишешь на C++.
Знаешь хорошо Java и умеешь его использовать — быстрее и качественнее напишешь на Java
и т.д…
Думаю, что автор, утверждая:
«Ну да ладно, вот и я как бы повелся, что надо бы писать на плюсах, наелся гавна (в том смысле что вместо того, чтобы программировать — думал за компилятор, скрещал библиотеки, и так далее). Слава богу у меня была производственная возможность плюнуть на все и переписать на Java»
просто констатирует, что на тот момент не знал хорошо C++ и не умел его использовать (не знал тонкостей компилятора и подключения библиотек). Посему выбрал для себя самое верное решение — освоить что-нибудь попроще… и Java оказалась именно такой.
Поэтому непререкаемый вывод:
1. В работе используй только то — что хорошо знаешь и умеешь
2. В свободное время — увеличивай новые знания и умения до уровня «хорошо», чтоб можно было использовать в п.1
3. Если ничего не знаешь и не умеешь — ищи самое простое и быстрое, чему можешь научиться для решения поставленной задачи и переходи на п.2.
Языки программирования и их ЭКО-среда — это как раз, то, что надо хорошо знать и уметь быстро использовать, если Вы отваживаетесь называть себя величественным словом «Программист» ;)
Знаешь хорошо C++ и умеешь его использовать — быстрее и качественнее напишешь на C++.
Знаешь хорошо Java и умеешь его использовать — быстрее и качественнее напишешь на Java
и т.д…
Думаю, что автор, утверждая:
«Ну да ладно, вот и я как бы повелся, что надо бы писать на плюсах, наелся гавна (в том смысле что вместо того, чтобы программировать — думал за компилятор, скрещал библиотеки, и так далее). Слава богу у меня была производственная возможность плюнуть на все и переписать на Java»
просто констатирует, что на тот момент не знал хорошо C++ и не умел его использовать (не знал тонкостей компилятора и подключения библиотек). Посему выбрал для себя самое верное решение — освоить что-нибудь попроще… и Java оказалась именно такой.
Поэтому непререкаемый вывод:
1. В работе используй только то — что хорошо знаешь и умеешь
2. В свободное время — увеличивай новые знания и умения до уровня «хорошо», чтоб можно было использовать в п.1
3. Если ничего не знаешь и не умеешь — ищи самое простое и быстрое, чему можешь научиться для решения поставленной задачи и переходи на п.2.
Языки программирования и их ЭКО-среда — это как раз, то, что надо хорошо знать и уметь быстро использовать, если Вы отваживаетесь называть себя величественным словом «Программист» ;)
Но, согласитесь, коллега, в C++ есть проблема с подключением библиотек, не так ли? :)
Если человек не знает, как подключить НУЖНЫЕ для решения задачи библиотеки — то конечно, проблема есть.
Если человек знает — проблемы нет.
Весь вопрос в том — обладает ли человек необходимыми знаниями? ;)
То, что некоторые библиотеки плохо совместимы — это часть знаний человека.
То, что существует много библиотек и в проекте лучше использовать хорошо известные и совместимые библиотеки — тоже часть знаний человека.
И наконец, если уж очень при очень требуется использовать в одном проекте плохо совместимые библиотеки (что практически сразу является огромным просчетом в архитектуре проекта) — то их адаптация, это тоже — часть знаний человека
Отсюда вывод:
Если человек — это программист C++, то он по определению обладает этими знаниями и у него проблем нет.
Если человек — это НЕ программист C++, то у него будут проблемы, пока он не получит нужных знаний и не станет программистом C++ :)
Труд — делает из обезьяны человека.
Знания — делают из человека программиста ;)
Если человек знает — проблемы нет.
Весь вопрос в том — обладает ли человек необходимыми знаниями? ;)
То, что некоторые библиотеки плохо совместимы — это часть знаний человека.
То, что существует много библиотек и в проекте лучше использовать хорошо известные и совместимые библиотеки — тоже часть знаний человека.
И наконец, если уж очень при очень требуется использовать в одном проекте плохо совместимые библиотеки (что практически сразу является огромным просчетом в архитектуре проекта) — то их адаптация, это тоже — часть знаний человека
Отсюда вывод:
Если человек — это программист C++, то он по определению обладает этими знаниями и у него проблем нет.
Если человек — это НЕ программист C++, то у него будут проблемы, пока он не получит нужных знаний и не станет программистом C++ :)
Труд — делает из обезьяны человека.
Знания — делают из человека программиста ;)
люблю такие статьи от души, благодарю
Хотелось бы узнать мнение автора о D, особенно в сравнения с Nim. Дело в том, что я тоже года два назад столкнулся с вопросом поиска идеального языка и для себя нашел D.
Насколько я понял мнение автора, если человек использует D, то он мудак
Простите, но тут сплошной разброд и шатание, а не статья. Автор бегает вокруг, брюзжет на всё подряд, попутно не забывая показать свой многолетний опыт и навыки.
Слово «продуктивность» упоминается чуть ли не в каждом предложении, в то время как качеству, надёжности и производительности почти не уделено внимание (типа, железо уже сильное, не парьтесь). Создаётся вполне определённое впечатление о том, какого рода код пишет автор и его команда. Это код, измеряемый строчками в секунду… Быстрее, больше, ещё больше!
Слово «продуктивность» упоминается чуть ли не в каждом предложении, в то время как качеству, надёжности и производительности почти не уделено внимание (типа, железо уже сильное, не парьтесь). Создаётся вполне определённое впечатление о том, какого рода код пишет автор и его команда. Это код, измеряемый строчками в секунду… Быстрее, больше, ещё больше!
Естественно продуктивность будет в каждом предложении.
Видел я таких «продуктивных» разработчиков. Не один раз.
Из разряда «Я за три дня зафигарил проект».
Смотришь в код и видишь там 1 класс и 4 метода… на 9000 строк кода)
Но начальник (заказчик) просто ссыыт кипятком, какой крутой инженер, всем брать с него пример!
Видел я таких «продуктивных» разработчиков. Не один раз.
Из разряда «Я за три дня зафигарил проект».
Смотришь в код и видишь там 1 класс и 4 метода… на 9000 строк кода)
Но начальник (заказчик) просто ссыыт кипятком, какой крутой инженер, всем брать с него пример!
Справедливости ради — если проект не будет поддерживаться, то почему нет?
Ха, я видел наоборот, когда на 100 строк необходимого кода восемь слоёв абстракции и два десятка интерфейсов, ещё в два раза больше классов, в каждом туча бесполезных методов. Если что-то надо добавить, то править приходится сквозь все восемь уровней абстракции.
Иногда в продуктивность вкладывают качество получающегося продукта. Если на выходе нет качества, о какой продуктивности может идти речь?
Это Архитекторы и Performance Гики могут после «продуктивной» работы деливерить тормозящие абстрактные фабрики для прошивки утюга и неподдерживаемые системы документооборота на ассемблере.
Это Архитекторы и Performance Гики могут после «продуктивной» работы деливерить тормозящие абстрактные фабрики для прошивки утюга и неподдерживаемые системы документооборота на ассемблере.
Спасибо за статью. Возможно, взгляд субъективный, но заряд, который заложен в этом порыве субъективности — это бомба. Зарядили на новые свершения.
На мой взгляд, мысли верные и применимы во всем. Двигатель внутреннего сгорания создавался автором вовсе не для того, чтобы им любовались, а для трех конкретных вещей: перестать мучать лошадей, в разы поднять производительность и как следствие — скорость, и третье — улучшить процессы, с этим связанные.
На мой взгляд, мысли верные и применимы во всем. Двигатель внутреннего сгорания создавался автором вовсе не для того, чтобы им любовались, а для трех конкретных вещей: перестать мучать лошадей, в разы поднять производительность и как следствие — скорость, и третье — улучшить процессы, с этим связанные.
Сумбурное, эмоциональное и немного скомканное изложение трех тезисов в трех статьях:
1. Автору не нравятся динамические языки.
2. Автору нравятся стройные языки.
3. Автор нашел новую любовь, Nim.
:-) А вообще да, Nim ничего, конечно, приятный, особенно после Scala и, тем более, Java. Не боитесь, что Rust его задавит?
1. Автору не нравятся динамические языки.
2. Автору нравятся стройные языки.
3. Автор нашел новую любовь, Nim.
:-) А вообще да, Nim ничего, конечно, приятный, особенно после Scala и, тем более, Java. Не боитесь, что Rust его задавит?
вот да, ничего не имею против того, что люди или я могу писать на ниме, но ощущается, как очередное выставление своего субъективного в объективного. ЯП — это скорее способы мышления в контексте разработки ПО. И привычнее полагать, что люди разные. Соответственно, инструменты разные, и для разных людей тот или иной инструмент может быть или удобен или нет. Я не имею ввиду нарушения логики, но скорее более «высокоуровненые» вещи. Все, как всегда, сводится к фразе: «На вкус и цвет фломастеры разные». Но в целом статьи неплохие. Человек изначально показал свои установки и ценности в данном контексте. Далее он просто перебирал языки и «примерял» их на себя. Как минимум бует полезно для программистов со схожими взглядами.
Так получилось, что прочитал все три части в один день, практически друг за другом. И постоянно в голове крутилась картинка, в которой автор читает свой текст, как монолог. Причем делает это очень нервно, эмоционально, порой сбивчиво, с большими паузами и ударениями, в стиле тарантиновских, наверное, персонажей.
Но в целом было интересно, спасибо, хоть автор и перл мимоходом обидел :)
Но в целом было интересно, спасибо, хоть автор и перл мимоходом обидел :)
Мне кажется что выбор ЯП имеет довольно опосредованное влияние на производительность программиста.
На первом месте все равно будут инструменты: это в первую очередь IDE, юнит-тесты, CI.
В этом смысле например swift или F# очень круты, так как позволяют сразу увидеть результат. Но это не столько заслуга языка, сколько его interpreter.
Например, в моём случае (.net) освоение решарпером удвоило мою производительность.
На первом месте все равно будут инструменты: это в первую очередь IDE, юнит-тесты, CI.
В этом смысле например swift или F# очень круты, так как позволяют сразу увидеть результат. Но это не столько заслуга языка, сколько его interpreter.
Например, в моём случае (.net) освоение решарпером удвоило мою производительность.
Вдвое? Ох, любят люди громкие слова :)
«Как я увеличила свой бюст на три дюйма»
Человек фактически открыл для себя рефакторинг. Немудрено. Могло и больше, чем удвоить.
Подозреваю, дело было не в умении реструктурировать или чистить код… :-)
А в чём? Хотя, по моему опыту, умение писать быстрее, писать лучше и постоянно поддерживать код в хорошем состоянии вырабатывается довольно быстро при освоении средств автоматизированного рефакторинга.
Мне просто интересно стало, почему вдруг необходимость поддерживать код в адекватном состоянии стала связана с доступностью того или иного вспомогательного инструмента.
Это я к связи фраз «человек фактически открыл для себя рефакторинг» и «освоение решарпера».
Это я к связи фраз «человек фактически открыл для себя рефакторинг» и «освоение решарпера».
Насколько я понял, именно о «необходимости» речи не шло, только о способности — про необходимость освоения решарпера или повышения производительности в исходном комментарии написано не было. Была бы необходимость — сразу бы специально объяснили или приняли бы другие меры. А тут — просто человек вдруг узнал, что чистый код можно писать довольно легко и не отходя от практики «скачала пиши код, потом 'причёсывай' его». Имея возможность легко улучшать дизайн кода после его написания, человек поупражнялся и в дизайне кода самом по себе и приобрёл навыки написания более чистого когда сразу, «с листа».
А расскажите, пожалуйста, что сейчас в решарпере вы используете? А то я внезапно отказался от решарпера полгода назад по причинам плохой производительности компьютера и до сих у меня есть только две основные проблемы: инжект зависимостей через конструктор и выделение класса в новый файл (но на это есть легковесный плагин). Раньше без него жизнь не мыслил, а сейчас не могу вспомнить, что ж там такое офигенное было.
Исходя из теоремы Гёделя о неполноте, можно заключить, что не существует языка программирования крутость (эффективность, красивость, элитарность… нужное подчеркнуть) которого можно доказать только исходя из анализа фич, синтаксиса и чего угодно еще только лишь этого языка. Крутость языка начинает иметь смыслы только с введением внешней системы, то есть с добавлением программиста. Следовательно, для разных пар «язык — программист» доказано будет крутость разных языков. Так о чем спор? ;)
Ну не знаю.
Меня C++ вполне устраивает.
Ведь для него же есть Qt! Значит 3-30 кнопок я — одним махом!) С любой логикой)
Плюс огромная потенциальная мощь, которую я пользую 10%, но она есть!
Да GC нет, но он мне как то и не особо нужен, к тому же есть умные указатели, к тому же есть вроде как фреймворки с GC на борту. К тому же GC в плюсы грядет в 17 стандарте (или выше).
Не хочу я перескакивать на др. язык, тем более что 90% библиотек, фреймворков и т.д. написаны либо на C либо на плюсах.
Меня C++ вполне устраивает.
Ведь для него же есть Qt! Значит 3-30 кнопок я — одним махом!) С любой логикой)
Плюс огромная потенциальная мощь, которую я пользую 10%, но она есть!
Да GC нет, но он мне как то и не особо нужен, к тому же есть умные указатели, к тому же есть вроде как фреймворки с GC на борту. К тому же GC в плюсы грядет в 17 стандарте (или выше).
Не хочу я перескакивать на др. язык, тем более что 90% библиотек, фреймворков и т.д. написаны либо на C либо на плюсах.
В чём преимущество GC перед RAII со смарт-поинтерами? C++11/14 — уже всё, если забыть про raw pointers, то утечек быть не должно (только вместе с мозгом быдлокодера).
GC разрешает проблему циклических ссылок.
Реализовано примерно так:
В отдельном потоке крутится в цикле со спячками или без некий код, который проходит по графу зависимостей «ссылка-объект-ссылка» пытаясь найти те объекты, до которых он не может добраться.
Ну например, есть объект A, который держит объект B, который держит объект C, который держит объект B. Удаляем B из A (закончилась область действия A) — GC декрементирует счетчик и если счетчик не станет нулем, попытается в отдельном потоке добраться из корня графа до B, если не сможет или такого корня нет, то удалит B, а затем и C.
Как то так.
Политик управления можно множество придумать.
Ну и ничто же ведь не мешает написать фреймворк/библиотечку со смарт-поинтерами и запускающимся GC в отдельном потоке. (ну там и аллокатор памяти, разумеется). Три-в-одном.
Хочешь, подключай инклуд и пользуйся, хочешь подключай инклуд — не пользуйся этими смартами, — GC будет просто спать.
Реализовано примерно так:
В отдельном потоке крутится в цикле со спячками или без некий код, который проходит по графу зависимостей «ссылка-объект-ссылка» пытаясь найти те объекты, до которых он не может добраться.
Ну например, есть объект A, который держит объект B, который держит объект C, который держит объект B. Удаляем B из A (закончилась область действия A) — GC декрементирует счетчик и если счетчик не станет нулем, попытается в отдельном потоке добраться из корня графа до B, если не сможет или такого корня нет, то удалит B, а затем и C.
Как то так.
Политик управления можно множество придумать.
Ну и ничто же ведь не мешает написать фреймворк/библиотечку со смарт-поинтерами и запускающимся GC в отдельном потоке. (ну там и аллокатор памяти, разумеется). Три-в-одном.
Хочешь, подключай инклуд и пользуйся, хочешь подключай инклуд — не пользуйся этими смартами, — GC будет просто спать.
У смарт-поинтеров, реализованных подсчётом ссылок, низкая производительность (при передаче указателя куда-то нужно делать запись в объект, увеличивая число ссылок), для многопоточных систем использовать блокирующий Interlocked*
GC разбирает циклические ссылки, которые в случае со смарт-поинтерами надо делать указателями разных типов.
В этом случае надо понимать, кто чем владеет и использовать правильные типы. То есть, есть шанс ошибиться, когда в языках с gc можно вообще эти тонкости не держать в голове.
GC разбирает циклические ссылки, которые в случае со смарт-поинтерами надо делать указателями разных типов.
В этом случае надо понимать, кто чем владеет и использовать правильные типы. То есть, есть шанс ошибиться, когда в языках с gc можно вообще эти тонкости не держать в голове.
Подождите. Да, подсчёт ссылок накладывает какой-то overhead. Не будем спорить, какого его влияние. Но очевидно же, что GC всегда и во всех языках будет гораздо дороже, чем refcounting, я правильно мыслю?
(Про многопоточность: управляющий блок shared_ptr'а потокобезопасен, основан на атомиках.)
(Про многопоточность: управляющий блок shared_ptr'а потокобезопасен, основан на атомиках.)
Но очевидно же, что GC всегда и во всех языках будет гораздо дороже, чем refcounting
Мне не очевидно. Наверняка есть ситуации, когда памяти хватает и до сборки мусора дело просто не дойдёт.
Кроме того, malloc/free вызываются часто и понемногу, а gc работает «оптом»
управляющий блок shared_ptr'а потокобезопасен, основан на атомиках
И это плохо, потому что atomic, или же interlocked-операции, медленные (см. «главный злодей» тут). Если известно, что некоторые объекты не участвуют в конкурентном доступе, стандартный shared_ptr для них не оптимален.
atomic-операции медленные только в контексте отдельных ассемблерных инструкций.
На практике в подавляющем большинстве случаев оверхед очень мал, примерно между L1 cache miss и L2 cache miss. Проблемы возникают в основном при наивной реализации spinning mutex-ов когда один из потоков начинает непрерывно проверять залоченную кем-то память через атомики.
Применительно к плюсам — у shared_ptr проблем с производительностью при грамотном использовании нет. Достаточно не копировать shared_ptr без необходимости (скажем передавая его by-value повсюду) и все будет ОК. Банально нету ни в одной разумной программе такого количества операций «take/release ownership» чтобы это начало существенно сказываться на производительности.
На практике в подавляющем большинстве случаев оверхед очень мал, примерно между L1 cache miss и L2 cache miss. Проблемы возникают в основном при наивной реализации spinning mutex-ов когда один из потоков начинает непрерывно проверять залоченную кем-то память через атомики.
Применительно к плюсам — у shared_ptr проблем с производительностью при грамотном использовании нет. Достаточно не копировать shared_ptr без необходимости (скажем передавая его by-value повсюду) и все будет ОК. Банально нету ни в одной разумной программе такого количества операций «take/release ownership» чтобы это начало существенно сказываться на производительности.
Это так. Я пришёл к более радикальному выводу, что передавать смарт-поинтеры в качестве параметра ф-ции никогда не нужно, ни по ссылке, ни по значению. Достаточно обычного
Вызывающий ф-цию код владеет объектом, поэтому до окончания вызова объект не исчезнет.
[const] T*Вызывающий ф-цию код владеет объектом, поэтому до окончания вызова объект не исчезнет.
Если ф-я меняет state а не просто возвращает значение, то иногда все же нужно передавать туда смарт-поинтер который она где-нибудь сохранит. Но в целом да, подавляющему большинству функций удобно передавать на вход ссылки, реже — указатели.
Передавать можно, а иногда и нужно (когда он там дальше передаётся).
Передавать лучше по
Передавать лучше по
T&& (если в шаблонную).Избыточные write-операции, которые приходится делать счётчику ссылок, это плохо. Объясню, почему. Например, имеем большую коллекцию не изменяющихся объектов (которая вся не помещаются в кеш), на объекты делаются смарт-указатели. Если бы указатели были без подсчёта ссылок, при вытеснении старых объекток из кеша, на их место были бы загружены новые. Но с подсчётом ссылок кеш-линия помечается как изменившаяся и при вытеснении сначала её надо выгрузить в RAM.
Ну а сборка мусора у GC вынуждает обходить практически всю аллоцированную память, и? Мало того что это изначально дает изрядные периодические тормоза которые далеко не везде допустимы, так это еще и создает поистине эпические проблемы при попытке задействования своп-файлов. На плюсах при необходимости можно эффективно работать с десятками гигабайт памяти через memory-mapped файлы при небольших объемах физической тогда как та же Java практически вынуждена довольствоваться только доступной физической памятью.
Ну а сборка мусора у GC вынуждает обходить практически всю аллоцированную память, и?Давно не так. Есть поколения, есть dirty checking.
еще и создает поистине эпические проблемы при попытке задействования своп-файлов. На плюсах при необходимости можно эффективно работать с десятками гигабайт памяти через memory-mapped файлы при небольших объемах физической тогда как та же Java практически вынуждена довольствоваться только доступной физической памятью.В тех задачах, где хочется использовать mmap в java используется nio (FileChannel, ByteBuffer etc) и off-heap storage (который может быть написан с использованием nio или native расширений).
Давно не так. Есть поколения, есть 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 расширений).
Верю. Проблема в том что в плюсах это делается и проще и эффективнее.
То, что вы говорите — абсолютно верно. С одной существенной оговоркой: на большинстве задач большинства пользователей этих проблем нет. И принципиально ситуация до 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 далеко не идеален, но довольно сильно оптимизирован и неплохо справляется в большинстве задач. Но не серебренная пуля, конечно.
Основная масса знакомых мне случаев, требовавших тюнинга GC укладывается в следующие категории:
— несоответствие профиля работы с памятью настройкам GC: другие времена жизни (объекты слишком быстро уезжают в oldgen и висят мертвым грузом до major gc), слишком маленькие eden/survival (частые минорные сборки и отправка объектов в oldgen);
— паттерны работы с памятью не укладывающиеся в модель generational GC: очень активное переиспользования долгоживущих объектов (соответственно много активно изменяющихся объектов в oldgen), использование крупных короткоживущих объектов (которые сразу уезжают в oldgen, т. к. не помещаются в eden);
— работа с большой кучей (большое время major gc).
Первая «проблема» лечится профилированием и настройкой GC. И не является проблемой, по большому счёту. Она сродни настройке размеров пулов потоков, соединений, размеров буферов, очередей и т. п. Обычно ничего катастрофического не происходит при неоптимальной настройке.
Вторая и третья проблемы лечатся по разному (в зависимости от задачи): изменением алгоритмов и структур данных, использованием offheap storage, выносом в нативные расширения (например, в heliosearch часть расчётов на больших короткоживущих массивах делается именно в нативном коде), распиливанием на компоненты меньшего размера, избеганием major gc (вплоть до перезапуска приложения вместо gc). Но это уже сильно зависит от задачи и имеющихся ресурсов.
В общем, GC в Java далеко не идеален, но довольно сильно оптимизирован и неплохо справляется в большинстве задач. Но не серебренная пуля, конечно.
unique_ptr работает в >90% случаев и не требует использования interlocked или ведения счетчиков ссылок
Еще чаще смарт-поинтеры вообще не нужны, поскольку лишь ничтожное меньшинство операций с указателями как-то пересекается с идиомой владения
Системы где были бы реально нужны циклические ссылки на практике лично мне вообще пока не встречались.
Смарт-поинтеры в плюсах требуют определенной культуры использования и при ее нарушении могут создавать проблемы, но эта культура там весьма простая и у сколь-либо опытного разработчика её соблюдение происходит автоматически без малейших сознательных усилий
Еще чаще смарт-поинтеры вообще не нужны, поскольку лишь ничтожное меньшинство операций с указателями как-то пересекается с идиомой владения
Системы где были бы реально нужны циклические ссылки на практике лично мне вообще пока не встречались.
Смарт-поинтеры в плюсах требуют определенной культуры использования и при ее нарушении могут создавать проблемы, но эта культура там весьма простая и у сколь-либо опытного разработчика её соблюдение происходит автоматически без малейших сознательных усилий
1. Скачал установщик Nim под Windows
2. При установке отметил все галочки (компилятор и IDE)
3. Запустил «китовую» IDE
4. Скопировал туда helloworld с первой страницы документации
5. Компилирую и запускаю helloworld из IDE — вместо вывода в консоль «введите своё имя» и ожидания ввода — чёрное окно с намертво повисшим процессом.
Вывод: и ЭТО вы считаете идеальным языком? Там даже helloworld не работает. :(
Рановато, мне думается, вы ему рекламу дали. Может, ложки-то и найдут, но осадочек у многих пацанов с раёна Хабровцы останется.
2. При установке отметил все галочки (компилятор и IDE)
3. Запустил «китовую» IDE
4. Скопировал туда helloworld с первой страницы документации
5. Компилирую и запускаю helloworld из IDE — вместо вывода в консоль «введите своё имя» и ожидания ввода — чёрное окно с намертво повисшим процессом.
Вывод: и ЭТО вы считаете идеальным языком? Там даже helloworld не работает. :(
Рановато, мне думается, вы ему рекламу дали. Может, ложки-то и найдут, но осадочек у многих пацанов с раёна Хабровцы останется.
«нишевый рынок в Северной Америке»
в Южной
в Южной
не язык делает нас продуктивными. хотя и он не на последнем месте! продуктивными нас делает опыт, либы, окружение.
К Скале, к сожалению, нужен особый подход. Нужно либо чутьё и понимание замысла создателей (это не какой-то редкий дар, я видел много таких людей), либо кто-то, кто знает, куда лучше не лезть.
Новички (и не только «неопытная молодёжь», как наглядно показано) всегда нарываются на scalaz и shapeless, потому что про них больше всего трёпа в интернете. А пользоваться ими в типичных «конторских» проектах вообще нельзя.
Для Type Classes библиотеки не нужны.
Новички (и не только «неопытная молодёжь», как наглядно показано) всегда нарываются на scalaz и shapeless, потому что про них больше всего трёпа в интернете. А пользоваться ими в типичных «конторских» проектах вообще нельзя.
Для Type Classes библиотеки не нужны.
Термин "продуктивность программистов" понятен, но оценить язык по этому критерию можно лишь эмпирическим путём.
Думаю, хорошим аналогом анализа самого языка будет критерий "уменьшение рутины".
И вычислять, например, отношением «важных строк» к «строкам согласования» (они же «строки склейки»). Чем больше %, тем меньше рутины и более продуктивней язык.
Думаю, хорошим аналогом анализа самого языка будет критерий "уменьшение рутины".
И вычислять, например, отношением «важных строк» к «строкам согласования» (они же «строки склейки»). Чем больше %, тем меньше рутины и более продуктивней язык.
nim? это точно не тонкий троллинг?
можешь описать картину замысла (холст, масло)?
чем чисто практически, для производства, это лучше жабы, которая уже «просто работает»
ты нарисовал бы Эклипсу на ниме быстрее, чем на жабе?
можешь описать картину замысла (холст, масло)?
чем чисто практически, для производства, это лучше жабы, которая уже «просто работает»
ты нарисовал бы Эклипсу на ниме быстрее, чем на жабе?
Жаба не работает, а тормозит собирает мусор
Так они и тормозят ведь, будьте честны сами с собой.
У меня не тормозит
Я работаю в Visual Studio (2013) под Windows и в CLion (по сути, IDEA) под Ubuntu. Машины идентичные.
VS быстрее, и это заметно невооружённым глазом.
Расскажите о конфигурации вашей рабочей машины.
Объективно Java-код не может работать быстрее нативного. Вы же не будете с этим спорить?
VS быстрее, и это заметно невооружённым глазом.
Расскажите о конфигурации вашей рабочей машины.
Объективно Java-код не может работать быстрее нативного. Вы же не будете с этим спорить?
Обычный десктоп — i5, 8ГБ, HDD
На другой машине у меня еще SSD есть, там быстрее работает
Но и без SSD не тормоит
На другой машине у меня еще SSD есть, там быстрее работает
Но и без SSD не тормоит
Объективно может, ведь «нативный» код на самом деле не нативный — он сделан чтоб выполняться на куче разных процессоров, а вот код который делает jit оптимизирован под конкретное железо(в оптимальном случае),
Т.е. посредник в виде jit не накладывает никакого оверхеда, по-вашему?
Ещё и GC там работает.
Ещё и GC там работает.
И в чем же может быть оверхед при исполнении нативного кода, сгенерированного jit'ом?
Если не прогонять программу через что-то типа ngen, то как минимум будет замедление, потому что сначало нужно скомпилировать промежуточный код в ассемблер. И это если у вас компиляция метода происходит при первом вызове метода.
Вот интересный вопрос: а сколько компилится код с помощью JIT? Не должен слишком долго, а поэтому часть оптимизаций отсекается. Не может быть почти моментальным, иначе не будет никаких оптимизаций.
Тут умные дядьки придумали делать оптимизации сначала на компиляторе Java/C# -> промежуточный код. А потом на компиляторе промежуточный код -> ASM. Вы уверены, что при двойной компиляции мы не теряем часть полезной информации, которую можно было заюзать для оптимизации?
А вот еще момент. А если программа запускается несколько раз, не будет ли разумным сохранять результаты работы JIT? А если так, то когда? И во сколько нам обойдется работа с файловой системой?
Вот интересный вопрос: а сколько компилится код с помощью JIT? Не должен слишком долго, а поэтому часть оптимизаций отсекается. Не может быть почти моментальным, иначе не будет никаких оптимизаций.
Тут умные дядьки придумали делать оптимизации сначала на компиляторе Java/C# -> промежуточный код. А потом на компиляторе промежуточный код -> ASM. Вы уверены, что при двойной компиляции мы не теряем часть полезной информации, которую можно было заюзать для оптимизации?
А вот еще момент. А если программа запускается несколько раз, не будет ли разумным сохранять результаты работы JIT? А если так, то когда? И во сколько нам обойдется работа с файловой системой?
Если не прогонять программу через что-то типа ngen, то как минимум будет замедление, потому что сначало нужно скомпилировать промежуточный код в ассемблер....
Правильно, оверхеда нет — есть единовременные затраты на jit компиляцию ;)
Спорить от тормозящих IDE я не хочу — у меня просто зацепился глаз за утверждение про «оверхэд» выполнения нативного кода.
Единственно, что отмечу про VisualStudio, применительно к плюсам, — меня всегда огорчал предоставляемый ей функционал по рефакторингу кода, где не было даже элементарного переименования методов и классов «из коробки». Поэтому никогда не удивлялся тому, что при этом она работает быстрее.
Тут умные дядьки придумали делать оптимизации сначала на компиляторе Java/C# -> промежуточный код. А потом на компиляторе промежуточный код -> ASM. Вы уверены, что при двойной компиляции мы не теряем часть полезной информации, которую можно было заюзать для оптимизации?
Можно я просто сошлюсь на других «умных дядек» успешно занимающихся Clang и LLVM? ;)
Правильно, оверхеда нет — есть единовременные затраты на jit компиляцию ;)
У меня есть наглядный пример — жирное enterprise приложение на c#.
Когда открываешь окошко, которое в текущей сессии ещё не открывалось, оно пол-секунды «компилирует». Конструктор диалога почти пустой, в базы не ходит. Разве что ресолвит зависимости из di-контейнера.
А поскольку окошек всяких разных много и типичный девелопер обычно не работает долго в одном, а открывает приложение при необходимости что-то глянуть и переходит в некоторое окно, тормоза раздражают постоянно.
Вот интересный вопрос: а сколько компилится код с помощью JIT? Не должен слишком долго, а поэтому часть оптимизаций отсекается. Не может быть почти моментальным, иначе не будет никаких оптимизаций.Если говорить за JVM, то она JITит методы только если они вызываются достаточно много раз (10к в server mode, если правильно помню), с учётом набранной статистики вызовов. И может переключить в интерпретируемый режим обратно (разJITить), если ей что-то не понравится.
Это приводит к тому, что:
— JIT компилирует не всё, а только горячие участки кода (снижая суммарные затраты времени на компиляцию),
— JIT использует довольно агрессивные варианты оптимизации исходя из статистики реальных вызовом метода (в частности, специализированные методы, dead path elimination, агрессивный inline).
Такой подход приводит к тому, что результирующее приложение после «прогрева» может работать быстрее, чем аналогичное, написанное на компилируемом языке или, тем более, на интерпретируемом с использованием AOT. Именно поэтому, увидев java-бенчмарки без прогрева, стоит гнать их авторов ссаными тряпками.
но, получается, что jvm куда-то сохраняет эту статистику по каждому вызову каждого метода. И это уже может ыбть приличным оверхедом.
Да, естественно это даёт некоторый оверхед (и по памяти, и по cpu). Но то, что скомпилированно JITом уже не имеет этого оверхеда, если не сваливается в slow path (при невыполнении параметров, при которых оно заоптимизированно).
Опять же, подробную статистику по методу JVM может собирать не сразу, а после накопления некоторого количества его вызовов, чтобы уменьшить оверхед на сбор статистики на холодных методах.
Опять же, подробную статистику по методу JVM может собирать не сразу, а после накопления некоторого количества его вызовов, чтобы уменьшить оверхед на сбор статистики на холодных методах.
Нативный код — нативный.
Особенно на языках типа C, C++, Delphi и т.п.
При компиляции этого кода хороший компилятор может производить оптимизацию под конкретное железо. Если задать ему соотв. ключи.
С другой стороны — вы правы, проги ведь распространяются обычно в собранном виде.
Если собирались для amd, а выполняются на intel'е, то вообще даже могут не выполниться.
Опрос железа и несколько вариантов сборок помогут. Костыль однако.
Особенно на языках типа C, C++, Delphi и т.п.
При компиляции этого кода хороший компилятор может производить оптимизацию под конкретное железо. Если задать ему соотв. ключи.
С другой стороны — вы правы, проги ведь распространяются обычно в собранном виде.
Если собирались для amd, а выполняются на intel'е, то вообще даже могут не выполниться.
Опрос железа и несколько вариантов сборок помогут. Костыль однако.
Тут дело не в том, что java теоретически может дать, а в том, как пишется реальный код.
На c++ разработчик потратит 3 дня на компонент, вручную освобождая память сразу, как только она не нужна, размещая короткоживущие объекты на стеке, не используя string, когда достаточно char* и т.д. На java всё это напишется за день, но без обдумывания низкоуровневых деталей, всё на автомате и по дефолту.
На java можно написать супер-производительный код «на спор», обдумывая его не меньше, чем код с++, но в большинстве случаев язык позволяет меньше думать. Значит, в программу вложено меньше знаний о специфике конеретной ситуации, значит, хуже производительность.
На c++ разработчик потратит 3 дня на компонент, вручную освобождая память сразу, как только она не нужна, размещая короткоживущие объекты на стеке, не используя string, когда достаточно char* и т.д. На java всё это напишется за день, но без обдумывания низкоуровневых деталей, всё на автомате и по дефолту.
На java можно написать супер-производительный код «на спор», обдумывая его не меньше, чем код с++, но в большинстве случаев язык позволяет меньше думать. Значит, в программу вложено меньше знаний о специфике конеретной ситуации, значит, хуже производительность.
Кстати, в современных компиляторах использование std::string будет незаметно по сравнению с char*.
Вот честно — по сути это то же самое, можно даже код ассемблерный посмотреть.
А на маленьких строчках даже быстрее будет из-за Small String Optimization (память для маленьких строк берётся прямо в стэке, а не аллоцируется в куче).
Вот честно — по сути это то же самое, можно даже код ассемблерный посмотреть.
А на маленьких строчках даже быстрее будет из-за Small String Optimization (память для маленьких строк берётся прямо в стэке, а не аллоцируется в куче).
На c++ разработчик потратит 3 дня на компонент, вручную освобождая память сразу, как только она не нужна, размещая короткоживущие объекты на стеке, не используя string, когда достаточно char* и т.д. На java всё это напишется за день, но без обдумывания низкоуровневых деталей, всё на автомате и по дефолту.
В плюсах все пишется за тот же день и на том же автомате. Смарт-поинтеры там где нужно, использовать std::string везде. И результат будет при этом гарантированно работать без утечек и сегфолтов, причем уже даже в таком тупом варианте «из коробки» он будет быстрее чем в Java. Дальше, если кусок очень performance-critical можно потратить дня три на его вылизывание, но даже при этом работа будет сосредоточена на алгоритмической и логической оптимизации, а не на возню с памятью. Это я как разработчик серьезного CAD/CAM и тяжелого высокопроизводительного real-time говорю.
Да, к сожалению, в плюсах можно и пострелять себе в ногу, а куча литературы учит работать на плюсах «в стиле C». Но это, прямо скажем, делать не обязательно и научиться хорошим практикам труда не составляет :).
Не смущает что VS написано с использование с#, где тоже есть gc1. Вы уверены, что VS вся написана на C#?
2. В C# есть структуры и нормальные generics, поэтому нагрузка на GC меньше.
Не смущает, что у Java есть Jit, который в теории может дать пифоманс горячего кода даже лучше, чем у c++«пифоманс», блять. Java и C# еще не доросли до такого уровня, чтобы выдавать подобные характеристики. Я имею в виду не в теории теории, а в реальной теории.
Улыбнуло насчет тормозит вообщеТак тормозит же. Холодный запуск очень медленный, gc stops the world.
Ничего что люди на Java пишут почти real-time приложения?Пруфы, пожалуйста.
2. Не знаю как это может помочь уменьшить нагрузку на GC
Структуры не учавствуют в процессе сборки мусора. Они хранятся либо на стеке, либо внутри объекта. На структуру тупо нету указателя, соответственно нет необходимости в GC — их удаление просчитано еще в compile-time. Нормальные честные generics приводят к тому, что структуры хранящиеся внутри коллекции не надо заворачивать в объект.
3. Возможно и доросли. Ведь для Java есть и AOT компиляторы
Почему код может быть быстрым после компиляции? Есть два варианта: нету тупорылых рантайм проверок и оптимизация на уровне смысла кода. Первый вариант в джаве и шарпе не прокатывает, а выразительность на уровне языка не сильно возрасла.
На 4-й пункт ничего не могу сказать, есть только личные впечатления.
> Ничего что люди на Java пишут почти real-time приложения?Вроде да, пишут. Но ЕМНИП там довольно жесткие ограничения на использование памяти, в том числе запрет на создание объектов в куче и, соответственно, никакого GC.
Пруфы, пожалуйста.
Пруфы, пожалуйста.Скорее тут стоит говорить про 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-паузой).
Люди RTB на Clojure пишут devopsdeflope.ru/posts/2015/018.html (только аудио, без текста).
Его также не смущает, что студия без Resharper'а (и иже с ним) не далеко ушла от блокнота в возможностях по работе с кодом, сравнивая с IDE от JetBrains.
В CLion работа GC очень заметна, особенно на больших проектах. Просто раз в N минут всё приложение тупо зависает :-)
Ничего что люди на Java пишут почти real-time приложения? ))
Кстати, вполне возможно, что и пишут. Но отличие в том, что на C++ уже написали, и эти приложения реально работают почти real-time :-)
Для тех 0.001% приложений, для которых этот «жосткийрилтайм» нужен, используют С++, все верно.
Остальные же 99.999% приложений, люди спокойно пишут на Java и иже с ним, за день.
И смотрят снисходительно на тех упоротых, которые неделями выжимают никому не нужные проценты производительности. А потом еще недели тратят на борьбу с сегфолтами и утечками.
Попутно отхватывая проблем с кросплатформенностью…
Кстати, если IDEA на Java такая тормозная гадость, а С++ такой вот весь из себя быстрый и крутой, где IDE уровня IDEA написанные на нем?
Остальные же 99.999% приложений, люди спокойно пишут на Java и иже с ним, за день.
И смотрят снисходительно на тех упоротых, которые неделями выжимают никому не нужные проценты производительности. А потом еще недели тратят на борьбу с сегфолтами и утечками.
Попутно отхватывая проблем с кросплатформенностью…
Кстати, если IDEA на Java такая тормозная гадость, а С++ такой вот весь из себя быстрый и крутой, где IDE уровня IDEA написанные на нем?
Т.е. всё-таки нет «почти риалтайм» приложений на Java? :-)
IDE уровня IDEA — Visual Studio 2015.
Но, вообще, это не аргумент. Точно так же можно спросить «Где [куча приложений, существующих на C++], написанные на Java?»
IDE уровня IDEA — Visual Studio 2015.
Но, вообще, это не аргумент. Точно так же можно спросить «Где [куча приложений, существующих на C++], написанные на Java?»
В ОС общего назначения не бывает, да. А в RTOS очень даже бывает, и тем более совсем без ОС, на голом железе. К слову, на Java тоже можно писать настоящий real-time, просто дефолтный GC для этого не подходит.
Для тех 0.001% приложений, для которых этот «жосткийрилтайм» нужен, используют С++, все верно.Хороший пример на тему — народ в какой-то момент, накурившись статей про bigtable и dynamodb написал Cassandra на Java, но нашлись добрые люди, решившие, что БД писать на Java — это не кошерно, работает медленно и всё такое. И запилили свой Hypertable на C++. К моменту, когда у кассандры был опыт боевой эксплуатации, большое количество пользователей, нормальный набор фич, у Hypertable была сырая пре-альфа в течении кучи времени, в которую залить пару сотен Гб без сегфолта было сложно. Зато на C++. В итоге, у кассандры уже второй стабильный major релиз, а hypertable ползёт к 1.0, но использовать её пока стрёмно.
Остальные же 99.999% приложений, люди спокойно пишут на Java и иже с ним, за день.
Посмотрел их код. Чуваки решили переизобрести STL, судя по всему. И везде raw pointers. В общем, неудивительно. Это ничего не говорит о языке.
Это скорее говорит о людях, которые начинают бездумно переписывать что-либо на 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 года. Как написал один из разработчиков на вопрос мертв ли проект в рассылке:
Цена развития и поддержки проекта на C++ часто оказаться слишком большой, и проект, в лучшем случае, буксует.
Когда требуется совсем маленькие 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++ часто оказаться слишком большой, и проект, в лучшем случае, буксует.
Забавно, какое бурление вызвал этот комментарий.
Меня не волнует, что джава тормозит компьютер, т.к. торможение незначительное, и в моих задачах это не играет роли. Значительные тормоза контролируются.
Что касается константной платы за запуск JVM, глубину иерархии клссов итп — планка оперативки и кингстоновский SSD, то и другое по 60 баксов у ближайшего барыги, стоят неизмеримо дешевле времени работы разработчиков.
Когда будете из своего кармана платить за то, чтобы кодер на Крестах месяц разрабатывал одну кнопочку, или команда нодо-поклонников джва месяца пыталась разобрать, какой динамической лапши наворотили их предшественники, вот тогда и вспомните.
Меня не волнует, что джава тормозит компьютер, т.к. торможение незначительное, и в моих задачах это не играет роли. Значительные тормоза контролируются.
Что касается константной платы за запуск JVM, глубину иерархии клссов итп — планка оперативки и кингстоновский SSD, то и другое по 60 баксов у ближайшего барыги, стоят неизмеримо дешевле времени работы разработчиков.
Когда будете из своего кармана платить за то, чтобы кодер на Крестах месяц разрабатывал одну кнопочку, или команда нодо-поклонников джва месяца пыталась разобрать, какой динамической лапши наворотили их предшественники, вот тогда и вспомните.
Ну, а скажем мою компанию волнует возможность выпустить сканер на три года раньше конкурентов и/или с более богатой функциональностью потому как наш код на плюсах работает достаточно быстро для реал-тайма, а оборудование которое обеспечит подобную производительность на Java появится только года через три. При этом уже сейчас можно уверенно сказать что люди которые рискнут пойти по этому пути будут там в итоге героически сражаться с тормозящим сборщиком мусора :).
Или вот скажем веб-сервера. На чем там у нас написан NGINX? И почему дураки пользуются подобным продуктом вместо того чтобы «просто поставить вдвое больше серверов» :D?
Или вот компьютерные игры. Почему их практически никто не пишет на Java :)? Может потому что игрушка выдающая 60 fps и/или обеспечивающая в реал-тайме более красивую графику / богатый функционал продается значительно лучше чем игрушка выдающая 30 fps и время от времени подвисающая на секунду :D?
В общем не валите все в одну кучу. Есть масса проектов где производительность does matter. Это может быть
а) софт работающий в том или ином виде в реал-тайме где важна скорость отклика или пропускная способность которую можно выжать из имеющегося оборудования
б) массовый софт где количество железа которое требуется апгрейдить оказывается достаточно велико — 60 баксов помноженные на 10.000 машин дают вполне достаточный повод оплатить годовую работу пяти программистов на плюсах.
Вдобавок «страшная сложность программирования на плюсах» — это миф, разница есть, но она невелика. Если у Вас кодер на крестах тратит больше 30 минут на добавление кнопочки то вытолкайте взашей идиота и наймите нормального сотрудника.
Или вот скажем веб-сервера. На чем там у нас написан NGINX? И почему дураки пользуются подобным продуктом вместо того чтобы «просто поставить вдвое больше серверов» :D?
Или вот компьютерные игры. Почему их практически никто не пишет на Java :)? Может потому что игрушка выдающая 60 fps и/или обеспечивающая в реал-тайме более красивую графику / богатый функционал продается значительно лучше чем игрушка выдающая 30 fps и время от времени подвисающая на секунду :D?
В общем не валите все в одну кучу. Есть масса проектов где производительность does matter. Это может быть
а) софт работающий в том или ином виде в реал-тайме где важна скорость отклика или пропускная способность которую можно выжать из имеющегося оборудования
б) массовый софт где количество железа которое требуется апгрейдить оказывается достаточно велико — 60 баксов помноженные на 10.000 машин дают вполне достаточный повод оплатить годовую работу пяти программистов на плюсах.
Вдобавок «страшная сложность программирования на плюсах» — это миф, разница есть, но она невелика. Если у Вас кодер на крестах тратит больше 30 минут на добавление кнопочки то вытолкайте взашей идиота и наймите нормального сотрудника.
Внимательно посмотрел я этот Nim. Это фактически Паскаль с питоньим синтаксисом и модными плюшками. У меня ощущение не особо приятное. Синтаксическое core языка достаточно громоздко. Вместо элегантного расширения при помощи API и типов, функционал зашит в синтаксис. Система типов посредственная. Когда одни языки используют концепты immutability, null-safety, value types, Nim пытается заставить нас вспомнить как правильно работать со сцылками. Одни zero-terminated mutable strings чего стоят! Язык прямо из коробки идет с кучей прикладной магии ввиде pragmas, шаблонов и макросов.
Вобщем, этакий невзрачный язык технического уровня наряду с D, Vala, etc…
Вобщем, этакий невзрачный язык технического уровня наряду с D, Vala, etc…
Стоит признать, что статьи этого цикла интересно читать: была какая-то интрига, да, и слог легкий, что-то цепляло. Но лично мне, очень неприятна настолько агрессивная и радикальная позиция автора во многих вопросах. Тем более, я бы не стал в статье такой тематики и контекста употреблять бранных слов…
В любом случае, почему начались такие войны в комментах? Человек нашел свой «идеальный» язык. Любая точка зрения субъективна. И для его взглядов на задачи, их решения, Nim — это «идеальный» язык. Можно подумать о его клиентах, в глазах которых он будет выглядеть как «один не очень хороший знакомец». Но если какие-то свои проекты, или внутренние. Если он полностью справляется с его задачами и предпочтениями, почему нет?! И за него стоит только порадоваться!
Я, например, работаю на Java. И несмотря на то, что последнее время мало услышишь положительных отзывов о ней, я ее не меньше люблю. Она полностью справляется с задачами, которые я решал, и решаю: нагруженные веб-системы, корпоративные решения, смартфоны, даже программирование для контроллера EHS6 (кстати, скоро будут платы с этими штуками!). Но если мне придется решать задачу, с которой Java не справится, я буду изучать другой язык, в чем проблема?
Мне кажется, что единственный качественный и объективный показатель для языка — это количество свободных вакансий, и уровень ЗП для разработчика, владеющего этим языком. Я вряд ли буду продолжать работать на Java, если разработчикам Nim/Go и др., в среднем будут платить в 3-5 раз больше 0_0, и вакансий будет куча)
Ну, опять-таки, это лишь моё субъективное мнение…
В любом случае, почему начались такие войны в комментах? Человек нашел свой «идеальный» язык. Любая точка зрения субъективна. И для его взглядов на задачи, их решения, Nim — это «идеальный» язык. Можно подумать о его клиентах, в глазах которых он будет выглядеть как «один не очень хороший знакомец». Но если какие-то свои проекты, или внутренние. Если он полностью справляется с его задачами и предпочтениями, почему нет?! И за него стоит только порадоваться!
Я, например, работаю на Java. И несмотря на то, что последнее время мало услышишь положительных отзывов о ней, я ее не меньше люблю. Она полностью справляется с задачами, которые я решал, и решаю: нагруженные веб-системы, корпоративные решения, смартфоны, даже программирование для контроллера EHS6 (кстати, скоро будут платы с этими штуками!). Но если мне придется решать задачу, с которой Java не справится, я буду изучать другой язык, в чем проблема?
Мне кажется, что единственный качественный и объективный показатель для языка — это количество свободных вакансий, и уровень ЗП для разработчика, владеющего этим языком. Я вряд ли буду продолжать работать на Java, если разработчикам Nim/Go и др., в среднем будут платить в 3-5 раз больше 0_0, и вакансий будет куча)
Ну, опять-таки, это лишь моё субъективное мнение…
У нас тут не портал начинающих писателей, знаете ли, а технический ресурс. Автор виновен не только в бранности, но прежде всего — в несостоятельности своей позиции. Nim — замечательный язык, надежда многих разработчиков на хорошую смесь C++ и Питоном, но говорить о продуктивности здесь и сейчас как-то странно, учитывая нестабильность языка и неразвитость экосистемы.
Заметил одну крутую оптимизацию. Если человек с первого абзаца придирается к бранным словам, то с ним не получится работать дольше 5 минут. Хотя бы потому, что после моего вопроса «чепушило, какой жопой ты писал этот писец?», пойдет не конструктивный диалог об особенностях решения, а какой-то бред про бранные слова.
> В любом случае, почему начались такие войны в комментах? Человек нашел свой «идеальный» язык.
потому что автор хотел войны в комментах, очевидно же. Это забавно. Спорим на что-нибудь бесполезное (например, проигравший читает и делает туториал по Nim), никакого идеального языка он не находил, а просто хочет потроллить больных синдромом поиска глубинного смысла языка программирования.
> Я вряд ли буду продолжать работать на Java, если разработчикам Nim/Go и др., в среднем будут платить в 3-5 раз больше 0_0, и вакансий будет куча)
и чем же данные языки так хороши, что они окажутся популярней джавы? И почему за них будут платить в 3-5 раз больше, если они настолько популярны?
> В любом случае, почему начались такие войны в комментах? Человек нашел свой «идеальный» язык.
потому что автор хотел войны в комментах, очевидно же. Это забавно. Спорим на что-нибудь бесполезное (например, проигравший читает и делает туториал по Nim), никакого идеального языка он не находил, а просто хочет потроллить больных синдромом поиска глубинного смысла языка программирования.
> Я вряд ли буду продолжать работать на Java, если разработчикам Nim/Go и др., в среднем будут платить в 3-5 раз больше 0_0, и вакансий будет куча)
и чем же данные языки так хороши, что они окажутся популярней джавы? И почему за них будут платить в 3-5 раз больше, если они настолько популярны?
Заметил одну крутую оптимизацию. Если человек с первого абзаца придирается к бранным словам, то с ним не получится работать дольше 5 минут. Хотя бы потому, что после моего вопроса «чепушило, какой жопой ты писал этот писец?», пойдет не конструктивный диалог об особенностях решения, а какой-то бред про бранные слова.
Ну, во-первых, рабочий процесс — это одно, а статьи на техническом ресурсе — это другое. В любом случае, по Вашей логике можно любые претензии выражать в бранной форме? Это как минимум не этично, даже если
чепушило, жопой писал этот писец
—
Спорим на что-нибудь бесполезное
Нет, не спорим, тем более на что-нибудь бесполезное.
и чем же данные языки так хороши, что они окажутся популярней джавы? И почему за них будут платить в 3-5 раз больше, если они настолько популярны?
Вы слишком буквально приняли мои слова. Смысл глубже. Это лишь пример, описывающий мою позицию в указанном контексте.
P.S. Выделяете цитаты символом ">" — привычка RedMine?)
P.S. Выделяете цитаты символом ">" — привычка RedMine?)Почувствовал себя старым пердуном, до сих пор пользующимся plain text email.
> P.S. Выделяете цитаты символом ">" — привычка RedMine?)
привычка с ресурса https://www.linux.org.ru/forum/
привычка с ресурса https://www.linux.org.ru/forum/
moved
3-я часть будет?
Продуктивность? Да, важна, но что если язык вообще не подходит под задачу?
Хотелось бы услышать авторитетное мнение platoff о Erlang`е. Так как сейчас «болею» именно ним.
Хотелось бы услышать авторитетное мнение platoff о Erlang`е. Так как сейчас «болею» именно ним.
Надо откровенно признать, что Erlang это нишевый язык. В своей нише — распределенные отказоустойчивые сервисы он очень хорош. Конкурентов почти нет.
Но писать на нем приложение для смартфона или, скажем, графичечкий редактор — теоретически наверно можно, но явно не нужно
Но писать на нем приложение для смартфона или, скажем, графичечкий редактор — теоретически наверно можно, но явно не нужно
А где продолжение?
Ввиду отсутствия третьей части вывод — лучший язык программирования не найден.
Шикарная вводная, второй раз уже перечитываю этот сериал, спустя год. Расскажите за Nim, пожалуйста!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я нашел лучший в мире язык программирования. Часть Йо (2.72)