Comments 1332
Согласен. Метросексуальный макияж на ядро линукса был последней каплей.
Даешь суровый олдскул!!!
image

А вообще, очень раздражает. Чай, посиделки, магнитики, тортики и сладости, дршечка на кухне.
Когда-то бесили, но потом появился Web Storage API и мне уже пофик на них.
Там даже через а было, чтобы не было путаницы с овечьими звуками.
Вспомнилась старая картинка с «чем-то сильно расстроенной» овечкой
image
«безобидное». Фу. Какой тогда смысл это писать?
Это ведь тоже детский сад
Ох уж эти бунтари. Бунтуют, бунтуют… а потом пойдут доедать свои печеньки)

Переходи на тёмную сторону. У нас есть печеньки!


Печеньки


А добро вообще разное бывает

Пфф. Распространённое заблуждение. Зло не дремлет ибо хорошо высыпается. На тёмной стороне каждому положен полный соцпакет, печеньки, бесплатный спортзал, длинный отпуск с оплатой расходов и курсы по повышению квалификации. Монстрам, получившим увечья в борьбе с героями предоставляется компенсация и пожизненная пенсия. Гибкий график, возможность карьерного роста, уважение к личности и индивидуальный подход. На службе у Зла каждый найдёт занятие по душе и поддержку личных проектов.


В R&D отдел срочно требуются Middle Mad Scientist, имеющие опыт работы с магическими кристаллами и плазменным оружием, либо желающие его получить. Гибкий график, оформление по ТК. Молодой и дружный коллектив непризнанных гениев. Белоснежный халат и курсы по злобному смеху за счёт компании.

-Герой,- кричали мне,- переходи на Тёмную сторону! У нас есть печеньки!
В ответ я доставал из рюкзачка бутерброд с колбасой и демонстративно поедал. Нашли чем приманивать! У Светлых со снабжением полный порядок. А тут какие-то печеньки… Cо временем я смеяться перестал. C нашей стороны всё было замечательно. Свой паёк я получал и мог на выпад Тёмных показать то рябчика, то ананас, другие деликатесы. Они предлагали печеньки. Cтранно. Нет, я сознавал, что у нас не каждый может себе позволить рябчиков с ананасами, но это только справедливо! Кто получает меньше, кто больше, но в целом все довольны, голодающих нет. И строй самый лучший, экономика процветает. А с Тёмной стороны мрак и беззаконие, и разруха, и коррупция, и военная диктатура… ужас творится! И всё-таки… у Тёмного всегда есть печеньки. Символический, но прожиточный минимум. Каждому, без исключения. Не хватает других вещей — лекарств, жилья, боеприпасов — но печеньки есть всегда. Для всех, без обмана. Это внушало уважение. И настал день, на обычный окрик «Эй, Светлый, не хочешь к нам? У нас есть печеньки!» я неожиданно для себя, но совершенно искренне ответил «хочу!» С той поры я на Тёмной стороне. Да, несладко. Да, у нас тут бывают проблемы. Зато у меня есть печеньки! Полные карманы! Светлая сволочь разбудит меня среди ночи и спросит: «Ну, и где..?» — я всегда готов их показать. Печеньки не кончатся никогда! Есть их категорически запрещено.

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

Мне хочется считать программистов субкультурой.

Таки да или нет?
На комментарий VIkrom не может быть дан ответ да или нет. Поэтому я пошутил с отсылкой к анекдоту на женскую логику. Разумеется, я уважаю женщин, но шутка основана на стереотипе.
И нет, я не блондинка. Я брюнет.
Т.е. вы не видите хотя бы легкого диссонанса между взрослыми здравомыслящими людьми и субкультурой? Профессионалам не нужна субкультура, им нужен профессионализм.

К слову, я согласен с большей частью статьи.
Геолог и профессия и субкультура. Курьер — профессия. Альпинист и профессия и субкультура. Продавец — профессия. Субкультура это не только панки и скинхэды, но и, например, учёные. Так понятнее моя мысль?
Вопрос дискуссионный насколько применимо во всех этих примерах слово субкультура, но в контексте материала наверно нет смысла углубляться.
Применимо, разумеется:

…«Субкультура может отличаться от доминирующей культуры собственной системой ценностей, языком, манерой поведения, одеждой и другими аспектами[1][2]. Различают субкультуры, формирующиеся на национальной, демографической, профессиональной, географической и других основах»…
Одно ведь другому не противоречит и вполне сочетается. Писать скрипт, который будет знакомым девушкам из контакт-листа на 8 марта автоматически поздравления рассылать, не брить свитер и не стирать бороду — это профессиональная деформация. Обмениваться мало кому «из внешнего мира» понятными шуточками из мира ИТ — это как раз профессиональная субкультура. Ездить на сисопки каюсь, уже давно никто не ездит на сисопки :( на хакатоны, активно общаться на сайтах вроде Хабра — это как раз штуки, которые присущи определённому профессиональному кругу, и в общем-то действительно составляют субкультуру.

Это тоже мимо. Профессиональная деформация — это изменение восприятия под воздействием специфики профессии, включая шуточки.


Ездить на хакатоны, активно общаться на сайтах вроде Хабра

И что? С каких под посещение хакатонов и активность на Хабре стали частью профессии? Это сугубо опциональные вещи, весьма слабо влияющие на уровень вашего профессионализма.
Безусловно, среди программистов есть уйма представителей самых различных субкультур, но сама профессия — это ни разу не субкультура, поскольку вы без труда найдёте 2 программистов, у которых не будет ничего общего в плане систем ценностей, языка, манеры поведения и одежды.

Это тоже мимо. Профессиональная деформация — это изменение восприятия под воздействием специфики профессии, включая шуточки.

Именно так. Я просто описал некоторые внешние проявления, которые являются следствием изменения восприятия. Обычный человек не будет писать скрипт, рассылающий поздравления. Не потому, что не умеет писать скрипты, а потому, что понимает, что автоматические поздравления получать на самом деле неприятно :) А вот программист наоборот, может подумать, что это же прикольно — сделать поздравляющего девушек бота. И сделает.

поскольку вы без труда найдёте 2 программистов

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

Дааа лааадно…
Раза 3 присутствовал на «попойке» на которой чинили автомобиль, рестайлили автомобиль, восстанавливали почти с нуля.
Пару лет почти еженедельно наблюдал «решение проблем строительства» (даже «возведения») какого-либо сооружения на очередной попойке.
Да те же приёмы высоких гостей «в бане» или корпоративы (одна из разновидностей) — подобные задачи решают.
Раза 3 присутствовал на «попойке» на которой чинили автомобиль, рестайлили автомобиль, восстанавливали почти с нуля.

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

Ну так панки давно уже на несколько субкультур разделились.

Как геолог, назвал бы свою профессию не субкультурой, а образом жизни. это несколько другое, как мне кажется. Жена -ученый, морской биолог, однако, смею надеяться, мы относимся к одной «субкультуре» по своим взглядам на жизнь, художественным вкусам, и прочему. А так — да, оба бродяги.
Любой особый образ жизни неизбежно формирует свою субкультуру
У любого носителя субкультуры особенности образа жизни во многом будут определяться этой субкультурой

Сравнивать программистов, сидящих в тепле, уюте и попивающих смузи, с геологами, альпинистами, летчиками и тп — это, конечно, сильно.

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

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


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

Ожидаемо: никто не хочет признавать себя офисным планктоном, поэтому давайте найдём пол-процента учёных пилотов-программистов, ездящих в командировки в Марианскую впадину и будем говорить, что это и есть настоящие программисты.

А те 99% программистов, которые сидят в офисах, пьют смузи и ездят в командировки реже, чем менеджеры по продажам, уже, соотвественно, причислять себя к субкультуре «настоящих» суровых программистов как-бы и не имеют права.

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

А вы думаете все геологи, биологи, и остальные географы, не вылезают из экспедиций?)
Есть те, кто поля никогда не видел, только на картинах и на даче разве, что.


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

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

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

Само название «планктон» — уже немного оскорбительное, вы не находите? А субкультура людей, которые работают в офисах — конечно есть. Просто у них могут быть очень разные должности и задачи… А субкультура одна, да.
Проблема в том, что вы опять стараетесь уравнять всех под одну гребенку. На хабр иногда приходят не только лишь одни стереотипные программисты, админы и прочие. Могу например сообщить вам, что в море романтики далеко не так много, как кажется с берега. Уже после третьего-четвертого контракта (а зачастую уже после практики и получения рабочего диплома) восторги и романтизм спадают, и гораздо больше волнует возраст и состояние судна, адекватный ли мастер, нет ли филипков или индусов, а к сожалению, есть все чаще, зарплата, овертаймы, из неочевидного — качество еды (вернее даже — качество ее приготовления) и прочие обыденные вещи, к которым примешиваются профессиональные вопросы. Рутина и немного расслабления на переходах, остальное — работа. Так что, простые романтики™ увы, уже не те.
А толку, если геолог \ нефтяник \ моряк получает меньше, чем офисный планктон сеньерского уровня? Получается, что условный геолог по сравнению с офисным планктоном дно, так еще и рисков больше. Получается, что офисный планктон победил.
Тогда нужно носить звание офисного планктона гордо, а не пытаться примазать программистов к каким-то там геологам и морякам. А тут видно, что несмотря на хорошую зарплату, для самооценки чего-то всё-таки не хватает.
Да всё нормально с самооценкой у нормальных программистов. Проблема у тех, кто примазывает программистов к планктону.
Примерно в том же, в чём разница между мелким клерком и инженером.
мелким клерком и инженером

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

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

А офисный планктон разве не двигает прогресс?


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

А когда напишут ИИ для программирования — программисты начнут исчезать как класс: бухгалтера просто будут говорить, что им нужно добавить в отчёт. Кое-где программистов уже заменяют на SCADE, Simulink и т. д. За офисным планктоном будущее!

UFO landed and left these words here
UFO landed and left these words here

А кто научит ИИ оформлять отчёты? Программисты этого не умеют, их самих учить надо. Нет, бухгалтера и прочие специалисты в предметных областях умрут исчезнут позже:
T — появление ИИ, способного самостоятельно писать программы
T+1 — программисты больше не нужны, бухгалтера обучают ИИ
T+2 — бухгалтера больше не нужны.

UFO landed and left these words here
Ну или будет человек, конфигурирующий этот ИИ (если ИИ ещё не умеет самообучаться), но это уже не будет бухгалтер в привычном нам понимании
А кто научит ИИ оформлять отчёты?
Переоцениваете сложность отчетов.
T+1 — программисты больше не нужны, бухгалтера обучают ИИ
Часто вникали в работу бухгалтера?
UFO landed and left these words here
Зачем вообще отправлять отчеты в налоговую? Не проще ли запретить наличку, и передавать данные по затратам/приходам в режиме онлайн, у плательщика же запрашивать только классификацию расхода? Все отчеты на основе вашей первички налоговая сформирует самостоятельно:-)

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

А настоящая проблема совсем в другом — человек пока банально намного дешевле. Особенно с учётом возможных поломок чего угодно. Стоимость небольшой команды по сравнению с топливом (я уж не говорю про груз) среднего контейнеровоза — просто копейки.
А стоимость пары вооружённых охранников — ещё меньше, чем команды (на большом судне ведь довольно большая команда, верно?).
Экипаж Knock Nevis (длина 450 м) всего 40 человек.
На любом судне крутят штурвал несколько человек посменно. Остальные там с другими задачами. Например, команда механиков всё ещё намного дешевле, чем двигатель который обслужит и починит себя сам.
Ну может быть можно сделать такой двигатель, который не будет выходить из строя в течение рейса хотя бы?
У самолётов ведь нет такой проблемы — иначе падал бы каждый второй рейс.
1. А ведь и отказывают. В кабине всё ещё 2 пилота есть, которые знают что в таких случаях делать.
2. А ещё их обслуживать надо. У самолётов рейсы короче и обычно в родной порт к своим механикам. А иногда они точно так же возят механиков с собой.
3. Устранение одной небольшой поломки на супертанкере на ходу оплатит зарплату механика на годы вперёд.
И как результат всего выше, авиационный двигатель намного дороже изначально и в эксплуатации.
Внезапно, существуют программисты, которые в отпуске выглядят как настоящие альпинисты.
Пожалуй соглашусь — был такой опыт, коллега… что ни отпуск, так вечно она «в лесах/горах/походах».
А для вас геолог — это обязательно тот, кто с молотком по горам лазает? Открою тайну, сейчас большинство геологов в поле только на студенческой практике бывало, да и керн не всегда носом нюхало. Сидят себе в тепле, уюте, и попивают смузи, рисуя модельки на мощных тачках с качественными дисплеями. Они ж геологи, а не буровики или трубопроводчики. Да даже и геологи-сейсмики не особо в поле катаются, что там делать-то на постоянной основе в 21-м веке?
А про лётчиков — почитайте в блоге Туту.ру, как пилотам живётся, посмотрите видео. Вполне себе комфортная работа в большинстве.
Открою тайну, сейчас большинство геологов в поле только на студенческой практике бывало

В полку офисного планктона прибыло, значит.


почитайте в блоге Туту.ру, как пилотам живётся

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


Вполне себе комфортная работа в большинстве

А вы сами попробуйте каждые пару дней туда-сюда летать то ночью, то днём, то в 5 утра, да по гостиницам ночевать — специфическое удовольствие, даже если просто паксом.

В полку офисного планктона прибыло, значит.

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

А вы сами попробуйте каждые пару дней туда-сюда летать то ночью, то днём, то в 5 утра, да по гостиницам ночевать — специфическое удовольствие, даже если просто паксом.

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

А почему "обзываются"? Не я термин придумал, я лишь констатировал факт. Судя по минусам все так разобиделись, что ваще: видать хотят быть брутальными мачо наравне с нефтяниками и пилотами, но попивая смузи с печеньками в уютном офисе.

Ну кстати термин какой то не очень ясного для меня происхождения. Лично у меня единственное что ассоциируется с планктоном это что то совсем тупое, без мозгов, абсолютно не развивающееся, безучастно плавает в воде и нифига не делеает и т.п.
Вы бы сначала с сутью термина разобрались, а потом бы применяли к месту, глядишь, не вызывали б столько нареканий.
Офисный планктон — современное жаргонное выражение, используемое для обозначения «белых воротничков» — мелких офисных служащих ( (с) Вики)
Ну ептыть. А вы попробуйте в 3 ночи вставать по звонку потому что «У нас тут сплит брейн на проде, давай сука чини бегом, заказчик уже три раза звонил, ЕТА спрашивал».
Не отрицаю, что работа офисного планктона тоже не без элемента героизма.
— Я сам служу, сударыня. Каждый день к 9 утра я должен идти в магистрат. Я не скажу, что это подвиг. Но, вообще, что-то героическое в этом есть.
© Тот самый Мюнгхаузен.
Туше, сударь.
Но тем не менее. Сложно сказать что отнимает больше времени и нервов — работа руками и ногами в поле или работа в офисе, но с постоянными найтшифтами и наркоманским графиком.
Руками/ногами, очень часто, в целом, поздоровее занятие, чем просиживать почти неподвижно весь день.
Никто не спрашивает, нужна вам субкультура или не нужна. Ваше мнение вообще ничего не значит в данном случае.

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

Ваш Капитан Очевидность.
Вот забавно, за статью в защиту токсичности плюсуют, а за токсичный ответ в слегка одесском стиле — сыпанули минусов…

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

И такая вещь есть. Во-о-он тот пласт под понятиями OpenSource / Freeware. Явления, которое в равной степени существуют и затрагивают сферу каждого — и красноглазого линуксоида, и фронтендера со смузями.
С трудом можно представить условного булочника, приходящего с работы, встающего к печи и затем раздающего булки на улице. Однако же строки кода, как и строки стихов, сегодня доступны каждому.
Понятно, что не всё так примитивно. Два фронтендера с одинаковыми скиллами могут быть мужчиной и женщиной, чёрным и белым. Моя мысль в том, что для фронтендера хипстерская субкультура может быть важней субкультуры айти. Поэтому одни на Хабре постят токсичные статьи, а совcем другие люди минусят токсичные комментарии. Личная культура пересекается примерно как венн диаграмма, и когда в комментариях встречаются люди с противоположных «лепестков», начинается весёлое кидание какашками :) Просто не понимают друг друга.

Тут вспоминается цитата из "Ведьмака":


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

Вот это — нормальная реакция здорового человека.
А жалоба на то, что кто-то с твоим мнением не согласен — ну тааакооооее...

Вот, кстати, живой пример мой коммент в соседней теме habr.com/post/353422/#comment_19481122 собрал тридцать минусов и половина минусов в карме. Думаю, автор топика имел ввиду примерно это. Формируется некая закрытая среда, которая занимается вытеснением неугодных мнений и людей. В результате получается некий бульон из «своих» омерзительно сладковатый на вкус
Хабраюзеры в массе своей не хотят читать глупости. Воистину это сговор и цензура.
Для меня лично 3D моделирование в Excel — это забивание гвоздей микроскопом. Делать это можно, но бессмысленно. Вот и получается, что образуется сладковатая среда забивателей гвоздей микроскопом и эта среда вытесняет любого, кто хочет это делать другими предметами. Но виноваты здесь не хаброюзеры, а сама среда (то есть площадка), давшая пользователям инструменты для формирования такой среды. Так что у меня здесь претензия не к хаброюзерам, а к площадке, а у автора топика должны быть претензии к работодателю
А может вы не на то акцент ставите? Никто же не призывает к именно «3D моделирование в Excel», но демонстрируют ещё один наглядный способ разобраться с 3D (о чём вам там в комментах и написали)
Простите, а вам что, кто-то заявлял, что делать тридэ графику не в экселе или делать в экселе не тридэ графику — это плохо? Вас заминусовали за статью об одной из этих вещей? Нет. Дерзайте)
3D моделирование это в первую очередь математика. С математикой в Excel более-менее нормально.
Хабраюзеры в массе своей не хотят читать глупости.
Не хотят, поэтому старательно читают, обдумывают, и после даже специально лезут на страницу профиля пользователя, чтобы сирануть в карму. Именно потому, что не хотят, ага :)

Понимаете ли, взрослый, сформировавшийся как личность человек, в отличие от инфантила, если не хочет читать глупости, он их просто… не читает (Внезапно!). А если читает — значит она ему интересна (пусть даже из энтомологического интереса), и здравая форма выражения этого интереса — изложение собственной аргументированной позиции. Конечно, если глупость совсем «за гранью добра и зла» — есть модераторы и почта для жалоб.
Проблематично понять, глупость ты читаешь или нет, пока не прочтёшь. А когда уже прочёл, логично дать обратную связь. Минус комментарию — «такие комментарии здесь не нужны». Минус в карму — «такие пользователи здесь не нужны». Последним, пожалуй, местные несколько злоупотребляют, но я не думаю, что от этого Хабр потерял так уж много.
У нас свободная страна™. Вам никто не мешает создать свой сайт с блекджеком и… и донести ваше, безусловно, очень важное мнение до окружающих.
создать свой сайт с блекджеком

У меня идея одного блекджека давно уже носилась: если персонаж А поставил персонажу Б минус, то персонаж А комеентариев персонажа Б уже не видит, а все остальные — видят. И овцы сыты, и волки целы: персонажа А не раздражает персонаж Б, а персонажа Б не раздражает то, что у него отобрали права голоса.

А потом приходит персонаж Ю и с удивлением наблюдает ресурс, на котором 30 десятка персонажей постят одинаковые посты и пишут одинаковые КЭПские комментарии один под другим, но их никто не замечает.
Действительно, это то, что нужно для данного ресурса!

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

Уже давно на разных форумах есть опция — скрыть сообщения пользователя. Без минусов/СМСок.
Ну мы же не форуме.
Да и как же без срача оживлённого обсуждения очередной неоднозначной статьи/новости?
Ну мы же не форуме.
Ну, можно что-то и здесь придумать. Как бы, не очень ново.
Да и как же без срача оживлённого обсуждения очередной неоднозначной статьи/новости?
Так идет себе обсуждение, просто не видите сообщения от тех или иных пользователей.
UFO landed and left these words here
почему вы считаете, что без минусования этого не случится?

Вот смотрите. Заходим в ветку любого *-срача и пишем комментарий, которые близок к нейтральному, но немного склоняется в одну из сторон (например: "по имеющимся у меня данным мне кажется, что в случае X имело место Y, потому что Z" — вполне рациональная позиция: человек описал имеющиеся у него данные и сделаные им выводы, при этом подчеркнул свою готовность изменить мнение, если будут предоставлены новые данные). При этом он тут же огребает минусов от противников этой точки зрения ("ату его, он против нас!") и… ничего от сторонников ("да ну его, он не за нас"). В результате имеем то, что имеем: карма неудержимо катится в минуса, независимо от того, чей Крым.

Я в последнее время только и делаю, что участвую в срачах в комментариях. Не стесняясь при этом высказывать достаточно экстремальные точки зрения. Моя карма за это время чуть-чуть подросла. Что я делаю не так?
UFO landed and left these words here
Вы в курсе, что людей с отрицательной кармой Хабр начинает постепенно урезать в правах (ограничена частота постов и т.п.)? При чём тут кармодрочерство (если я правильно понимаю суть термина)?
UFO landed and left these words here
А Вы в курсе, что кармадрочество (= желание иметь максимальную карму любой ценой, насколько я помню) и стремление не быть урезанным в правах — это несколько разные вещи? Или Ваша позиция сводится к мысли «не хотите минусов — не лезьте в комменты»?
В общем-то, тут действует абсолютно то же правило, что и в жизни. Если хочешь, чтобы тебя слушали — убедись в том, что то, что ты говоришь, кому-то интересно. Или хотя бы не очень раздражает. Иначе тебя тем или иным образом выдавят из компании. В жизни — перестанут приглашать на тусовки. На хабре — насыплют минусов.

xkcd_про_свободу_слова.жпг
И мы возвращаемся чуть выше по ветке: получается, что нейтральный по форме и общей позиции, рациональный по сути комментарий здесь в большинстве своём будет «не интересен» и «очень раздражает»? Нет, меня, конечно, тоже не раз называли троллем, когда я всего лишь пытался сделать из слов собеседника какие-то выводы (не здесь, на другом сайте)…
А где вы берёте такие комментарии? Обычно если я вижу комментарий в минусах, то он либо хамский по форме, либо глупый по содержанию. А в идеале — и то, и другое сразу.
То есть мы сейчас обсуждаем явления, с которым ни я, ни вы лично не встречались. Мне кажется, это неконструктивно)
Ок, пример: комментарий +36/-2 совпал с -2 кармы (другие комментарии в тот день минусов не собирали)
Всё как в жизни? Не надо говорить, если тебя слушать не хотят? Не надо говорить то, что раздражает?
Ха, ха, ха.
А сейчас ваш комментарий не получил плюсов, а плюс в карму прилетел. Как вам такой контраргумент?)
Спасибо, но суть всё же была не в том.
Если бы плюсы и минусы к комментами напрямую конвертились в оценку того, хотят тебя здесь слушать или нет — вот тогда б это было показательно. А сейчас зачастую не понятно что людям не понравилось вообще.
Вот, кстати, требование оставлять развёрнутое объяснение под каждым минусом в карму я бы поддержал. Видел похожую систему на одном сайте, мне понравилось.
А сейчас ваш комментарий не получил плюсов, а плюс в карму прилетел. Как вам такой контраргумент?)

Я бы с удовольствием послушал оратора. Но ему накидали минусов в карму (-1), но у меня нету прав поставить ему (+1)
В итоге оратора «запинали».
Подозреваю, если человек выскажет свое «глупое, смешное и никому не интересное мнение» в ветке «не по профилю» (про БД выскажется спец по JS/C++), то в своем «профиле» — он уже тоже ничего не сможет сказать :)
Карму слили в «непрофильном» наказав за любопытсво, а в «профильном» это и так спецам понятно, зачем поошрять.

Насчет большинства и интереса: Аристотель как-то написал что у мухи 8 ног и ~2000 лет никто не удосужился это проверить до Карла Линея. Интересно, а скольким до него было сказано «У мухи 6 ног ?! Да ты, парень, идиот. Все знают что их 8!!! Слышишь, неполноценный умственно, 8! С Аристотеля!!!»
Не обижайтесь, но это очень забавно, когда про аристотелей, карлов линнеев и прочих джордано брунов пишут люди, которые ниасилили написать пост и нарастить кармическую подушку безопасности.
Не обижайтесь, но это очень забавно, когда про аристотелей, карлов линнеев и прочих джордано брунов пишут люди, которые ниасилили написать пост и нарастить кармическую подушку безопасности.

Я так понимаю, что по существу приведенного сценария и исторического факта сказать нечего. Разве что добавить язвительности, которая сформировала не плохой эмоциональный посыл, за который поставили +1.
Случайный социальный эксперимент :)

Я бы поддержал Ваше предложение с пояснениями по карме в чуть измененной форме: требование оставлять развёрнутое достаточно нескольких градаций проф/социальный/личное и т.д. объяснение под каждым минусом (плюсом) в карму
А это и было высказывание по существу. Если вы умный и без ваших мыслей Хабр много потеряет — накопите этих мыслей побольше и напишите пост. Если не получается написать такой пост, то имеет место логическое отрицание условия из прошлого предложения.

Пример с мухой — он, мягко говоря, хрестоматийный. А говоря твёрдо — боян. Я его, помнится, приводил ещё на локальном общажном форуме, когда просил меня разбанить после того, как несколько раз высказал своё ценное мнение по различным вопросам. Но одмин был глух к мольбам. И, в общем-то, совершенно правильно. Хреновый из меня тогда был Карл Линней.
А это и было высказывание по существу.

Мой вопрос был прост: Как не имеющий права голоса может высказаться в поддержку того, с чьими высказываниями он согласен, но не согласно «голосующее большинство»? По вашим правилам, порог вхождения крайне высок(запретительный) :)
Если вы умный и без ваших мыслей Хабр много потеряет — накопите этих мыслей побольше и напишите пост.

У Вас не верная предпосылка. Репутация Хабра — любопытная штука, хороший механизм монетизации. Для владельцев ресурса :)
Не очень понятно, почему я должнен мои «гениальные мысли» выложить на Хабр, а не «замутить Свой Крутой Бизнес»? :)
Если не получается написать такой пост, то имеет место логическое отрицание условия из прошлого предложения.

В общем-то это и есть наглядный пример мехнизма «токсичности» :)
Не устроило большинство (или обладающего Правом), просто "-1" без пояснения и играй в угадайку :)
На мой взгляд, от того что «пример хрестоматийный» или «боян» разбрасываться его практической пользой — сомнительная практика.
Если форум созданы для обмена мнениями, это одно, если форумы созданы удовлетворить большинство — это другое :)
С точки зрения бизнеса — сценарий «большинства» предпочтителен:)

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

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

Считайте это как «социальную эволюцию». Время от времени появляются новые виды (мысли). Каких-то «уродцев» выбрасывают, какие-то выживают и развиваются двигая общество вперед и защищая его.
Нету новых мыслей — застой.
Вы предлагаете убрать свободу самовыржения? Или оставить только управляемую «социальную эволюцию»?
Эволюция — очень хороший пример. Если регулярно выкашивать случайно выбранные 10% популяции, эволюция продолжит работать как ни в чём не бывало (при условии, что популяция успевает восполнять потери). На одного заминусованного комментатора придутся девять таких, кто сумеет сформулировать примерно ту же мысль, но более куртуазно. А если не придутся — значит, либо мысль очень плоха, и чёрт с ней; либо мысль очень хороша, и тогда её автор способен родить пост.

P.S. Если что, я не хочу показаться высокомерным. Я в своё время по идеологическим соображениям гордо выпиливался с хабра, имея в активе статьи с рейтингом около 200. Я думал, это что-то будет значить. Неа, практически никто и не заметил. Система работает по принципу взаимозаменяемости винтиков. И это нормально.
UFO landed and left these words here
Если регулярно выкашивать случайно выбранные 10% популяции, эволюция продолжит работать как ни в чём не бывало

Эволюция невозможна без отбора.

Все верно, за исключением проблемы масштабирования.
Если популяция ниже определеного порога, она вырождается и умирает.
Если будем выкашивать рандомно 10% в коллектие в сотни… тысячи… миллионы единиц- «эволюция» продолжится, но с меньшей скоростью.
А если такое будет в популяции в 5..20..100 единиц?
Не проявится ли «выученная беспомощность» со временем — зачем генерить повторно мысль, если ее выкосили включив в рандомные 10%? Остальным 90% тоже не сахар. Такие прецеденты тоже были в истории :)
Извините, оффтоп. Прокомментирую вашу аналогию.
Если популяция ниже определеного порога, она вырождается и умирает.
Нет.
Есть такое понятие «бутылочное горлышко». Его прохождение часто весьма способствует эволюционным изменениям.
Если будем выкашивать рандомно 10% в коллектие в сотни… тысячи… миллионы единиц- «эволюция» продолжится, но с меньшей скоростью.
Нет.
Высокая численность популяции является эффективным тормозом эволюции. Можете погуглить «кошмар Дженкина» и «дилемму Холдейна».
/оффтоп.
Есть такое понятие «бутылочное горлышко».

Вы имеете ввиду этот «Эффект бутылочного горлышка»
Цифры что я видел: Людей, если меньше 150..200 в племени, вымирает за порядка 5 поколений. Тоже падение устойчивости к внешним воздействиям.
По животным 100..1000 в течении 50..100 лет.
«кошмар Дженкина» ...«дилемму Холдейна»

Не могу ничего сказать, но материалы относятся к очень давним временам, а в свете данных последних 10 лет генетики открыты горизонтальный перенос генов, и теория о резких эволюционных скачках в следствии накопившихся небольших генетических изменений.
Но полагаю, что далее тут эту тему развивать не стоит :)
Да, именно его.
Там несколько не тот механизм. При падении численности популяции увеличивается вероятность вымирания. Бутылочное горлышко можно и не пройти. Но ни о каком детерминированном вымирании речи и близко не идет.

Про горизонтальный перенос генов я еще в детстве слышал, это очень сильно не десять лет. Теория о резких скачках… Не ловлю. Не прерывистого равновесия? Если она, то это 70-е, и несколько не о том.

Ну и да, если что, не развивать тему всегда готов :)
В конце концов, это был оффтоп.

Вы как в том анекдоте.


Грибник заблудилися в лесу и кричит "Ау! Ау!"
На шум из кустов вылезает сонный медведь.
— Мужик, чего орёшь?
— Заблудился я, надеюсь, услышит кто.
— Ну я услышал. Тебе сильно помогло?

Лично мне — нет.

Хм. Вот, кстати, ваш пример меня удивляет. Как вас угораздило?

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

Где вы наловили столько минусов в карму? По одному-два за случайные комменты? Или всё-таки был какой-то центральный момент неприятия вас сообществом?
По одному-два за случайные комменты на протяжении двух лет (последняя моя публицкация была в 2016). Неубывающая карма (после окончания временных «бустов») была, кажется, около 50.
Кстати: а может такое быть, что у мухи, которую исследовал Аристотель, было действительно 8 ног? Возможно, какой-то вымерший впоследствии вид?
Насколько я помню, там вообще какая-то мутная история. В том смысле, что её растиражированная версия не вполне совпадает с тем, что было на самом деле. Но детали моя память не сохранила.
Вымерший впоследствии вид — однозначно нет. Количество ног таксономически различается не на видовом уровне, а на уровне классов. Различия не между человеком и обезьяной, а между человеком и птицей.

Теоретически это могло быть уродство, сбой в онтогенезе. Если дать эмбриологу возможность, он вам Слейпнира вырастит, а не то что муху восьминогую. Ну может, вырастить не получится, но родит запросто.
Раз, два, три… в общем, кто видел источники (пусть даже в переводе) — опровергают.
Так что вопрос больше в источнике байки про то, что Аристотель это писал :)
UFO landed and left these words here
есть разница между хамством и конструктивной критикой. Из ваших комментариев, как, впрочем, и статьи, очевидно, что вы пропагандируете первое.
Жить в чёрно-белом мире легко и просто. Жалко что наш мир на него не совсем похож.
Хочется, но не можется — отсюда такие истеричные посты, ибо эмоции захлёстывают. Хочется всех послать, но в ответ могут послать дальше и крутое мачо начинает обижаться. Они просто не пробовали когда их только пинают, а стоит немного попробовать.
Программист — это человек, который отдает свое время за деньги. Как врач. Как сантехник. Как уборщица. Он всегда хочет поработать меньше и получить больше. Вот и весь секрет. Это не детский сад и не субкультура. Это — ПРОФЕССИЯ.

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

вот как здесь, например
Люблю работать. Вот прёт бывает и всё. Хоть сутками сиди.
Выходит, я не программист.
Я бы различал несколько профессиональных субкультур в профессии программиста, причём некоторые из них выходят далеко за рамки профессии. Некоторых программистов точно можно отнести к субкультуре «офисный планктон» работников умственного труда с пониженной творческой составляющей :), а некоторых к якки, фрилансерам, дауншифтерам и т. п.
Возможно, когда мне будет за 30, я так же начну работать от звонка до звонка только ради зарплаты.

Не волнуйтесь, мне уже за 40, а "от звонка до звонка" всё ещё не хочется — интересно работать жеж, ёпрст!

Программист — это человек, который программирует, а то, что он получает за это, деньги, удовольствие или что-то ещё — это дело третье…
По вашей логике, получается, что некоммерческое/Freeware/OpenSource ПО присылают марсиане.
Ибо под понятие «поработать меньше и получить больше» никак не попадает.
UFO landed and left these words here
У меня от слова гик встаёт(ну вы поняли) перед глазами нагеленный полупокер в розовой футболочке с айтишным принтом, тыщачий маникюренными пальцами в айфончик, проставляя лайки в инстушечку.Как в фемили гае, в серии про миллениалов
Небось, ещё и смузи прихлёбывает при этом, закусывая фалафелем.
напрасно. Geek это кто-то, чем-то чрезвычайно увлечённый (не обязательно компьютерами), что от этого иногда страдает внешний вид и социализированность.
Не совсем ясно, что мешает автору выстроить работу с заказчиком (будь то внутренний или внешний, неважно) так, что есть условная команда матерящихся через слово инженеров, крепко знающих своё дело, но не общающихся с душевно-тонкими личностями с «той стороны» и команда пахнущих ромашками менеджеров проекта, которые как раз и берут задачу «презентации» команды на себя?

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

Или вы заставляете инженеров говорить с бизнесом? Тогда может в этом проблема?
В статье речь о состоянии внутри коллектива, а не про общение заказчик-исполнитель.
Автор говорит о том что в рабочей обстановке в последнее время культивируется «безопасное и мягкое общение» и именно против этого тренда он и высказывается.
Ну так и я про тоже. Выделите тех, кому не нравится «безопасное» общение в отдельный коллектив, пусть общаются между собой, как хотят. Если это повышает производительность — почему бы нет?
Разумеется, такой коллектив и его представителей следует максимально изолировать от тех, кто против их стиля общения.
Это вполне разумно, но на деле всегда могут всплыть нюансы, из-за которых такая четкая изоляция будет невозможна — команды изначально маленькие, дробить еще меньше не выйдет, либо придется делать перестановки, что также скажется на эффективности труда (по крайней мере на первых парах), нового сотрудника зачастую тяжело отнести к тому или иному «лагерю», он может раскрыться только со временем. А даже если удастся поделить именно так, то коммуникацию все равно не прервешь, так или иначе будут видеть друг друга, хоть на той же кухне.
Я все же хочу надеяться, что выделять в отдельный «коллектив» придется все-таки быдло, а не адекватных людей. Хотя судя по рейтингу статьи — до этого еще далеко.
Тонкие метросексуалы сломаются от попыток общения с вечно пьяными матершинниками, и ничего из такой затеи не выйдет…
Но ведь, если такая статья появилась, значит, сегодня выигрывают «метросексуалы»!
Почитайте Карнеги, лесть лицемерие и подковерные интриги — это норма человеческого общения, так же лицемерно названная этикетом. Так везде и всегда, я Вас огорчу, но ИТшники и здесь ни разу не особенные.
А в профессиональном плане, кто Вам сказал что критиковать людей нельзя? Можно и нужно, но критиковать можно по разному. Кто Вам сказал что людей хантят печеньками? Что у Вас вообще в голове творится?
Вы тут продавливаете общество «трамвайных хамов», но открою Вам секрет это работает только на первых порах, а в перспективе дает кучу проблем которые никому не нужны.
Да и не стоит считать всех ИТшников слабовольными безхарактерными хипстерами, поверьте это далеко не так.

Я против культивирования инфантилизма и гиперопеки. Вы спорите с вашими собственными высказываниями. Трамвайные хамы откуда-то взялись… Заранее известно моё мнение обо всех айтишниках… Прямо пособие по демагогии.
Какая еще гиперопека и инфантилизм? Кроме ярлыков я здесь ничего не вижу? Я 10 лет в ИТ и могу Вам написать прямо противоположную картину.
И со своими утверждениями я не спорю, я пытался, видимо не совсем удачно, сказать что преимущество «трамвайного хама» весьма зыбкое и перспективе приносит ему огромную кучу проблем ради разовой эфемерной выгоды и тем более на уровне трамвайных хамов невозможно построить профессиональные отношения.
Вы приписываете мне утверждение и на этом строите критику. Это называется демагогия. Хотите спорить аргументированно — приводите цитаты из статьи. Я достаточно ясно излагаю свои мысли, они не нуждаются в вашем толковании да ещё и с уничижительными эпитетами.
Я достаточно ясно излагаю свои мысли, они не нуждаются в вашем толковании да ещё и с уничижительными эпитетами.

Вы достаточно ясно излагаете мысли для себя..:


Любые предложения люди понимают иначе, чем тот, кто их вносит.
Следствия:
Даже если ваше объяснение настолько ясно, что исключает всякое ложное толкование, всё равно найдется человек, который поймет вас неправильно.
Если вы уверены, что ваш поступок встретит всеобщее одобрение, кому-то он обязательно не понравится. — Третий закон Чизхолма

PS Я вот ваш текст не осилил — нытьё и плачь, с просьбой вернуть хамство… И откуда-то внезапно берутся розовые сопли и карамельные рельсы… Ау, вы про какой айти-то хоть? Мировое? Нет такого — есть европейское, есть американское и т.д. Нет, ситуация с линуксом, конечно не самая приятная, но на галерах, например, никаких изменений нет. В ынтырпрайзе — тоже не особо заметно (благо галеры наполовину с ним пересекаются).

Не могли бы вы перестать? Опять то же самое, текст вы не читали, но критикуете с уничижительными эпитетами.

Вы же сами ратуете за прямое, без обиняков выражение мнений. А как получили такое мнение о своей работе — так сразу просьба перестать?))))

UFO landed and left these words here
Я утверждаю, что конструктивая критика полезна. Пока что все возмущённые конструктивизма не проявляют, зато прямо блещут своей тактичностью. Довольно странно, что люди, не прочитавшие текст приписывают мне какое-то мнение и выражают его в поразительно невежливой форме. Почему меня называют нытиком, плаксой и хамом в комментариях те самые люди, которых до глубины души возмутила моя статья? Потому, что не могут её прочитать и судят на основании своих домыслов?

Чувак, если я "ниасилил" текст, это не значит, что я его не читал. Я осилил (давясь) первые ~40% и последние два абзаца. Чтобы иметь представление о чём речь — достаточно. Если ты умудрился запихнуть в указанный мной кусок все свои "гиперболы" (на самом деле адовые перегибы в большинстве случаев) — сугубо твои, как автора, проблемы, т.к. существенно снижаются твои шансы быть понятым.


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

Позвольте ответить вам вашим стилем.

У вас, вероятно, серьёзные проблемы. Вы не прочитали даже половину текста, но так перевозбудились, что бросились гневно писать комментарий. Мне не особо интересно мнение такого формата.
В общем я «ниасилил» твой текст, а ты «ниасилил» обычную, даже без мата, критику… за которую типа ратовал в текстовке. Никакого уважения такое поведение вызвать не может.

А где там, извиняюсь, критика?

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

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

Это разные вещи, которые любители хамства не понимают. «Ты дебилоид» — это не критика, это прямое оскорбление. То, что и называется токсичностью.
«Ты накосячил, сделал так, а надо было вот так» — критика. Здесь нет оскорблений, но нет и никакого ограждения от критики.

"возможность накричать на приятеля — признак верной крепкой дружбы" ©

Весьма манипулятивная фраза, да и мы не о друзьях говорим, а коллегах. Это не всегда пересекающиеся множества.
А что такое галеры? Извините, тут просто со сленгом проблемы у некоторых)
Вообще мысль автора понятна. Но времена меняются, и программисты перестают быть гиками с низкой социализацией. Не все менеджеры это еще поняли, это да. Дайте им время )
Вообще мысль автора понятна.
А мне нихрена не понятна: навалена куча каких-то предрассудков, ни грамма логики, никаких выводов. Так и хочется ответить на это:
Идите-ка вы в жопу с вашей «токсичностью»!
чем-то вроде этого:
Иди-ка ты автор в жопу с своими «статьями»! Набросал две страницы ключевых слов и теперь рассказываешь в комментариях «я этого не писал», «вы мне это приписываете». Дай я открою тебе глаза: ты вообще не написал на одной умной мысли кроме того факта, что без критики и честных фидбеков мы никуда никуда не поедем. Вот тебе честный фидбек: засунь ты себе эту статью обратно в жопу черновики. И не связывай рабочие навыки, привычку материться и твердость гениталий. Слово "!@#" тебе, как видишь, никак не помогло.
Дело, на самом деле, в том, что вежливость, как заметили тут многие — это этикет или протокол взаимодействия между работниками. Быть невежливым и вызывать какие-либо втч отрицательные эмоции у других просто мешает работе. Пример с дальнобойщиком и продавщицей здесь неуместен, поскольку, во-первых любая женщина и любой мужчина предпочтёт вежливое обращение к ним вне зависимости от того, как они сами обращаются. Во-вторых, их взаимодействие длится несколько минут от силы, легче потерпеть.

Что касается стрессоустойчивости и «запрет на негатив» — то это просто манипуляция фактами. Админ стрессоустойчив не потому он матерится, и матерится он не потому что он стрессоустойчив. Он матерится потому что он — быдло, а на работе его держат потому что, наверное, достоинства превышают недостатки. И, наконец, если некомпетентный джун тебе пятый раз присылает говнокод на ревью, а ты не видишь никакого решения кроме как «вызвать негативные эмоции» чтобы решить проблему, то ты — некомпетентеный начальник. Когда встречаются два некомпетентных человека ни трэш-ток, ни размазывание розовых соплей не помогают, да.
UFO landed and left these words here
И вот кроме «джун, ты !@#» тут и не скажешь ничего.
Я так и написал: некомпетентный руководитель. Разве что мне здесь кто-то объяснит зачем вообще человека обзывать !@#ем и как это помогает рабочим отношениям.
Вы же говорите о ситуациях, когда джуна с первой итерацией кода посылают в !@#
Где?
Лично мне проще работать в коллективах «твой отдел — твоя семья», где действительно доверительные отношения и никто ни с кем не сюсюкается.
Вероятно, не у всех ваших сотрудников слово "!@#" — нормальное обращение в семье и вполне возможно, что они страдают из-за вас на работе и вполне возможно, что это отражается на их производительности. Кроме того, лично мне совершенно не нужны ваши семейные отношения на работе.
Но насаждение «этичной толерантности» чуть ли не силой это явный перебор на мой взгляд.
Силой — это бьют, что ли? Заставляют отжиматься? Да, явный перебор, согласен.

Вы передергиваете.


Люди могут страдать не только от того, что кто-то материться, но и от того, что они ощущают давление в направлении рамок.


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


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


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

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

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

погуглил трактовки статьи, спасибо что обратили внимание на заблуждение. буду знать.
Коммуникативный слой русского языка богат и разнообразен. И очень часто (надеюсь, пока) огульно и бездумно до нельзя упрощяется и искажается интерпретаторами. Вот тут введение в тему, очень всем рекомендую: amarinn.livejournal.com/1122199.html
Люди могут страдать не только от того, что кто-то материться, но и от того, что они ощущают давление в направлении рамок.

Самый банальный пример, это когда ЧР делает замечание о том как стоит и не стоит разговаривать людям, которые уже давным давно на ты.
Приватные бесседы — личное дело каждого. Если ЧР слышит приватную бесседу — то она больше не приватная. Если вы открыты к критике так, как бахвалится этим автор, то никакого давления от замечания испытывать не будете.
Создать общий свод правил о том, как нужно себя вести, что-бы любой коллектив с любым составом уживался на 5 — невозможно. Вас раздражает семейность, кого-то формальность, кого-то другого что нибудь еще. И каждый может привести доводы, почему такой или иной стиль поведения продуктивней.
Нет. Во-первых, продуктивность тут вторична. Во-вторых, пилоты используют специальный лексикон на англ языке в полете потому что о нем смогли договориться. Ваши интернеты пользуют доисторический HTTP потому что о нем смогли договориться. Названия живых организмов все на латинском потому что о нем смогли договориться. Люди по умолчанию вежливы друг с другом потому что об этом смогли договориться и свидетельство тому — несколько статей админ кодекса. Вопрос: сможете ли вы договориться на работе повсеместно использовать какой-то другой стиль кроме формального? А если новый сотрудник — то заново договариваться? На это может уйти много времени, что как-то не вяжется с продуктивностью.
Единственный способ создать функционирующее общество, это не вмешиваться в дела, которые вас не касаются.
Это у вас пережиток советского воспитания: «не лезь», «не твое дело», «ты что самый умный?». Об этом можно вести отдельную дискуссию, но суть в том, что это, скорее всего, плохо и неправильно, и, ИМХО, одна из основных причин почему люди из СНГ по-прежнему хотят свалить на запад.
Если кто-то любит материться, пусть матерится.
Так, где границу проведем? По какую сторону от границы будет огнестрельное оружие?
Если вам это мешает — договоритесь. Это отлично работает в современных обществах (меритократический капитализм).
Хер это а не работает. Если вы заглянете в среднестатистический российский подъезд, то вы сразу поймёте, что 50 человек не могут договориться просто ни о чем. Не умеют-с.
В советском воспитании скорее наоборот пропагандировалось постоянно вмешательство «общественности» в личные и семейные дела. А «не твое дело» — это защитная реакция.
Если ЧР слышит приватную бесседу — то она больше не приватная.

Одно дело если вас попросят говорить тише или в другом месте, другое, когда вас начнут поучать как друг друга называть.


Во-вторых...

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


Это у вас пережиток советского воспитания

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


Так, где границу проведем? По какую сторону от границы будет огнестрельное оружие?

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


Хер это а не работает.

Это работает лучше чем автократия. Если есть проблема, то ей занимаются те кто замешан, а не все вокруг. А то что в РФ происходит это никак не пример.

Одно дело если вас попросят говорить тише или в другом месте, другое, когда вас начнут поучать как друг друга называть.
Вот открытие: у всего есть мера.
Но люди есть люди все равно будут симпатия и антипатия. И это уже за рамками формального общения.
Неформальные отношения с хорошо знакомыми людьми на работе мешают этой самой работе — инфа 100%.
Я вырос не на пост советском пространстве, а в очень даже западном Израиле.
Вполне вписывается в мои представления об Израиле.
Причем тут оружие вообще?
Подумайте.
Вот открытие: у всего есть мера.

И вот ее нарушают. Об этом и статья.


Неформальные отношения с хорошо знакомыми людьми на работе мешают этой самой работе — инфа 100%.

Неформальное общение это не только покурилки. Нелюбить человека можно за то как делает код ревью. Можно весь отдел похерить, с плохим менеджером, который только формально общается — инфа 100%ю


Вполне вписывается в мои представления об Израиле.

Какие?


Подумайте.

Я подумал, и все равно никакой связи не вижу.


P.S.
Мне не нравится ваш токсичный стиль общения.

Мне не нравится ваш токсичный стиль общения.
Это не стиль общения а объективная критика, см. статью.

Нет, вы токсичный человек и я чувствую себя оскорбленным.


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

Интересно, а что если после того как вы скажите джуну идика ты на @*_#, он вежливо попросил тебя выйти на улицу уточнить лично с ним ваши претензии. Возможно ваш пыл сразу поубаватся. Нельзя давать себя оскорблять, нужно это мгновенно пресекать любым способом, иначе у человека это войдёт в норму. Как тут писали — вежливость и порядочность на работе — это протокол общения

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

Вы намекаете на силовое наказание обидчика. Успешное наказание легко попадает под статью УК, с учетом того, что в травматологии пострадавшего будут едва ли не пытать: «итак, я вам предлагал признаться в том, что вас побили, и вы согласились? Нет? То есть вы решили скрыть факт того, что вас побили? И кто именно вас не побил?..».

А дальше как я со стороны программиста вижу влияние этого на дальнейшую карьеру: коллеги запомнят обе стороны конфликта как «чуваков, которые подрались в офисе». Именно так, без лишних деталей. Когда через 5 лет у них рекрутер спросит «знаешь ли ты Персону1» именно этот прецедент и всплывет в памяти, с погрешностью на испорченный телефон и забытые со временем детали.

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

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

С точки зрения топ-менеджмента это как минимум неприятная мелочь, а как максимум: потери репутации.

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

Можно подумать, что быть *вежливым* и «вызывать какие-либо втч отрицательные эмоции у других» — работе не мешает. *Эмоции* — как бы, вообще не та вещь, которая — безусловно — уместна «на работе».
И, наконец, если некомпетентный джун тебе пятый раз присылает говнокод на ревью, а ты не видишь никакого решения кроме как «вызвать негативные эмоции» чтобы решить проблему, то ты — некомпетентеный начальник.

Даже опуская вариант, когда «вызвать негативные эмоции» — это и есть «решить проблему», ваше обобщение с «некомпетентностью»… это такое. Сказать, что «говнокод» — это «говнокод», если и является «некомпетентностью», то несколько в другой области :-)
Ничего не понял. Походу вы с автором на каком-то непонятном наречии пишете. Или да, я дурак.
Сказать, что говнокод — говнокод допустимо в целом, сказать, что его автор — говнокодер — нет.
Допустим, в некотором отделе разработчики отлаживают код перед сдачей — потому что сроки на неделю сдвинули, зато попросили экстренных фич, при этом на сдаче контракта нужен красивый прототип, который примут as is, а потом будет пол-года на устранение багов и это согласовано всеми сторонами.
Но фичи ломают архитектуру и вообще не вписываются, зато ОЧЕНЬ нужны.
В воздухе плавает запах дедлайна, свежих багов и пара топоров, которые не падают из-за густого мата, что не нравится нежным девочкам-тестировщицам и вызывает негативные эмоции.
Внимание, вопрос: и что делать в таком случае?
В итоге — да, но у нас была пара других кабинетов.
А если бы это был модный openspace? Или в других кабинетах не было бы мест?
MVP же делают чтоб было рабочим и манящим. Код совсем прототипов выбрасывается и пилится нормальный с архитектурой, для остальных случаев костыли и затычки превращают в куски архитектуры, возможно накапливая некоторый тех.долг относительно унификации и идиоматики.
UFO landed and left these words here
Так и я о том. Программисты сегодня существа гораздо более социальные изначально, поэтому не надо устраивать детский сад.
UFO landed and left these words here
Кто Вам сказал что людей хантят печеньками? Что у Вас вообще в голове творится?

Это что у Вас в голове творится? Где в статье про то, что хантят печеньками? Автор написал о том, что в вакансиях очень часто есть упоминание про печеньки. Я тоже это постоянно вижу и меня тоже это выводит из равновесия. При этом никто не говорит, что печеньки не нужны, с ними лучше чем без них. Но, блин, есть много вещей важнее этого. Кресло удобное, например. Или не адовый опенспейс на 100 человек, а маленькие кабинеты и т.д.
Просто «печеньки», видимо, один из самых выгодных способов мотивации, как по критерию «эффективность/стоимость», так и по стоимости реализации. Так что их все внедряют, а многие на этом и останавливаются.
UFO landed and left these words here
Ну, во-первых, мотивировать нужно не только «взрослых профессионалов», но еще и «невзрослых профессионалов», «невзрослых непрофессионалов» и даже «взрослых непрофессионалов». Во-вторых, «печеньки», возможно, должны восприниматься как маркер «тут меня будут холить и лелеять». «Мы будем специально стараться, чтобы вам спокойно кодилось, и ничего не отвлекало… даже в магазин бегать не придется». Возможно, кто-то подсознательно понимает это как «надо будет заниматься только разработкой в свое удовольствие, а всякое другое, что я делать не люблю, не хочу и не умею, возьмет на себя компания». В третьих, едва ли не большая часть когнитивных искажений связана с ошибками выбора и оценки. А в кадровой службе тоже могут работать «взрослые профессионалы», которые психологию знают и умело используют.
UFO landed and left these words here
чем офис в зловонном подвале с табуретками, пентиумом три вместо компьютера и более высокую зарплату

Про «пентиумы» и «табуретки» как раз никто и не пишет, собственно в этом и проблема.
Это не ради мотивации. Просто модный мем, такой социальный пароль для «субкультуры», знак «мы тут в теме, знаем про кукисы».

Никому на самом деле печеньки не нужны, это просто такой опознавательный знак.
UFO landed and left these words here
Вот да. Это было смешно и забавно сколько, 5 лет назад, больше? По меркам интернет мемов это древенее античности и лежит примерно на той же полке что и падонкавский сленг.
Это подмена понятий. «В каждой вакансии пишут про X(печеньки), но не описывают рабочее место, следовательно писать про Х — плохо. » Это неправильно, правильно «Не описывать рабочее место — плохо». Короче говоря, оставьте печеньки в покое)
Давайте писать «у нас в офисе электричество есть и зимой тепло»
и зимой тепло

А давайте. Не приходилось в офисе сидеть в пуховике?

Ох, очень хотелось бы видеть в вакансиях фразы типа "у нас в офисе нормальная приточная вентиляция и уровень ppm" и "у нас не приняты громкие дебаты и оффтоп в опенспейсе". Вот реально, дал бы скидку 10-20% зарплаты за эти два пункта.

UFO landed and left these words here
Автор написал о том, что в вакансиях очень часто есть упоминание про печеньки. Я тоже это постоянно вижу и меня тоже это выводит из равновесия.

Так вот для кого safe spaces придумали! :)
Чего?
Забавный чувак, открытым текстом говорит: «что бы иметь хорошие отношения с людьми нужно больше лести и лицемерия, главное делать это правильно и я расскажу вам как!»
Опять уволили за токсичность? Сочувствую, тоже бывало. А теперь по пунктам:

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

Не соответствует правде. Критика постоянно высказывается, особенно в пулл-реквестах, после работы QA, и пользователями. Я бы сказал большая часть работы программиста — это работа с конструктивной критикой

2.
Человек может раз за разом отправлять вам на ревью код с одними и теми же ошибками и надо отвечать на это вежливостью и улыбкой?

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

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

Конечно же без явных причин! Токсичность и отсутствие компетенций тут не причем, да :)

4.
С годом опыта можно быть специалистом высшего уровня в профессии.

А когда, например, ява программист с 10 летним опытом, 5 из которых на управленческих позициях, начинает писать на PHP. Считаете, у за год не сможет до сеньора дойти? Ну считайте, ваше право :)

5.
Неожиданный факт — программисты не хотят работать без печенек.

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

6.
Через три месяца разговор с HR, в результате которого выясняется, что команда его ненавидит.

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

После прочтения данного произведения хотелось бы посоветовать автору перестать мыслить чрезмерно категоричными понятиями (ненависть, двуличие, подковерные интриги), и начать прислушиваться не только к своему мнению, но и к мнению окружающих, а так же хорошо выполнять свою работу, и тогда за токсичность никто уже увольнять не будет :)
У всех свой опыт. Спасибо что поделились вашим. Однако, я не считаю себя абсолютно правым, в тексте много гиперболизаций.
Тут такое дело, нельзя всех причесать под одну гребёнку. А статью стоит рассматривать с юмором а не как крик души отчаявшегося грубияна.
> Не соответствует правде. Критика постоянно высказывается, особенно в пулл-реквестах, после работы QA, и пользователями. Я бы сказал большая часть работы программиста — это работа с конструктивной критикой

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

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

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

Критикуйте то, в чем у вас есть набор компетенций. Если вы программист — профессионально критикуйте код, а для профессиональной критики личности есть психологи и психотерапевты, и их этому минимум 10 лет учат.

И это элементарное уважение к человеку как к личности, «нетоксичность» тут вообще не при чем.
Зачем может в принципе понадобится критика личности человека на рабочем месте? Если вы вы с коллегой приятели, можете обсуждать ваши личные дела, если это работе не мешает, но это к работе не имеет никакого отношения.
Есть люди, которые не могут не критиковать личность человека при критике его работы или её результатов. Ну типа «Ты это сделал? Идиот, переделывай!!!»
Критика постоянно высказывается, особенно в пулл-реквестах, после работы QA, и пользователями.

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


Вежливостью — да, улыбкой — нет. А потом просто вежливо попросить написать по собственному.

А если это не в вашей компетенции? Причем ответственный за проект ты, но задачи раздает и принимает начальник по принципу "работает — и ладно". Если человек коммитит код на Java в 201x году, где коллекции итерируются: for (int i = 0; i < list.size(); i++) list.get(i). А на просьбу переписать как надо жалуется начальнику, что я придираюсь. И кто тут разводит токсичность?


Ненависть коллектива сложно игнорировать, хочу я вам сказать.

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

Причем ответственный за проект ты, но задачи раздает и принимает начальник по принципу «работает — и ладно»

Если начальник раздает и принимает таски, то ответственный не вы, а начальник. В данной ситуации я обычно огораживаюсь от человека, который делает дичь. И не только я, прошу заметить. В результате с человеком никто не хочет работать, через месяц составляется отчет, и по результату безделия человека просят уйти. Именно про такую «ненависть» я говорю.
Про личностей, которых вы упомянули, а именно
ненависть и шум в основном разводят хреновые специалисты, как попытку оправдаться
— тоже регулируются подобным образом. Со скандалистами соглашаются работать такие же скандалисты, а результат такой команды редко выходит хороший. Ну и дальше по накатанной — пустой отчет — по собственному или по статье :)
Ответственный тот, кто согласился быть ответственным. При этом полномочий и даже других разумных возможностей на что-то влиять в процессе, за который ответственен, может и не иметь.
Ответственный тот, кто согласился быть ответственным.

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

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

В данной ситуации я обычно огораживаюсь от человека, который делает дичь.

Отгородиться не удастся, ибо код и проект общий. А таск разбираться с любой проблемой на продакшне поставят тебе, ибо "ты есть лид" и ответственный. Вот и ловишь потом ликинги ресурсов и памяти в коде, к которому ты не имеешь никакого отношения и разбираешься с проблемой падений или проседания перформанса. А по завершении говорят "спасибо" и закрывают таск без всякого разбора полетов (а зачем, все ведь заработало, проблема решена, какая разница кто виноват — мы же все в одной команде?!).


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

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

ты есть лид

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

Не успеешь моргнуть, как они уже начинают тобой командовать

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

А по завершении говорят «спасибо» и закрывают таск без всякого разбора полетов

От того что вы поблеймите своего подчиненного, кому от этого станет лучше? Может лучше действительно просто закрыть таск, предварительно спокойно его обсудив?

какая разница кто виноват

А действительно, кто виноват? Разработчик, написавший гавно, тимлид, пропустивший это в продакшен, тестировщик не увидевший это на тестах, или, может, ПМ, эту задачу поставивший и обозначив недостаточный срок реализации? Кто из них виноват? Или может все вместе накосячили, одной командой?

for (int i = 0; i < list.size(); i++) list.get(i)

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

Если человек коммитит код на Java в 201x году, где коллекции итерируются: for (int i = 0; i < list.size(); i++) list.get(i)

А что в этом плохого-то? То, что метод size() вызывается каждый раз, и это ухудшает производительность? А разве JVM то не оптимизирует в рантайме?
UFO landed and left these words here
А вам не кажется, что у вашего варианта читаемость сильно ниже при беглом просмотре кода? Или это у меня только такое, субъективное?

Насчёт линейного времени — зависит от того, что за коллекция. Там может быть ArrayList или Vector, и там время доступа будет константное (но мы можем не знать, что у нас там на самом деле, т.к. интерфейс единый). При маленьких объёмах данных — это вообще, имхо, не суть важно.

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

P.S. Самое главное — я не понимаю, почему для вас стандартный заголовок цикла for(), который, кстати, одинаков вообще для любого C-подобного языка — это «отвлекаться на индексы». Такое вообще пишется (или вставляется по хоткею) на уровне автоматизма… Вот производительность кода — это да, серьёзно.
А вам не кажется, что у вашего варианта читаемость сильно ниже при беглом просмотре кода? Или это у меня только такое, субъективное?

Я, конечно, не s-kozlov, но нет, не кажется. Оно, как раз-таки сильно проще и приятнее. Меньше лишнего кода, меньше возможностей для выстрела себе же в голову.

P.S. Самое главное — я не понимаю, почему для вас стандартный заголовок цикла for(), который, кстати, одинаков вообще для любого C-подобного языка — это «отвлекаться на индексы».

Если человек не совсем дуб, то при итерации он в самом начале выделит элемент коллекции в переменную, аля var test = testList.get(i); В таком случае встреча индекса и использование коллекции в дальнейшем коде будет означать что-то специфическое. И, в целом, отвлечения на индексы особо не будет(но тут возникает вопрос — зачем? Зачем вручную прописывать создание переменной и использовать for(;;) конструкцию, когда есть более лаконичный foreach?)

А если человек дуб, то он просто везде будет использовать testList.get(i), что увеличит объём кода, уменьшит его читаемость и увеличит шансы случайно пропустить выстрел или логическую ошибку в виде testList.get(j) или testList.get(i-j)

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

Чтобы не создавать итераторы.

UFO landed and left these words here
Квадратичным оно станет только в случае с настоящим списком (LinkedList, например). Если быть совсем точным — там будет O(n² / 2). В случае с тем же Vector всё будет линейно.
В случае с тем же Vector всё будет линейно.

У меня маленькое замечание не относящееся к делу прямо. Класс Vector остался в джаве только потому, что нельзя ломать спецификацию. Он — тяжёлое наследие прошлого. Использовать его нельзя.

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

Что касается ArrayList — он как бы есть, но он ничем не лучше. К тому же, он не является потокобезопасным.
Что за глупости? Только его обычно и используют, когда нужен динамический массив с изменяемой длиной.

Это не глупости, это суровая реальность. Если пишешь на Java и нужен динамический массив — нужно использовать ArrayList.


Что касается ArrayList — он как бы есть, но он ничем не лучше. К тому же, он не является потокобезопасным.

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


Если нужна потокобезопасность Vector тоже плохой выбор. Нужно использовать либо обёртки, которые делают любую коллекцию потокобезопасной, такие как Collections.synchronizedList, либо использовать специализированные коллеции, такие как CopyOnWriteArrayList.

приводит к синхронизации потоков

В том-то и дело, что обычный код, как правило (могу ошибаться, поправьте) исполняется всегда в один поток (кроме обработки GUI). А раз так — ему пофиг, что использовать. Если же приложение многопоточное — всё равно нужна синхронизация будет, скорее всего.

Если нужна потокобезопасность Vector тоже плохой выбор. Нужно использовать либо обёртки, которые делают любую коллекцию потокобезопасной, такие как Collections.synchronizedList, либо использовать специализированные коллеции, такие как CopyOnWriteArrayList

А чем они лучше Vector?
В том-то и дело, что обычный код, как правило (могу ошибаться, поправьте) исполняется всегда в один поток (кроме обработки GUI). А раз так — ему пофиг, что использовать.

Даже если код выполняется в один поток — вся машинерия, которая синхронизирует потоки всё равно отрабатывает честно и честно жрёт время процессора. Поэтому нет, не пофиг. ArrayList эту машинерию не задействует вообще, поэтому он быстрее. Разработчики JDK рекомендуют использовать ArrayList там, где потокобезопасность не нужна. Так и написано — If a thread-safe implementation is not needed, it is recommended to use ArrayList in place of Vector.


А чем они лучше Vector?

Обёртки делают практически то же самое, что Vector. CopyOnWriteArrayList обеспечивает потокобезопасность тем, что делает новую копию внутреннего массива при каждом изменении. Его надо использовать если коллекцию в основном читают и иногда в неё что-то пишут.

Прочитал про эти обёртки по Вашей ссылке. Но неужели копирование при каждом изменении — это быстро?.. Всё равно же накладные расходы огромны. Чем это лучше использования Vector?

Вариант Vector:
1 поток на запись, 20 потоков на чтение — стопаем всех при каждом обращении к вектору,
Вариант CopyOnWriteArrayList:
1 поток на запись, 20 потоков на чтение: да потоки на чтение могут получить устаревшую информацию, но они всегда могут прочитать из массива без остановки, блокируют ли друг друга потоки на запись — не помню, надо смотреть спеку.
В общем для ситуации "в основном читаем, изредка пишем" идеальная коллекция.


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


Смотрите, foreach подразумевает то, что о типе итерируемой сущности позаботится рантайм (или компилятор). В случае с JavaScript (я в основном пишу на нём), использование for… in, перебирающего все ключи объекта либо индексы массива — реально очень плохая идея, если у нас обычный массив. for всегда будет быстрее. JS правда, в отличие от Java, не компилируется в байт-код в общем случае (точнее, компилируется в него прямо перед исполнением, и время этой компиляции нам тоже важно).

Ох, юноша, ну куда же вы со своим js в обсуждение java? Ведь надо понимать, что и структуры и алгоритмы под капотом синтаксического сахара сильно разные. В Java foreach это скрытый вызов итератор и обход по нему. И не надо думать, что если в js есть слово java, то они хоть чем-то похожи.


Кстати, на минутку — есть какой-то аргумент, чем итератор лучше цикла for? Тем, что он сохраняет стейт коллекции в момент начала обхода? Так он ничего не сохраняет, там при попытке изменения коллекции исключение выкинет…

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


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

Початайте Кнута, дельные вещи мужик написал. Ещё можете почитать/посмотреть доклады про оптимизации Шипилёва — очень доходчиво рассказывает про трудозатраты vs результаты оптимизаций. Не помню только, говорил ли он, что новичкам в языке лучше вообще не связываться с оптимизацией… Там ведь надо уже понимать как jvm твой код обработает и во что превратит…
В общем случае лучше писать правильный/красивый код, а оптимизации оставить на горячие участки, которые реально нужно ускорять.


Кстати, забыл добавить: выше комментаторы указывали, что создание итератора — это лишние накладные расходы, и в некоторых случаях они могут быть существенными. Тогда зачем использовать foreach вместо for (то, что это сахар — уже замедлит компиляцию в байт-код как минимум на копейки, плюс само наличие итератора, которое может быть нежелательным)? Не говорите только опять про опечатки в буквах, такие ошибки — это даже не уровень школы, серьёзный программист никогда их не допустит (да и IDE не даст).

Нет, создание итератора — не очень дорогая операция и если не жарить её миллионы раз на одной коллекции худо от них не будет точно. Время компиляции в java так же в большинстве случаев пренебрежимо мало и происходит один раз — при сборке пакетов (ну разработчик пару наносекунд подождёт, чего уж там, ага?). Худшее что я видел — пара минут на дофига кода. Гораздо хуже какой-нибудь gwt, который из 1-2к строк будет минуты 3 комплиться. Для кого долго — пусть покомпилят программы на c/c++.
Про опечатки — это хлеб стат. анализаторов и это первое чему они учатся. Да сейчас их встраивают в IDE, но онлайновые всё же далеки от совершенства. И да, даже с ними можно пролететь с опечаткой. Почитайте тематические статьи, если интересно. Но на исходниках > 10к "рассмотреть всё глазками" не работает почти никогда.


С последним утверждением — полностью согласен. Проблема в том, что цикл for — это не «фишка» только JavaScript. Такие циклы можно встретить и в программах на C, C++, ActionScript и PHP, как минимум. То есть это общепринятая конструкция. Да, в Java могут быть лучшие способы итерирования, и не только в Java. Но писать код, понятный программисту на любом языке — имхо, не есть минус…

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


PS простите за комментари n-in-1, минусы отрицательной кармы при недостатке писательских навыков :-)

В общем для ситуации «в основном читаем, изредка пишем» идеальная коллекция.

Согласен. А если у меня вообще поток всего один, и никто никого не блокирует? Можно ещё раз на пальцах, чем Vector медленнее ArrayList в случае одного потока?

И не надо думать, что если в js есть слово java, то они хоть чем-то похожи.

Я так и не думал, вы что.

В Java foreach это скрытый вызов итератор и обход по нему.

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

Итератор не сохраняет состояние, он отказывается работать с изменённой коллекцией.

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

Не помню только, говорил ли он, что новичкам в языке лучше вообще не связываться с оптимизацией… Там ведь надо уже понимать как jvm твой код обработает и во что превратит…

Соглашусь :) Именно поэтому я особо и не заморачиваюсь с быстродействием своего Java кода. Ну хотя наверное я начну это делать, только когда всё очень сильно начнёт тормозить…

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

Так никто и не спорит! Там же выше шла дискуссия о том, нужно ли использовать итератор, если он даёт оверхед. Моё мнение — если можно на этом сэкономить, то не стоит: обход по индексам, в случае, если соблюдены все меры предосторожности, даст тот же эффект в случае не списка.

ну разработчик пару наносекунд подождёт, чего уж там, ага?

Да Вы оптимист! У меня не самый большой курсовой проект комплилися на среднем железе (окей, на довольно слабом железе для тех лет) секунд 7-8. Это простой проект. А если что-то тяжёлое? Тут и 1-2 секунды можно лишних получить, особенно если плохой HDD вместо SSD.

Для кого долго — пусть покомпилят программы на c/c++.

Я в курсе про время компиляции программ на C++. Вы правда считаете, что это хорошо? Я вот не понимаю, как люди вообще так живут и работают (в случае, если у них нет супербыстрого корпоративного билд-сервера, а обычный ноут).

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

Онлайновые — это какие? Там имели в виду случай, когда в заголовке или теле цикла перепутана буква итератора. Как минимум любая IDE подчеркнёт ошибку, если мы напишем j вместо i, а такой переменной у нас нет. Да, бывают случаи вложенных циклов, бывает, когда переменная j есть внутри тела цикла, и мы опечатались в каком-то индексе. Ну а отладка на что? Точки останова? Юнит-тесты, в конце концов? Обычное тестирование «руками» на нескольких наборах данных? Такая ошибка обычно всплывает на первом же прогоне!

Но на исходниках > 10к «рассмотреть всё глазками» не работает почти никогда.

Вы что, за раз добавляете и коммитите 10k строк? Нет, вы обычно добавляете строк 100-200, ну в крайнем случае 500. А длина одной функции вообще в идеале должна быть строк 40-50, не больше. И циклов там — ну максимум 2-3. К чему тут обсуждать общий размер кодовой базы проекта вообще?

Просто поймите, есть стандарты кодирования. Для каждого языка.

Опять Вы про что-то не то говорите. Стандарт кодирования — это скорее про правила оформления кода. Например, то, что в C# открывающая фигурная скобка класса переносится на новую строку, в отличие от Java. Это да, тут я не спорю, лучше делать так, как рекомендует разработчик языка (хотя даже это можно перенастроить в IDE под себя и делать по-своему — если работаешь не в команде, либо если ты возглавляешь команду и сам определяешь правила оформления кода). Но цикл for-то тут причём? Это вполне себе легитимная конструкция языка Java! Это не какой-нибудь goto, который кое-где ещё есть, но использовать его не советуют. Никто его использовать не запрещает, более того, он для этого изначально и был предназначен — для обхода массивов в том числе. Да, в Java он пришёл скорее всего как наследие из C/C++, но я не видел ещё ни одной статьи, которая утверждала бы, что «for в Java — это зло, по возможности никогда его не используйте».

PS простите за комментари n-in-1

Да нет проблем. Хотя отвечать и правда чуть проще было бы в случае нескольких комментариев поменьше. Но проблему вложенности это не решит, да и объём текста для ответа тоже не уменьшит, так что невелика беда :)
А если у меня вообще поток всего один, и никто никого не блокирует? Можно ещё раз на пальцах, чем Vector медленнее ArrayList в случае одного потока?

Случай с одним потоком это как раз тот случай, когда Vector всегда медленнее. Потому, что любой метод у Vector работает дольше, чем у ArrayList за счёт того, что на каждом методе Vector осуществляется синхронизация. Когда поток один, синхронизация не нужна, но время на неё всё равно уходит.

Это да. Но насколько эта синхронизация замедляет работу? Можно какие-то бенчмарки найти? Ведь мы никого «не тормозим», по идее, раз один поток.
Это да. Но насколько эта синхронизация замедляет работу?

На столько, что из-за этого замедления разработчики JDK и добавили ArrayList

Мне бы в процентах. А лучше — в мс для типового сценария (для списков размеров не больше 100 элементов, например). Я просто не пишу программ, где требуется очень высокая производительность…
Если вы пишете программы, которые будут читать другие разработчики на этом языке, то использовать Vector — дурной тон. Одного этого вам должно быть достаточно, чтобы не использовать его.

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

Вам уже десяток людей сказала — потому что для обычных коллекций в большинстве случаев принято использовать ArrayList.
Почему? Потому что Vector медленнее и в большинстве случаев синхронизация излишняя.

Бенчмарки гуглятся за полторы минуты, будь у вас такое желание.
stackoverflow.com/questions/17471913/java-vector-vs-arraylist-performance-test
www.baeldung.com/java-arraylist-vs-vector

И суммарно, если вы будете использовать Vector, то вы будете этим показывать свой низкий уровень владения языком, поскольку в 95% случаев это будет не оправданным решением, а лишь потому что вы так привыкли и вам так удобнее.

И, помнится, вы так ратовали за то, что использование foreach накладывает оверхед и лучше обходиться простым for с индексацией. Раз вы так боретесь за оверхед, то почему же используете Vector, который его вносит? Не находите противоречие?
И суммарно, если вы будете использовать Vector, то вы будете этим показывать свой низкий уровень владения языком, поскольку в 95% случаев это будет не оправданным решением

Может и так. Я просто не понимаю вот этого вот «дурной тон», как-то очень категорично прозвучало. такое ощущение, что у вас прямо кровь из глаз льётся каждый раз, когда Вы слово «Vector» видите в коде. Несерьёзно как-то :)
Я просто не понимаю вот этого вот «дурной тон», как-то очень категорично прозвучало. такое ощущение, что у вас прямо кровь из глаз льётся каждый раз, когда Вы слово «Vector» видите в коде.

Когда вы, в 2019 году будете писать стандартами 2000 года — это дурной тон. Крови из глаз не будет, однако наладить коммуникацию с коллегами вам будет куда сложнее.
Банально, видя ваши постоянные for и vector — на ревью к вам постоянно будут подходить и, скажем так, вбивать в голову — что так писать нельзя. Есть более подходящие инструменты.
Про veсtor и arrayList прекрасно написано тут, stackoverflow.com/questions/1386275/why-is-java-vector-and-stack-class-considered-obsolete-or-deprecated
Эта ссылка была в бенчмарке, который я кидал выше.

Несерьёзно как-то :)

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

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


такое ощущение, что у вас прямо кровь из глаз льётся каждый раз, когда Вы слово «Vector» видите в коде.

Ну в общем да, ощущение верное. Как только видишь Vector в коде, сразу становится понятно, что там помимо вектора можно запросто встретить вообще всё, что угодно. Например, я встречал вместе с вектором ConcurrentHashMap в однопоточной программе. Код, где есть вектор явно надо вычитывать в поисках проблем, которых в коде человека, знакомого с джавой, просто не может быть. Чаще всего встречается заблуждение, что если используешь Vector, то с синхронизацией можно вообще не заморачиваться, он всё сделает. Поэтому да, "кровь из глаз". На ревью, кстати, код с Vector не пропустят. Поэтому писать такой код бессмысленно.

Вы хотите его использовать потому, что вам название больше нравится? Вот это уже чутка странно.

Когда использовал его в первый раз — просто принципиально хотелось выпендриться и сделать не так, как в листингах, которые нам раздали. То есть попробовать что-то своё. Попробовал — получилось, интерфейс-то идентичный. Я там ещё и Hashtable вместо HashMap в одном месте заюзать умудрился. Один раз правда всего)

Чаще всего встречается заблуждение, что если используешь Vector, то с синхронизацией можно вообще не заморачиваться, он всё сделает.

Не всё. Нам в универе рассказывали, в чём нюанс, и в учебнике по Java было это написано. И я это помню прекрасно. Синхронизированы только отдельные операции, общую синхронизацию нужно обеспечивать самостоятельно.

На ревью, кстати, код с Vector не пропустят.

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

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


Почему [Vector не пропустят на ревью]? Производительность? Так не всегда она является узким местом

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

Возможно когда-то такое не пропускали из-за производительности.

Ещё раз — нам никто из преподов категорически не запрещал использовать векторы (хотя упоминали, что у них довольно плохо с производительностью). Это был 2010-ый год. Java SE 6, на минутку :)

по которым не пропускают плохо отформатированный код

А не проще его доформатировать и принять? Тем более, сейчас есть всякие линтеры и средства бьютификации.
Ещё раз — нам никто из преподов категорически не запрещал использовать векторы

В IT с хорошими преподавателями серьёзная проблема. Те, кто разбирается в предмете редко занимаются преподавательской деятельностью, увы ((.


А не проще его доформатировать и принять?

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

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

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

Предыдущий комментатор говорит про далёкость преподавателей (в том числе ваших аспирантов) от промышленной разработки. Это сказывается и сильно на том, какой и как они дают материал. И да, Vector нерекомендован к применению самими разработчиками java.


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

Предыдущий комментатор говорит про далёкость преподавателей (в том числе ваших аспирантов) от промышленной разработки.

Я бы не сказал так. Тот парень в «ЛАНИТ-Теркоме» работал. Правда, его основной язык таки C++ :)

требования к лабам существенно ниже, чем требования к промышленным программам

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

У него не просто основной язык c++, он в принципе работал(ет) в компании, которая занимается преимущественно разработкой на этом языке (ещё у них там есть мобильщики, ага… но это свой отдельный мир всё же).
В общем вопрос в том, что применять в java технологии c++… это по меньшей мере странно.


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

Привидите пример вашей лабы:


  • какие задачи решает?
  • насколько критична скорость/производительность/потребление?
  • что будет, если будет 100/1000/10000 и больше запросов в минут?
В общем вопрос в том, что применять в java технологии c++… это по меньшей мере странно.

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

Привидите пример вашей лабы

Ну, она не совсем лаба, а семестровая/курсовая, но не суть, не будем раздувать значимость :)

Визуализатор алгоритмов на графах. Задача — выполнять алгоритмы, подсвечивая в риалтайме состояние рёбер и вершин, вести логи операций. Есть встроенный редактор графов и удалённое хранение на сервере даже (не помню уже, зачем это делал). Соответственно, есть сервер под это дело в виде отдельной утилиты (с GUI). Он тоже использует векторы. Но я никогда не проводил нагрузочного тестирования всего этого. Скажем так, 1 клиент с 8-10 запросами в секунду (всего порядка 25-30 запросов, передача данных построчно в текстовом формате без использования даже HTTP протокола) — это не нагрузка.
Но меня он за код с векторами по рукам не бил, я вот о чём. Просто всех призывал учитывать, когда что лучше применять (в том числе учитывая то, нужна ли многопоточность).

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


Визуализатор алгоритмов на графах. ...

Т.е. получаем:


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

есть подозрение, что jvm у вас кушает больше, чем ваша программа
Не исключаю, что так и есть :)

а что за сервер, не подскажете (какие библиотеки, протокол, ...)?
Никаких библиотек. Текстовый протокол собственного сочинения, обмен через сокеты. И я прекрасно помню, там была проблема нарушения порядка прохождения отдельных запросов (отправляем 1, 2, 3, ..., 10, приходит 3, 4, 1, 6, 5, ...). Я не знал, как пофиксить это по уму, поэтому просто ввёл в протокол нумерацию строк. Кстати, новый коннекшен на каждую строку не делался, просто шла запись в стандартный PrintWriter через println. Могу покопаться в коде и посмотреть, как там было сделано.
Ну у нас по практике преподы были молодые (аспирант по сути). Так что книжки они читали тоже довольно новые, на возраст тут не спишешь.

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


Мне всё-таки кажется, это Вы излишне категоричны в суждениях.

Я категоричен, но не излишне.


То, что вектор неоптимальный вариант и более медленное решение — не мешает его применять

Именно это и мешает.


и получать работающий, и даже не глючащий продукт

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


Опять же — я применял его столько лет

Самое время перестать ))


и не разу не получил ни одной проблемы (с производительностью в том числе).

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

Я категоричен, но не излишне.

Категоричность — это плохо :)

Именно это и мешает.

Нисколько. Ваша позиция сейчас напоминает позицию человека, который призывал бы использовать ассемблер вместо C/C++, потому что «так быстрее работает и легче контролировать результат».

Самое время перестать ))

С чего вдруг? Работает же. И даже если его «выпилят» в будущих версиях JVM совсем — те проекты, которые я писал под Java 1.6, так и останутся работать под 1.6 (в крайнем случае, под 1.7). Так что даже это не проблема.

Проблем на код ревью у вас не было либо потому, что не было код ревью

Да, их не было. Было тестирование собственными силами, чтобы понять, есть ли ошибки, и достаточно ли всё оптимально работает. В том числе и в плане скорости.

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

Браво, вы наконец-то это поняли. Так зачем тогда там что-то переписывать, раз она не критична?)
Нисколько. Ваша позиция сейчас напоминает позицию человека, который призывал бы использовать ассемблер вместо C/C++, потому что «так быстрее работает и легче контролировать результат».

Если бы ассемблер и C/C++ ничем, кроме названия не отличались, ваша аналогия была бы хорошей. В данном случае она плохая.


Так зачем тогда там что-то переписывать, раз она [производительность] не критична?)

Вы всё это время думали, что я предлагаю вам переписать старый код? Я советую не использовать Vector в новом. Хотя старый код имеет смысл поправить если вы занимаетесь поддержкой проекта, просто, чтобы не было стыдно за свой код. Это конечно, если проект вам не совсем безразличен.

просто, чтобы не было стыдно за свой код
Я больше всего не согласен вот с этим. Не понимаю, почему за код с Vector должно быть стыдно, если он работает корректно и не тормозит.
Это с чего вдруг?.. Там интерфейс абсолютно такой же.

Что интересно, и у LinkedList точно такой же интерфейс.


Разница только в производительности

И с LinkedList у ArrayList разница в производительности и ещё в количестве используемой памяти. Но с процессом чтения кода это не связано никак.


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

Что интересно, и у LinkedList точно такой же интерфейс.

И это хорошо. Специально же так спроектировано.

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

Между этими двумя коллекциями разница ещё меньше. Только вот час назад читал отличный вопрос на STO на эту тему :)

По сути, зависит от того, что нам нужно делать чаще: удаление/вставку или доступ к произвольному элементу (да, вставка в LinkedList тоже побыстрее, поиск по нему в среднем N/4, а в случае с ArrayList нам нужно делать сдвиг хвоста, и там в среднем N/2). В плане обхода — вообще без разницы. Оверхед по памяти — есть, но крайне мал, и чем меньше список, тем он меньше в абсолютном значении.

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

Разница между LinkedList и ArrayList огромна.


В плане обхода — вообще без разницы.

Разница большая, LinkedList не ложится в кеш.


Оверхед по памяти — есть, но крайне мал

LinkedList занимает в памяти где-то в 6 раз больше места, чем ArrayList.


Там везде только обходы, поэтому что именно использовать — там почти всё равно

Так как там только обходы — использовать можно только ArrayList.


P. S. Прошу прощеня за краткость, стараюсь писать только главное. Работа ))

Разница между LinkedList и ArrayList огромна.

Не так и огромна. Посмотрите сами сравнения:
stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist-in-java

LinkedList занимает в памяти где-то в 6 раз больше места, чем ArrayList.

Простите, «лолшто»? Там оверхед в в два указателя на каждый элемент списка, и всё. Вы разве не в курсе, что память под указатель имеет постоянный размер независимо от типа (и количества полей и методов в классе, на который мы ссылаемся)?

Ссылка на объект или массив занимает одно 32-битное слово (4 байта) на 32-битной виртуальной машине JVM или Davlik. A null занимает то же место, что и ссылка. (Он должен, потому что нуль должен быть помещен в слот с типизированным типом, то есть поле экземпляра, локальную переменную и т.д.)

С другой стороны, объект занимает минимум 2 32-битных слова (8 байтов), а массив занимает минимум 3 32-битных слова (12 байтов). Фактический размер зависит от количества и типов полей для объекта, а также от количества и типов элементов для массива.

Для 64-разрядной JVM размер ссылки составляет 64 бита, если вы не настроили JVM на использование сжатых указателей.
Не так и огромна. Посмотрите сами сравнения:

Сравнение неполное, но даже там с самого начала написано, что почти всегда надо использовать ArrayList. В комментарии, кстати, есть уточнение про кеш.


Простите, «лолшто»?

"лолLinkedListбольшеArrayListгде-тов6раз" ))


Там оверхед в в два указателя на каждый элемент списка, и всё.

Ну, то есть по вашему мнению LinkedList занимает всего в 3 раза больше, чем ArrayList?


Вы разве не в курсе, что память под указатель имеет постоянный размер независимо от типа (и количества полей и методов в классе, на который мы ссылаемся)?

Ладно, шутки в сторону. В ArrayList на один элемент приходится 1 указатель на объект, то есть 8 байт. В LinkedList — указатель на объект — 8 байт, указатель на следующую ноду — 8 байт, указатель на предыдущую ноду — 8 байт, оверхед на объект с нодой — 16 байт.


Это у нас получает разница в 5 раз. По умолчанию в джаве включена компрессия указателей. Тогда на указатель приходится 4 байта и разница получается не в 5, а в 7 раз. Плюс могут быть различия в зависимости от конкретной реализации JVM. Такие дела.

А если у меня вообще поток всего один, и никто никого не блокирует? Можно ещё раз на пальцах, чем Vector медленнее ArrayList в случае одного потока?

На примере извлечение элемента i:
ArrayList:
Операция 1: берём указатель на внутренний массив (лёгкая операция в малое количество циклов)
Операция 2: извлекаем из массива элемент i (лёгкая операция в малое количество циклов)
Vector:
Операция 1: Входим в монитор (тяжёлая операция в существенно большее количество циклов)
Операция 2: Получаем указатель на внутренний массив (лёгкая операция в малое количество циклов)
Операция 3: Извлекаем элемент i из массива (лёгкая операция в малое количество циклов)
Операция 4: Освобождаем монитор (не помню точно, насчёт сложности операции)
Вот и посчитайте, что выполнится быстрее. Пример приведён исключительно для однопоточного приложения. Для многопоточного доступа (если у нас только чтение — то можно же и из ArrayList-а читать) там будут ещё нюансы, что читает одновременно только один поток, а остальные тупо стоят ждут.


Создание итератора — в самом деле лишние накладные расходы, которых можно избежать. Зачем нам итератор? От него выигрыш только в случае использования LinkedList. Но если мы решим его использовать, то и несколько циклов в этот момент можно будет переписать, которые с ним работают. В чём проблема-то?

Потому что, чем меньше мест где можно накосячить — тем меньше багов в программе. Foreach не даёт возможности накосячить, for через интовый итератор — только в путь. При этом проигрышь по производительности от итератора в большинстве случаев не ощущается от слова никак. А вот там, где ощутили — там и нужна оптимизация. В общем code convention — они не просто так придуманы.


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

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


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

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


Так никто и не спорит! Там же выше шла дискуссия о том, нужно ли использовать итератор, если он даёт оверхед. Моё мнение — если можно на этом сэкономить, то не стоит: обход по индексам, в случае, если соблюдены все меры предосторожности, даст тот же эффект в случае не списка.

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


Да Вы оптимист! У меня не самый большой курсовой проект комплилися на среднем железе (окей, на довольно слабом железе для тех лет) секунд 7-8. Это простой проект. А если что-то тяжёлое? Тут и 1-2 секунды можно лишних получить, особенно если плохой HDD вместо SSD.

В java как-то принято в модульность. Реально проектов на 100 тысяч строк и больше не так уж и много, но даже эти проекты собираются за пару минут. Вот тесты могут крутиться уже существенно дольше. И я говорил про оверхед от единичного использования синтаксического сахара.


Онлайновые — это какие?

Онлайновые — это которые IDE запускает во время написания кода и/или простоя самостоятельно.


Там имели в виду случай, когда в заголовке или теле цикла перепутана буква итератора. Как минимум любая IDE подчеркнёт ошибку, если мы напишем j вместо i, а такой переменной у нас нет.

А если такая переменная есть?


Да, бывают случаи вложенных циклов, бывает, когда переменная j есть внутри тела цикла, и мы опечатались в каком-то индексе. Ну а отладка на что? Точки останова? Юнит-тесты, в конце концов? Обычное тестирование «руками» на нескольких наборах данных? Такая ошибка обычно всплывает на первом же прогоне!

Простите, вы собираетесь каждый кусок кода вручную тестировать? Иначе зачем вам эти самые "отладка" и "точки останова"? Нет на это времени практически никогда. К такому способу тестирования прибегают в 2х случаях: есть бага, но не до конца понятно, в какой момент алгоритм лажает, или код совсем уж труднотестируем автоматически — так вручную на паре-тройке наборов прогоняется… Юнит-тесты… Вы слышали о 100% покрытии не в TDD? А большинство работает не по TDD. А вы в курсе, что реально все случае проверить нереально, именно поэтому появилась такая штука как "мутационное тестирование"? В общем способов-то обезопаситься много… но вот foreach реально тупо дешевле. Его использования занимает условно секунду, а тесты/юнит-тесты/прочие радости — минуты, часы, ...


Вы что, за раз добавляете и коммитите 10k строк? Нет, вы обычно добавляете строк 100-200, ну в крайнем случае 500. А длина одной функции вообще в идеале должна быть строк 40-50, не больше. И циклов там — ну максимум 2-3. К чему тут обсуждать общий размер кодовой базы проекта вообще?

Ну бывает, что и по 2к строк за раз в коммит уходит, пусть и крайне редко… Средний коммит, да — 100-400 строк. А длина функции больше 10 строк — это уже сигнал внимательно на неё посмотреть и по возможности разбить… Вот только как всегда, есть нюанс: баги привносятся чаще всего не в том месте, которое изменяют, а в те места, которые от него зависят. И чем больше кодовая база, тем больше случаев взаимного использования разных кусков кода. А опечатки "замыленый" глаз банально не видит даже в 10 строчках (проверено неоднократно).


Опять Вы про что-то не то говорите. Стандарт кодирования — это скорее про правила оформления кода.

Вы не поверите, но использование (или не использование) синтаксического сахара — это тоже часть стандартов кодирования.


Но цикл for-то тут причём? Это вполне себе легитимная конструкция языка Java!

Ну так кто же заставляет от цикла-то отказываться? Только вот количество возможных вариантов его использования снижаются сознательно — выше уже неоднократно писал почему


Это не какой-нибудь goto, который кое-где ещё есть, но использовать его не советуют.

Вот 90% говорящих про вред goto никогда не пользовались goto. В грамотных руках — отличнейшая инструкция… а в ассемблере — так и вовсе никуда без неё.


Никто его использовать не запрещает, более того, он для этого изначально и был предназначен — для обхода массивов в том числе.

Стандарты кодирования могут запрещать. Из тех же соображений, что и goto.


Да, в Java он пришёл скорее всего как наследие из C/C++, но я не видел ещё ни одной статьи, которая утверждала бы, что «for в Java — это зло, по возможности никогда его не используйте».

Ну так вы не представляете, сколько альтернативных путей использования цикла for, не включающих в себя обход массива! И никто там его не запрещает.

Входим в монитор (тяжёлая операция в существенно большее количество циклов)

Спасибо, и правда наглядно. Я примерно так и представлял себе работу вектора. Но я не знаю абсолютно, как в Java устроены мониторы. Надо бы почитать. Просто может ведь оказаться, что не такая уж это страшно тяжёлая операция, как многим кажется :) Это ведь всего лишь специальный объект со своими методами и полями. И если одновременно запущенных потоков — минимум, то на что там может уйти так уж много процессорных тактов, я так и не понимаю.

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

Так я ж писал — нельзя серьёзный алгоритм (который может привести к серьёзным проблемам из-за багов) пихать в прод, толком не протестив. Особенно если программа многопоточная. Сначала юнит-тесты хотя бы сделать и прогнать надо… И даже с точки зрения самого алгоритма — ваш подход не решит проблему, а только сделает её более явной и заметной. А чтобы её решить, надо сам код переписывать. например, перед обходом коллекции делать копию, как я предложил выше.

Половина багов возникает по невнимательности, вторая половина — при изменении изменении зависимого/зависящего от этого куска кода.

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

И я говорил про оверхед от единичного использования синтаксического сахара.

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

А вы в курсе, что реально все случае проверить нереально, именно поэтому появилась такая штука как «мутационное тестирование»?

Все — не реально, но все имхо как правило проверять и нет необходимости. Про мутационное тестирование увы не читал :)

К такому способу тестирования прибегают в 2х случаях: есть бага, но не до конца понятно, в какой момент алгоритм лажает, или код совсем уж труднотестируем автоматически — так вручную на паре-тройке наборов прогоняется…

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