Комментарии 1335
Даешь суровый олдскул!!!
не смог удержаться )
Переходи на тёмную сторону. У нас есть печеньки!
У нас есть печеньки!
Но жрать их запрещено.
Пфф. Распространённое заблуждение. Зло не дремлет ибо хорошо высыпается. На тёмной стороне каждому положен полный соцпакет, печеньки, бесплатный спортзал, длинный отпуск с оплатой расходов и курсы по повышению квалификации. Монстрам, получившим увечья в борьбе с героями предоставляется компенсация и пожизненная пенсия. Гибкий график, возможность карьерного роста, уважение к личности и индивидуальный подход. На службе у Зла каждый найдёт занятие по душе и поддержку личных проектов.
В R&D отдел срочно требуются Middle Mad Scientist, имеющие опыт работы с магическими кристаллами и плазменным оружием, либо желающие его получить. Гибкий график, оформление по ТК. Молодой и дружный коллектив непризнанных гениев. Белоснежный халат и курсы по злобному смеху за счёт компании.
В ответ я доставал из рюкзачка бутерброд с колбасой и демонстративно поедал. Нашли чем приманивать! У Светлых со снабжением полный порядок. А тут какие-то печеньки… Cо временем я смеяться перестал. C нашей стороны всё было замечательно. Свой паёк я получал и мог на выпад Тёмных показать то рябчика, то ананас, другие деликатесы. Они предлагали печеньки. Cтранно. Нет, я сознавал, что у нас не каждый может себе позволить рябчиков с ананасами, но это только справедливо! Кто получает меньше, кто больше, но в целом все довольны, голодающих нет. И строй самый лучший, экономика процветает. А с Тёмной стороны мрак и беззаконие, и разруха, и коррупция, и военная диктатура… ужас творится! И всё-таки… у Тёмного всегда есть печеньки. Символический, но прожиточный минимум. Каждому, без исключения. Не хватает других вещей — лекарств, жилья, боеприпасов — но печеньки есть всегда. Для всех, без обмана. Это внушало уважение. И настал день, на обычный окрик «Эй, Светлый, не хочешь к нам? У нас есть печеньки!» я неожиданно для себя, но совершенно искренне ответил «хочу!» С той поры я на Тёмной стороне. Да, несладко. Да, у нас тут бывают проблемы. Зато у меня есть печеньки! Полные карманы! Светлая сволочь разбудит меня среди ночи и спросит: «Ну, и где..?» — я всегда готов их показать. Печеньки не кончатся никогда! Есть их категорически запрещено.
— Из комментариев к произведениям Давыдова Сергея
Есть и другой подвох во фразе «у нас есть печеньки»
bormor.livejournal.com/371852.html
Переходи на тёмную сторону. У нас есть печеньки!
Брауни?
…«Субкультура может отличаться от доминирующей культуры собственной системой ценностей, языком, манерой поведения, одеждой и другими аспектами[1][2]. Различают субкультуры, формирующиеся на национальной, демографической, профессиональной, географической и других основах»…
Вы путаете профессиональную деформацию и субкультуру.
Это тоже мимо. Профессиональная деформация — это изменение восприятия под воздействием специфики профессии, включая шуточки.
Ездить на хакатоны, активно общаться на сайтах вроде Хабра
И что? С каких под посещение хакатонов и активность на Хабре стали частью профессии? Это сугубо опциональные вещи, весьма слабо влияющие на уровень вашего профессионализма.
Безусловно, среди программистов есть уйма представителей самых различных субкультур, но сама профессия — это ни разу не субкультура, поскольку вы без труда найдёте 2 программистов, у которых не будет ничего общего в плане систем ценностей, языка, манеры поведения и одежды.
Это тоже мимо. Профессиональная деформация — это изменение восприятия под воздействием специфики профессии, включая шуточки.
Именно так. Я просто описал некоторые внешние проявления, которые являются следствием изменения восприятия. Обычный человек не будет писать скрипт, рассылающий поздравления. Не потому, что не умеет писать скрипты, а потому, что понимает, что автоматические поздравления получать на самом деле неприятно :) А вот программист наоборот, может подумать, что это же прикольно — сделать поздравляющего девушек бота. И сделает.
поскольку вы без труда найдёте 2 программистов
Вы даже двух панков без труда найдёте, которые слушают разную музыку, ведут себя и одеваются по-разному. Профессиональная субкультура — это не какой-то кодекс правил, который надо принимать, вступая в профсоюз, а всего лишь набор моделей поведения и ценностей, которые больше присущи людям, принадлежащим соответствующей профессии. При этом совершенно естественно, что кто-то её не разделяет, кто-то не понимает, или наоборот, к ней может примкнуть кто-то посторонний. Участие в хакатонах, например, это чётко выраженная субкультурная модель поведения для программистов, особенно молодых. Подобных сборищ, где сочетается совместное решение какой-то практической задачи и дружеской вечеринки, нет ни у какой другой профессии. Прожигать время на хабре — менее выраженная модель, но тоже куда больше распространена в кругах именно ИТшников, чем в каких-то других.
Подобных сборищ, где сочетается совместное решение какой-то практической задачи и дружеской вечеринки, нет ни у какой другой профессии.
Дааа лааадно…
Раза 3 присутствовал на «попойке» на которой чинили автомобиль, рестайлили автомобиль, восстанавливали почти с нуля.
Пару лет почти еженедельно наблюдал «решение проблем строительства» (даже «возведения») какого-либо сооружения на очередной попойке.
Да те же приёмы высоких гостей «в бане» или корпоративы (одна из разновидностей) — подобные задачи решают.
Вы даже двух панков без труда найдёте, которые слушают разную музыку, ведут себя и одеваются по-разному.
Ну так панки давно уже на несколько субкультур разделились.
Есть на хабре несколько блогов разного рода инженерного спецназа, дык эти ребята могут с геологами по количеству экспедиций посоревноваться.
И потом айти уже во всех сферах науки.
В половине подводных научно-исследовательских экспедиций, участником которых мне довелось быть, нас сопровождали айтишники, которые писали софт к технике, с которой мы работали…
И многие из них по миру покатались достаточно и полевых у них за плечами то же хватает...
А вы думаете все геологи, биологи, и остальные географы, не вылезают из экспедиций?)
Есть те, кто поля никогда не видел, только на картинах и на даче разве, что.
Ваши стереотипы ошибочны.
Особенно в свете того, что этот пример, был приведён комментатором, касательно факта наличия и у тех и других своей субкультуры и не ставил их в один ряд по уровню "мачизма"
Офисный планктон (он же «офисное быдло», «канцелярская крыса»,«козявка приказная» и т. п.) — работники умственного труда с пониженной творческой составляющей, проводящие жизнь в офисах и прочих управлениях, но не относимые к инженерам: низшие менеджеры, бухгалтеры, секретутки, и т. д. Являют собой передаточные механизмы, винтики и смазку в механизмах управления, учета, планирования, финансов. Быстрорастущий пролетариат постиндустриального мира.
А планктон — это уже другое.
Особенно продвинутого ИИ для кораблей на маршрутах не надо: достаточно уже имеющихся инструментов автоматического принятия решения и автоматизации.
Проблема с кораблями состоит принципиально в другом поле (собственно, как и для многих других областей, как бухгалтерия, что ниже обсуждают). В международном морском праве судно без человека на борту — покинутое судно, а значит его может захватить кто угодно. Этому праву уже черт знает сколько лет и нет особых перспектив, что это дело как-то урегулируют в ближайшее время (ту же бухгалтерию полностью автоматизируют куда раньше).
На любом судне крутят штурвал несколько человек посменно. Остальные там с другими задачами. Например, команда механиков всё ещё намного дешевле, чем двигатель который обслужит и починит себя сам.
У самолётов ведь нет такой проблемы — иначе падал бы каждый второй рейс.
2. А ещё их обслуживать надо. У самолётов рейсы короче и обычно в родной порт к своим механикам. А иногда они точно так же возят механиков с собой.
3. Устранение одной небольшой поломки на супертанкере на ходу оплатит зарплату механика на годы вперёд.
И как результат всего выше, авиационный двигатель намного дороже изначально и в эксплуатации.
А про лётчиков — почитайте в блоге Туту.ру, как пилотам живётся, посмотрите видео. Вполне себе комфортная работа в большинстве.
В полку офисного планктона прибыло, значит.
дык, в этом и есть суть прогресса — всё больше людей делают всё больше дел не отрывая задницы от дивана
поэтому человечество в пределе — сборище офисного планктона
А вы сами попробуйте каждые пару дней туда-сюда летать то ночью, то днём, то в 5 утра, да по гостиницам ночевать — специфическое удовольствие, даже если просто паксом.
бгг, и эти люди
Офисный планктон — современное жаргонное выражение, используемое для обозначения «белых воротничков» — мелких офисных служащих ( (с) Вики)
Возникновение субкультуры — побочное явление любой сложной, требующей полной самоотдачи, занимающей всю жизнь человека профессии.
Ваш Капитан Очевидность.
Двуличная субкультура!!!
Любая субкультура производит культурные явления — обычаи, предметы, символы, идентифицирующие ее и при этом доступные для наиболее бедных из ее членов.
И такая вещь есть. Во-о-он тот пласт под понятиями OpenSource / Freeware. Явления, которое в равной степени существуют и затрагивают сферу каждого — и красноглазого линуксоида, и фронтендера со смузями.
С трудом можно представить условного булочника, приходящего с работы, встающего к печи и затем раздающего булки на улице. Однако же строки кода, как и строки стихов, сегодня доступны каждому.
Тут вспоминается цитата из "Ведьмака":
— Ну чего, ты хочешь меня на хер послать? Милости просим, сука, давай. Я тебя тогда тоже нахер пошлю. Ну и чего? Обнимемся, вместе пойдем, да?
Вот это — нормальная реакция здорового человека.
А жалоба на то, что кто-то с твоим мнением не согласен — ну тааакооооее...
Хабраюзеры в массе своей не хотят читать глупости.Не хотят, поэтому старательно читают, обдумывают, и после даже специально лезут на страницу профиля пользователя, чтобы сирануть в карму. Именно потому, что не хотят, ага :)
Понимаете ли, взрослый, сформировавшийся как личность человек, в отличие от инфантила, если не хочет читать глупости, он их просто… не читает (Внезапно!). А если читает — значит она ему интересна (пусть даже из энтомологического интереса), и здравая форма выражения этого интереса — изложение собственной аргументированной позиции. Конечно, если глупость совсем «за гранью добра и зла» — есть модераторы и почта для жалоб.
создать свой сайт с блекджеком
У меня идея одного блекджека давно уже носилась: если персонаж А поставил персонажу Б минус, то персонаж А комеентариев персонажа Б уже не видит, а все остальные — видят. И овцы сыты, и волки целы: персонажа А не раздражает персонаж Б, а персонажа Б не раздражает то, что у него отобрали права голоса.
почему вы считаете, что без минусования этого не случится?
Вот смотрите. Заходим в ветку любого *-срача и пишем комментарий, которые близок к нейтральному, но немного склоняется в одну из сторон (например: "по имеющимся у меня данным мне кажется, что в случае X имело место Y, потому что Z" — вполне рациональная позиция: человек описал имеющиеся у него данные и сделаные им выводы, при этом подчеркнул свою готовность изменить мнение, если будут предоставлены новые данные). При этом он тут же огребает минусов от противников этой точки зрения ("ату его, он против нас!") и… ничего от сторонников ("да ну его, он не за нас"). В результате имеем то, что имеем: карма неудержимо катится в минуса, независимо от того, чей Крым.
xkcd_про_свободу_слова.жпг
А сейчас ваш комментарий не получил плюсов, а плюс в карму прилетел. Как вам такой контраргумент?)
Я бы с удовольствием послушал оратора. Но ему накидали минусов в карму (-1), но у меня нету прав поставить ему (+1)
В итоге оратора «запинали».
Подозреваю, если человек выскажет свое «глупое, смешное и никому не интересное мнение» в ветке «не по профилю» (про БД выскажется спец по JS/C++), то в своем «профиле» — он уже тоже ничего не сможет сказать :)
Карму слили в «непрофильном» наказав за любопытсво, а в «профильном» это и так спецам понятно, зачем поошрять.
Насчет большинства и интереса: Аристотель как-то написал что у мухи 8 ног и ~2000 лет никто не удосужился это проверить до Карла Линея. Интересно, а скольким до него было сказано «У мухи 6 ног ?! Да ты, парень, идиот. Все знают что их 8!!! Слышишь, неполноценный умственно, 8! С Аристотеля!!!»
Не обижайтесь, но это очень забавно, когда про аристотелей, карлов линнеев и прочих джордано брунов пишут люди, которые ниасилили написать пост и нарастить кармическую подушку безопасности.
Я так понимаю, что по существу приведенного сценария и исторического факта сказать нечего. Разве что добавить язвительности, которая сформировала не плохой эмоциональный посыл, за который поставили +1.
Случайный социальный эксперимент :)
Я бы поддержал Ваше предложение с пояснениями по карме в чуть измененной форме: требование оставлять
Пример с мухой — он, мягко говоря, хрестоматийный. А говоря твёрдо — боян. Я его, помнится, приводил ещё на локальном общажном форуме, когда просил меня разбанить после того, как несколько раз высказал своё ценное мнение по различным вопросам. Но одмин был глух к мольбам. И, в общем-то, совершенно правильно. Хреновый из меня тогда был Карл Линней.
А это и было высказывание по существу.
Мой вопрос был прост: Как не имеющий права голоса может высказаться в поддержку того, с чьими высказываниями он согласен, но не согласно «голосующее большинство»? По вашим правилам, порог вхождения крайне высок(запретительный) :)
Если вы умный и без ваших мыслей Хабр много потеряет — накопите этих мыслей побольше и напишите пост.
У Вас не верная предпосылка. Репутация Хабра — любопытная штука, хороший механизм монетизации. Для владельцев ресурса :)
Не очень понятно, почему я должнен мои «гениальные мысли» выложить на Хабр, а не «замутить Свой Крутой Бизнес»? :)
Если не получается написать такой пост, то имеет место логическое отрицание условия из прошлого предложения.
В общем-то это и есть наглядный пример мехнизма «токсичности» :)
Не устроило большинство (или обладающего Правом), просто "-1" без пояснения и играй в угадайку :)
На мой взгляд, от того что «пример хрестоматийный» или «боян» разбрасываться его практической пользой — сомнительная практика.
Если форум созданы для обмена мнениями, это одно, если форумы созданы удовлетворить большинство — это другое :)
С точки зрения бизнеса — сценарий «большинства» предпочтителен:)
Вы почему-то считаете, будто каждое мнение априори кому-то интересно,
Априори ничего никому не интересно, ровно до того момента пока не станет касаться их лично и не начнет им угрожать.
а свобода самовыражения является основополагающей ценностью. Это невероятно далеко от правды.
Считайте это как «социальную эволюцию». Время от времени появляются новые виды (мысли). Каких-то «уродцев» выбрасывают, какие-то выживают и развиваются двигая общество вперед и защищая его.
Нету новых мыслей — застой.
Вы предлагаете убрать свободу самовыржения? Или оставить только управляемую «социальную эволюцию»?
P.S. Если что, я не хочу показаться высокомерным. Я в своё время по идеологическим соображениям гордо выпиливался с хабра, имея в активе статьи с рейтингом около 200. Я думал, это что-то будет значить. Неа, практически никто и не заметил. Система работает по принципу взаимозаменяемости винтиков. И это нормально.
Если регулярно выкашивать случайно выбранные 10% популяции, эволюция продолжит работать как ни в чём не бывало
…
Эволюция невозможна без отбора.
Все верно, за исключением проблемы масштабирования.
Если популяция ниже определеного порога, она вырождается и умирает.
Если будем выкашивать рандомно 10% в коллектие в сотни… тысячи… миллионы единиц- «эволюция» продолжится, но с меньшей скоростью.
А если такое будет в популяции в 5..20..100 единиц?
Не проявится ли «выученная беспомощность» со временем — зачем генерить повторно мысль, если ее выкосили включив в рандомные 10%? Остальным 90% тоже не сахар. Такие прецеденты тоже были в истории :)
Если популяция ниже определеного порога, она вырождается и умирает.Нет.
Есть такое понятие «бутылочное горлышко». Его прохождение часто весьма способствует эволюционным изменениям.
Если будем выкашивать рандомно 10% в коллектие в сотни… тысячи… миллионы единиц- «эволюция» продолжится, но с меньшей скоростью.Нет.
Высокая численность популяции является эффективным тормозом эволюции. Можете погуглить «кошмар Дженкина» и «дилемму Холдейна».
/оффтоп.
Есть такое понятие «бутылочное горлышко».
Вы имеете ввиду этот «Эффект бутылочного горлышка»
Цифры что я видел: Людей, если меньше 150..200 в племени, вымирает за порядка 5 поколений. Тоже падение устойчивости к внешним воздействиям.
По животным 100..1000 в течении 50..100 лет.
«кошмар Дженкина» ...«дилемму Холдейна»
Не могу ничего сказать, но материалы относятся к очень давним временам, а в свете данных последних 10 лет генетики открыты горизонтальный перенос генов, и теория о резких эволюционных скачках в следствии накопившихся небольших генетических изменений.
Но полагаю, что далее тут эту тему развивать не стоит :)
Там несколько не тот механизм. При падении численности популяции увеличивается вероятность вымирания. Бутылочное горлышко можно и не пройти. Но ни о каком детерминированном вымирании речи и близко не идет.
Про горизонтальный перенос генов я еще в детстве слышал, это очень сильно не десять лет. Теория о резких скачках… Не ловлю. Не прерывистого равновесия? Если она, то это 70-е, и несколько не о том.
Ну и да, если что, не развивать тему всегда готов :)
В конце концов, это был оффтоп.
Вы как в том анекдоте.
Грибник заблудилися в лесу и кричит "Ау! Ау!"
На шум из кустов вылезает сонный медведь.
— Мужик, чего орёшь?
— Заблудился я, надеюсь, услышит кто.
— Ну я услышал. Тебе сильно помогло?
Лично мне — нет.
Теоретически это могло быть уродство, сбой в онтогенезе. Если дать эмбриологу возможность, он вам Слейпнира вырастит, а не то что муху восьминогую. Ну может, вырастить не получится, но родит запросто.
А работодатель всегда хочет заплатить меньше. Отсюда и придумываются всякие набросы типа «корпоративная культура», «мы — семья», «мы — избранные», «айти-нация» и т.п.
вот как здесь, например
Выходит, я не программист.
Ибо под понятие «поработать меньше и получить больше» никак не попадает.
Таки да или нет?А поцчему Ви спрашиваете?
Проще если. Клиента встречает метросексуал, пишет код ему бородатый вечно пьяный хакер, а по пятницам они вместе обсуждают проекты в ближайшей рюмочной?
Или вы заставляете инженеров говорить с бизнесом? Тогда может в этом проблема?
Автор говорит о том что в рабочей обстановке в последнее время культивируется «безопасное и мягкое общение» и именно против этого тренда он и высказывается.
Разумеется, такой коллектив и его представителей следует максимально изолировать от тех, кто против их стиля общения.
Я достаточно ясно излагаю свои мысли, они не нуждаются в вашем толковании да ещё и с уничижительными эпитетами.
Вы достаточно ясно излагаете мысли для себя..:
Любые предложения люди понимают иначе, чем тот, кто их вносит.
Следствия:
Даже если ваше объяснение настолько ясно, что исключает всякое ложное толкование, всё равно найдется человек, который поймет вас неправильно.
Если вы уверены, что ваш поступок встретит всеобщее одобрение, кому-то он обязательно не понравится. — Третий закон ЧизхолмаPS Я вот ваш текст не осилил — нытьё и плачь, с просьбой вернуть хамство… И откуда-то внезапно берутся розовые сопли и карамельные рельсы… Ау, вы про какой айти-то хоть? Мировое? Нет такого — есть европейское, есть американское и т.д. Нет, ситуация с линуксом, конечно не самая приятная, но на галерах, например, никаких изменений нет. В ынтырпрайзе — тоже не особо заметно (благо галеры наполовину с ним пересекаются).
Вы же сами ратуете за прямое, без обиняков выражение мнений. А как получили такое мнение о своей работе — так сразу просьба перестать?))))
Чувак, если я "ниасилил" текст, это не значит, что я его не читал. Я осилил (давясь) первые ~40% и последние два абзаца. Чтобы иметь представление о чём речь — достаточно. Если ты умудрился запихнуть в указанный мной кусок все свои "гиперболы" (на самом деле адовые перегибы в большинстве случаев) — сугубо твои, как автора, проблемы, т.к. существенно снижаются твои шансы быть понятым.
В общем я "ниасилил" твой текст, а ты "ниасилил" обычную, даже без мата, критику… за которую типа ратовал в текстовке. Никакого уважения такое поведение вызвать не может.
У вас, вероятно, серьёзные проблемы. Вы не прочитали даже половину текста, но так перевозбудились, что бросились гневно писать комментарий. Мне не особо интересно мнение такого формата.
В общем я «ниасилил» твой текст, а ты «ниасилил» обычную, даже без мата, критику… за которую типа ратовал в текстовке. Никакого уважения такое поведение вызвать не может.
А где там, извиняюсь, критика?
Практически переход на личности, выворачивание позиции человека наизнанку, явное пренебрежительное отношение к человеку, которое без проблем можно воспринять, как хамство.
Есть один кусок текста без пояснений, что тут не так и что вам не понятно.
Так же, извиняюсь, критика?
не надо его ограждать от критики. Надо говорить «Ваня, ты дибилоид, ну как так можно», в идеале еще показать ошибки и научить как правильно.
Это разные вещи, которые любители хамства не понимают. «Ты дебилоид» — это не критика, это прямое оскорбление. То, что и называется токсичностью.
«Ты накосячил, сделал так, а надо было вот так» — критика. Здесь нет оскорблений, но нет и никакого ограждения от критики.
Вообще мысль автора понятна.А мне нихрена не понятна: навалена куча каких-то предрассудков, ни грамма логики, никаких выводов. Так и хочется ответить на это:
Идите-ка вы в жопу с вашей «токсичностью»!чем-то вроде этого:
Иди-ка ты автор в жопу с своими «статьями»! Набросал две страницы ключевых слов и теперь рассказываешь в комментариях «я этого не писал», «вы мне это приписываете». Дай я открою тебе глаза: ты вообще не написал на одной умной мысли кроме того факта, что без критики и честных фидбеков мы никуда никуда не поедем. Вот тебе честный фидбек: засунь ты себе эту статью обратно вДело, на самом деле, в том, что вежливость, как заметили тут многие — это этикет или протокол взаимодействия между работниками. Быть невежливым и вызывать какие-либо втч отрицательные эмоции у других просто мешает работе. Пример с дальнобойщиком и продавщицей здесь неуместен, поскольку, во-первых любая женщина и любой мужчина предпочтёт вежливое обращение к ним вне зависимости от того, как они сами обращаются. Во-вторых, их взаимодействие длится несколько минут от силы, легче потерпеть.жопучерновики. И не связывай рабочие навыки, привычку материться и твердость гениталий. Слово "!@#" тебе, как видишь, никак не помогло.
Что касается стрессоустойчивости и «запрет на негатив» — то это просто манипуляция фактами. Админ стрессоустойчив не потому он матерится, и матерится он не потому что он стрессоустойчив. Он матерится потому что он — быдло, а на работе его держат потому что, наверное, достоинства превышают недостатки. И, наконец, если некомпетентный джун тебе пятый раз присылает говнокод на ревью, а ты не видишь никакого решения кроме как «вызвать негативные эмоции» чтобы решить проблему, то ты — некомпетентеный начальник. Когда встречаются два некомпетентных человека ни трэш-ток, ни размазывание розовых соплей не помогают, да.
И вот кроме «джун, ты !@#» тут и не скажешь ничего.Я так и написал: некомпетентный руководитель. Разве что мне здесь кто-то объяснит зачем вообще человека обзывать !@#ем и как это помогает рабочим отношениям.
Вы же говорите о ситуациях, когда джуна с первой итерацией кода посылают в !@#Где?
Лично мне проще работать в коллективах «твой отдел — твоя семья», где действительно доверительные отношения и никто ни с кем не сюсюкается.Вероятно, не у всех ваших сотрудников слово "!@#" — нормальное обращение в семье и вполне возможно, что они страдают из-за вас на работе и вполне возможно, что это отражается на их производительности. Кроме того, лично мне совершенно не нужны ваши семейные отношения на работе.
Но насаждение «этичной толерантности» чуть ли не силой это явный перебор на мой взгляд.Силой — это бьют, что ли? Заставляют отжиматься? Да, явный перебор, согласен.
Вы передергиваете.
Люди могут страдать не только от того, что кто-то материться, но и от того, что они ощущают давление в направлении рамок.
Самый банальный пример, это когда ЧР делает замечание о том как стоит и не стоит разговаривать людям, которые уже давным давно на ты.
Создать общий свод правил о том, как нужно себя вести, что-бы любой коллектив с любым составом уживался на 5 — невозможно. Вас раздражает семейность, кого-то формальность, кого-то другого что нибудь еще. И каждый может привести доводы, почему такой или иной стиль поведения продуктивней.
Единственный способ создать функционирующее общество, это не вмешиваться в дела, которые вас не касаются. Если кто-то любит материться, пусть матерится. Если вам это мешает — договоритесь. Это отлично работает в современных обществах (меритократический капитализм). Но вот люди зажили хорошо, и как много раз до этого, хотят сделать лучше. Ничем хорошим это не кончится.
Люди могут страдать не только от того, что кто-то материться, но и от того, что они ощущают давление в направлении рамок.Приватные бесседы — личное дело каждого. Если ЧР слышит приватную бесседу — то она больше не приватная. Если вы открыты к критике так, как бахвалится этим автор, то никакого давления от замечания испытывать не будете.
Самый банальный пример, это когда ЧР делает замечание о том как стоит и не стоит разговаривать людям, которые уже давным давно на ты.
Создать общий свод правил о том, как нужно себя вести, что-бы любой коллектив с любым составом уживался на 5 — невозможно. Вас раздражает семейность, кого-то формальность, кого-то другого что нибудь еще. И каждый может привести доводы, почему такой или иной стиль поведения продуктивней.Нет. Во-первых, продуктивность тут вторична. Во-вторых, пилоты используют специальный лексикон на англ языке в полете потому что о нем смогли договориться. Ваши интернеты пользуют доисторический HTTP потому что о нем смогли договориться. Названия живых организмов все на латинском потому что о нем смогли договориться. Люди по умолчанию вежливы друг с другом потому что об этом смогли договориться и свидетельство тому — несколько статей админ кодекса. Вопрос: сможете ли вы договориться на работе повсеместно использовать какой-то другой стиль кроме формального? А если новый сотрудник — то заново договариваться? На это может уйти много времени, что как-то не вяжется с продуктивностью.
Единственный способ создать функционирующее общество, это не вмешиваться в дела, которые вас не касаются.Это у вас пережиток советского воспитания: «не лезь», «не твое дело», «ты что самый умный?». Об этом можно вести отдельную дискуссию, но суть в том, что это, скорее всего, плохо и неправильно, и, ИМХО, одна из основных причин почему люди из СНГ по-прежнему хотят свалить на запад.
Если кто-то любит материться, пусть матерится.Так, где границу проведем? По какую сторону от границы будет огнестрельное оружие?
Если вам это мешает — договоритесь. Это отлично работает в современных обществах (меритократический капитализм).Хер это а не работает. Если вы заглянете в среднестатистический российский подъезд, то вы сразу поймёте, что 50 человек не могут договориться просто ни о чем. Не умеют-с.
Если ЧР слышит приватную бесседу — то она больше не приватная.
Одно дело если вас попросят говорить тише или в другом месте, другое, когда вас начнут поучать как друг друга называть.
Во-вторых...
Все что вы тут перечислили — это языки. Но существуют еще и межличностные отношения. Конечно, на работе можно ограничится лишь рабочими вопросами. Но люди есть люди все равно будут симпатия и антипатия. И это уже за рамками формального общения.
Это у вас пережиток советского воспитания
Я вырос не на пост советском пространстве, а в очень даже западном Израиле. И люди стараются не вмешиваться друг другу в отношения.
Так, где границу проведем? По какую сторону от границы будет огнестрельное оружие?
Причем тут оружие вообще? Мне от того, что кто-то с оружием ходит ни тепло ни холодно.
А граница находится между непреднамеренным и намеренным вредом. Легко придраться к мату, а вот к неуклюжести? Или к депрессии? Или к аутизму? Проявления этих вещей раздражают на порядок сильнее мата.
Хер это а не работает.
Это работает лучше чем автократия. Если есть проблема, то ей занимаются те кто замешан, а не все вокруг. А то что в РФ происходит это никак не пример.
Одно дело если вас попросят говорить тише или в другом месте, другое, когда вас начнут поучать как друг друга называть.Вот открытие: у всего есть мера.
Но люди есть люди все равно будут симпатия и антипатия. И это уже за рамками формального общения.Неформальные отношения с хорошо знакомыми людьми на работе мешают этой самой работе — инфа 100%.
Я вырос не на пост советском пространстве, а в очень даже западном Израиле.Вполне вписывается в мои представления об Израиле.
Причем тут оружие вообще?Подумайте.
Вот открытие: у всего есть мера.
И вот ее нарушают. Об этом и статья.
Неформальные отношения с хорошо знакомыми людьми на работе мешают этой самой работе — инфа 100%.
Неформальное общение это не только покурилки. Нелюбить человека можно за то как делает код ревью. Можно весь отдел похерить, с плохим менеджером, который только формально общается — инфа 100%ю
Вполне вписывается в мои представления об Израиле.
Какие?
Подумайте.
Я подумал, и все равно никакой связи не вижу.
P.S.
Мне не нравится ваш токсичный стиль общения.
Интересно, а что если после того как вы скажите джуну идика ты на @*_#, он вежливо попросил тебя выйти на улицу уточнить лично с ним ваши претензии. Возможно ваш пыл сразу поубаватся. Нельзя давать себя оскорблять, нужно это мгновенно пресекать любым способом, иначе у человека это войдёт в норму. Как тут писали — вежливость и порядочность на работе — это протокол общения
Вы намекаете на силовое наказание обидчика. Успешное наказание легко попадает под статью УК, с учетом того, что в травматологии пострадавшего будут едва ли не пытать: «итак, я вам предлагал признаться в том, что вас побили, и вы согласились? Нет? То есть вы решили скрыть факт того, что вас побили? И кто именно вас не побил?..».
А дальше как я со стороны программиста вижу влияние этого на дальнейшую карьеру: коллеги запомнят обе стороны конфликта как «чуваков, которые подрались в офисе». Именно так, без лишних деталей. Когда через 5 лет у них рекрутер спросит «знаешь ли ты Персону1» именно этот прецедент и всплывет в памяти, с погрешностью на испорченный телефон и забытые со временем детали.
С точки зрения менеджера обе стороны конфликта рассматриваются как потенциальный источник проблем. На их отношения между собой менеджеру пофиг, не пофиг на проект и коллектив в целом. А это как минимум риск спонтанных увольнений день-в-день на эмоциях.
С точки зрения кадровика (и всех помошниц, 90% из которых станут кадровиками других компаний через 5 лет) на корпоративе после выпивки это будут 2 обезьяны с гранатой, а сам случай — опасный прецедент, другие могут взять на вооружение.
С точки зрения топ-менеджмента это как минимум неприятная мелочь, а как максимум: потери репутации.
Плюс один — пацаны на районе уважают.
Быть невежливым и вызывать какие-либо втч отрицательные эмоции у других просто мешает работе.
Можно подумать, что быть *вежливым* и «вызывать какие-либо втч отрицательные эмоции у других» — работе не мешает. *Эмоции* — как бы, вообще не та вещь, которая — безусловно — уместна «на работе».
И, наконец, если некомпетентный джун тебе пятый раз присылает говнокод на ревью, а ты не видишь никакого решения кроме как «вызвать негативные эмоции» чтобы решить проблему, то ты — некомпетентеный начальник.
Даже опуская вариант, когда «вызвать негативные эмоции» — это и есть «решить проблему», ваше обобщение с «некомпетентностью»… это такое. Сказать, что «говнокод» — это «говнокод», если и является «некомпетентностью», то несколько в другой области :-)
Но фичи ломают архитектуру и вообще не вписываются, зато ОЧЕНЬ нужны.
В воздухе плавает запах дедлайна, свежих багов и пара топоров, которые не падают из-за густого мата, что не нравится нежным девочкам-тестировщицам и вызывает негативные эмоции.
Внимание, вопрос: и что делать в таком случае?
Что делать: действовать по принципу "вернуть проблемы тем, кто их породил, на устранение". Для этого провести анализ корневых причин, т.е. собрать фактологию, проявляющую возникновение ситуации. Где-то на верху будут две связанные причины: нарушили технологию разработки, чтобы "отжать" разработчиков (или аутсорсера). А для этого никак не решают вопрос соответствия нагрузки (объёма задач) производительности.
Т.е. проблема возникла намного раньше и выше: на уровне лиц, принявших ошибочные решение. Реакция разработчиков – тщетная попытка сигнализирования и защиты от бессмыленных и вредных перегрузок на уровне психики (т.е. мат и прочие реакции). В целом, это поломанный процесс разработки, где съумничал кто-то из лиц, принявших ошибочное решение и такие условия.
Вернуть им проблему – заставить исправить ошибки в решении, т.е. принудить к выполнению технологии разработки и обеспечению покрытия объёма задач производительностью с запасом 10-15%. И это как раз то место и направление, куда необходимо направлять все реакции в созданной подставе.
Отжимают тех, кто отжимается. Грузят лошадь, которая везёт. Увы, но степень упырства многих "на верху" переходит все вообразимые пределы. И отдела разработки с лихвой хватит, чтобы пару-тройку человек реально испугать (в т.ч. превосходящей физической силой) и заставить правильно учесть и обработать названные выше причины. Не просто так ЛПР закрываются в своей коморке, чтобы "порешать вопросы" скрытно от тех, кому потом прилетит головняк. И да, это всегда вопрос власти и её баланса. Пока его нет, будут отжимать, а значит будут "бухтеть недовольством под нос на весь ёпн-спейс".
Кто Вам сказал что людей хантят печеньками? Что у Вас вообще в голове творится?
Это что у Вас в голове творится? Где в статье про то, что хантят печеньками? Автор написал о том, что в вакансиях очень часто есть упоминание про печеньки. Я тоже это постоянно вижу и меня тоже это выводит из равновесия. При этом никто не говорит, что печеньки не нужны, с ними лучше чем без них. Но, блин, есть много вещей важнее этого. Кресло удобное, например. Или не адовый опенспейс на 100 человек, а маленькие кабинеты и т.д.
и зимой тепло
А давайте. Не приходилось в офисе сидеть в пуховике?
Ох, очень хотелось бы видеть в вакансиях фразы типа "у нас в офисе нормальная приточная вентиляция и уровень ppm" и "у нас не приняты громкие дебаты и оффтоп в опенспейсе". Вот реально, дал бы скидку 10-20% зарплаты за эти два пункта.
Автор написал о том, что в вакансиях очень часто есть упоминание про печеньки. Я тоже это постоянно вижу и меня тоже это выводит из равновесия.
Так вот для кого safe spaces придумали! :)
1.
Почему-то активно продвигается мнение, что нельзя критиковать людей, нельзя вообще высказвать им негативную оценку.
Не соответствует правде. Критика постоянно высказывается, особенно в пулл-реквестах, после работы QA, и пользователями. Я бы сказал большая часть работы программиста — это работа с конструктивной критикой
2.
Человек может раз за разом отправлять вам на ревью код с одними и теми же ошибками и надо отвечать на это вежливостью и улыбкой?
Вежливостью — да, улыбкой — нет. А потом просто вежливо попросить написать по собственному. Проявлять агрессию и выходить на конфликт — себе дороже.
3.
Как вам такой расклад — получить отрицательный фидбэк от коллег без явных причин? И нет, вы не выясните подробностей, вы просто раз за разом не будете получать повышение не зная почему.
Конечно же без явных причин! Токсичность и отсутствие компетенций тут не причем, да :)
4.
С годом опыта можно быть специалистом высшего уровня в профессии.
А когда, например, ява программист с 10 летним опытом, 5 из которых на управленческих позициях, начинает писать на PHP. Считаете, у за год не сможет до сеньора дойти? Ну считайте, ваше право :)
5.
Неожиданный факт — программисты не хотят работать без печенек.
Неожиданный факт — там, где печеньки и кофеек, работается почему-то лучше. при прочих равных я бы выбрал с печеньками.
6.
Через три месяца разговор с HR, в результате которого выясняется, что команда его ненавидит.
Ненависть коллектива сложно игнорировать, хочу я вам сказать. Видимо эта ненависть только по словам HR, а в реальности проблемы иного рода.
После прочтения данного произведения хотелось бы посоветовать автору перестать мыслить чрезмерно категоричными понятиями (ненависть, двуличие, подковерные интриги), и начать прислушиваться не только к своему мнению, но и к мнению окружающих, а так же хорошо выполнять свою работу, и тогда за токсичность никто уже увольнять не будет :)
Тут такое дело, нельзя всех причесать под одну гребёнку. А статью стоит рассматривать с юмором а не как крик души отчаявшегося грубияна.
В нетоксичных рабочих средах ваш тезис не соответствует правде. В них в пулл-реквестах, баг-репортах и т. п. критикуется не человек, а результат его работы: код, иное техническое решение и т. д. В нетоксичных рабочих средах большая часть работы программиста — это работа с конструктивной критикой его кода, его технических решений, а также с конструктивной критикой его поведения, его действий или бездействия, влияющих на производственные процессы.
В нетоксичных рабочих средах недопустима даже конструктивная критика личности человека, даже по его явной просьбе. Результаты работы, поведение в рабочих процессах — да, если конструктивно, то можно критиковать. Личность, поведение вне рабочих процессов — нет, даже конструктивно, по крайней мере в рамках работы — могут быть нюансы если общение не ограничивается рабочими процессами, но тут всё индивидуально.
недопустима даже конструктивная критика личности человека
Личность и психология — это не код писать. То, что вы считаете личностной проблемой может быть частью характера, позволяющей человеку раскрыться в иных направлениях деятельности. Не вам судить, что в личности человека хорошо, а что плохо, ему не пять лет, и лишением сладкого плохое поведение не исправить.
Критикуйте то, в чем у вас есть набор компетенций. Если вы программист — профессионально критикуйте код, а для профессиональной критики личности есть психологи и психотерапевты, и их этому минимум 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 то не оптимизирует в рантайме?
Насчёт линейного времени — зависит от того, что за коллекция. Там может быть 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?)
Чтобы не создавать итераторы.
В случае с тем же 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:
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 осуществляется синхронизация. Когда поток один, синхронизация не нужна, но время на неё всё равно уходит.
Иди-ка ты на !@# со своей «токсичностью»